Ska & Newwave

I have three machines located under my desk at home:

  • rock, an SMP i386 machine on which I'm typing this,
  • ska, an MVME167 machine that has a 68040 processor and is supposed to be a Debian/m68k buildd host,
  • and newwave, a Macintosh Quadra 700, which does not have enough RAM to be used as a buildd, but which I use to do some m68k-based hacking on.

A few months ago, the last two had died with various problems that had seemed to be disk-related; both gave an error in the firmware—with ska's error obviously being more... detailed... than the 'unhappy mac' error icon that newwave gave me.

Today, I powered both on again. newwave didn't even give me a hiccup; it booted right away, even if it needed to do a rather extensive fsck run. ska did take a little more work, unfortunately; it seems to boot, but it does give me SCSI errors, too. At least it's managed to make it to a login prompt, however, so I can have a chance at fixing it.

Interestingly, just as I finished the above paragraph, and less than half a minute after it made it to said login prompt, it breaks down rather horribly:

scsi0 channel 0 : resetting for second half of retries.
SCSI bus is being reset for host 0 channel 0.
scsi0 : DCMD|DBC=0x98080000, DNAD=0x2cec6c (virt 0x002cec6c)
         DSA=0x3ad300 (virt 0x003ad300)
         DSPS=0x2060000, TEMP=0x3ad154 (virt 0x003ad154), DMODE=0xe0
         SXFER=0x58, SCNTL3=0x0
         phase=MSGIN, 0 bytes in SCSI FIFO
         SCRATCH=0x3ad300, saved2_dsa=0x3ad300
scsi0 : DSP 0x2cec64 (virt 0x002cec64) ->
0x2cec64 (+1a1) : 0x98080000 0x02060000
0x2cec6c (+1a3) : 0xc0000004 0x002ce5c4 0xfff47010
0x2cec78 (+1a6) : 0x80080000 0x002cfb80
0x2cec80 (+1a8) : 0x98080000 0x00030000
0x2cec88 (+1aa) : 0x50000000 0x002cede0
0x2cec90 (+1ac) : 0x60000200 0x00000000
scsi0 : issue queue
scsi0 : dsa at phys 0x3ab188 (virt 0x003ab188)
        + 64 : dsa_msgout length = 2282225664, data = 0x2ce7d8 (virt 0x002ce7d8)
        + 60 : select_indirect = 0xfff47010
        + 56 : dsa_cmnd = 0x2ce5c4                result = 0x8888, target = 27147, lun = 0, cmd = VENDOR SPECIFIC(0xe5) c4 ff f4 70 10 88 08 00 00
        + 48 : dsa_next = 0x0
scsi0 target 27147 : sxfer_sanity = 0x0, scntl3_sanity = 0x0
                   script : 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
Unable to handle kernel NULL pointer dereference at virtual address 0000004a
Oops: 00000000
PC: [<000bfae2>]
SR: 2700  SP: 01ad9cd8  a2: 01ad8000
d0: 00000001    d1: 00002622    d2: 0000000a    d3: 00000008
d4: 002d2704    d5: 002d14e0    a0: 00000000    a1: 0015aefc
Process ntp_time_as_com (pid: 775, stackpage=01ad9000)
Frame format=7 eff addr=01ad9d5c ssw=0505 faddr=0000004a
wb 1 stat/addr/data: 0005 003ab188 01ad9d60
wb 2 stat/addr/data: 0005 0016f8b5 0000abd6
wb 3 stat/addr/data: 0005 01ad9d40 0000000a
push data: 01ad9d60 0000adec 0015aee0 00000001
Stack from 01ad9d40:
        0000000a 00000008 002d2704 002d14e0 002ce5c4 002ce140 003ab188 0000ac4a
        000bfe68 002ce5c4 0013e781 00000000 00000018 002d2704 00000000 00000000
        0000ac4a 003ab188 002d14e0 002ce000 000bfefc 002d14e0 003ab188 0013e576
        00000000 0000ac4a 002d14e0 003ad300 98080000 000bf586 fff47000 002cec98
        002ce000 000c02d4 002d14e0 003a5200 00000000 000b2704 00000018 00000020
        00000000 00000000 002d14e0 002ce000 000bf912 002d14e0 002d14e0 00000001
Call Trace:
        [<0000ac4a>] [<000bfe68>] [<0013e781>] [<0000ac4a>]
        [<000bfefc>] [<0013e576>] [<0000ac4a>] [<000bf586>]
        [<000c02d4>] [<000b2704>] [<000bf912>] [<000b6c4c>]
        [<000b5f24>] [<000b6a04>] [<000b6c4c>] [<000b6c4c>]
        [<000b65b6>] [<0013d5fe>] [<00002404>] [<000beb82>]
        [<000bd206>] [<000bf022>] [<000bf4d6>] [<000bed46>]
        [<000833fe>] [<00004e52>] [<00003b86>] [<0000c00c>]
Code: 2c68 004a 4878 0180 2f0c 47fa 0c8a 4e93 508f 2a0b
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing


Oh well, at least I've got one more working machine now. Only need to update it from unstable as it was 41 days ago to today's unstable. Going to take a while, I fear.