Re: 2.2.10 on Mac IIcx: SCSI doesn't work :-(
On Fri, 11 Aug 2000, Alexander Shumakovitch wrote:
> On Thu, Aug 10, 2000 at 04:17:17PM -0500, Andrew McPherson wrote:
> > If the IIcx is anything like the various SE/30's around, don't give a
> > ramdisk much hope. The SE/30's all die with a "Bad kernel buserr" during
> > NuBus slot scanning on startup.
> So I did some more testing and got some more logs. I've tried to boot
> 2.2.16-080700 with and without RAM-disk and 2.2.14-073100 with RAM-disk.
> With RAM-disk it gets only till ABCFGHIJ on the screen and then everything
> freezes, but there is still output on a serial console. Without RAM-disk it
> goes as usual till depmod.
>
> Moreover, 2.2.14 produced an infinite output. I had to switch the computer off
> when the log became more than .5MB. I'll attach only excerpts of it to this
> mail but could send the whole one on request ;-) What's interesting is that
> there was some garbage instead of process information (I hope it'll be sent
> correctly) and pids were truly amazing.
>
> Hope this helps somehow!
>
> --- Alexander.
>
I've seen the recurring errors before. Every time, it prints a bus error
with a longer trace, ad infinitum until I shut it off. Odd...
[snip]
[2.2.16:]
> Stack from 0018ff10:
> 00002000 00000001 f9fffffc 000074e0 0015dc40 00000068 00000008 0018ff66
> 00000014 000000e1 00002000 00000001 00000001 000000e1 00000009 00000002
> f9fffffc 000074e0 0075727c 001291b0 00000000 0000f9ff ffb02334 0000ea60
> 00129193 001291b0 001291b0 00002000 00181106 00129193 00167ff8 0015df58
> 00000009 000000e1 00000009 00000078 00000000 00000001 00000001 0015def4
> 00002000 0015df76 00000009 00000000 0000b21c 0015dfba 000fea96 00156fd0
See the f9fffffc? That means it probably died probing slot 9. I don't know
how that helps us, but it's interesting.
>
>
> ======================== 2.2.14-073100 with RAM-disk ======================
>
[...]
> *** ADDRESS ERROR *** FORMAT=B
> SSW=0x264d Pipe stage C instruction fault at 0xdb6db6db
> Current process id is -613566757
> BAD KERNEL TRAP: 00000000
> PC: [<001544de>]
> SR: 2004 SP: 0071bf44 a2: 0071a000
> d0: 0000004f d1: 0000004f d2: 00000000 d3: 00000078
> d4: 00000000 d5: 00000001 a0: 00000600 a1: 50f02000
> Process Ûm¶Ûm [ skipped around 6KB ] ¶m¶Ûm¶Ûm¶Ûm¶Ûm¶Frame format=B ssw=264d isc=50f0 isb=4ab9 daddr=0071bfc8 dobuf=50f020ff
> baddr=db6db6dd dibuf=db6db6db ver=f
> Stack from 0071bfcc:
> 6db6db6d b6db6db6 db6db6db 6db6db6d b6db6db6 db6db6db 6db6db6d b6db6db6
> db6db6db 6db6db6d b6db6db6 db6db6db 6db6db6d
> Call Trace:
> Code: 4e75 4e71 4ab9 0013 f0ca 672a 23fc 50f1 a000 0013
> Data write fault at 0xdb6db6db in Super Data (pc=0x89ee)
> BAD KERNEL BUSERR
> Oops: 00000000
> PC: [<000089ee>]
> SR: 2708 SP: 0071bde0 a2: 0071a000
> d0: 00000004 d1: 00002000 d2: 0000264d d3: 00000078
> d4: 00000000 d5: 00000001 a0: b6db6db6 a1: db6db6db
> Process Ûm¶Ûm¶ [ skipped around 7KB ] ¶Ûm¶Ûm¶Û (pid: -613566757, stackpage=0071b000)
> Frame format=A ssw=070d isc=2149 isb=0004 daddr=db6db6db dobuf=b6db6db6
> Stack from 0071be2c:
> 0000b336 0071bf38 0000e420 0071a0b6 0000264d 00000078 00000000 00000001
> 00000001 00000002 0000b336 0071bf44 0075727c 0071bf38 000034b2 0000000b
> 0071bf44 000e7182 0071a1b6 db6db6db 0071b000 0000b336 0071bf44 0000327c
> 000e70d9 0071bf44 00000000 000e70bf db6db6db 00000000 0000b336 00002000
> 000032b6 0071bf44 00000000 6db6db6d b6db6db6 db6db6db 6db6db6d b6db6db6
> db6db6db 6db6db6d b6db6db6 db6db6db 6db6db6d b6db6db6 db6db6db 6db6db6d
This is _very_ interesting. I was screwing around in MacsBug on my Classic
II a while ago trying to reverse-engineer the video brightness (MacsBug is
a major pain on < 640x480 screens BTW), and I came across a large section
of ROM, just before video memory IIRC, that was full of that "b6db6d..."
pattern. Somehow the kernel got pointed into that section of address space
as if it were usable memory. I would bet those weird process names are
"b6db6d..." converted to ASCII.
I did some testing of my own tonight. The 2.2.16 kernel died while probing
NuBus, like you found. When I compiled my own with debugging built in
(still using 2.2.14 CVS), it crashed much earlier. Extra logging revealed
that it happened while registering via IRQ's. I didn't have time to look
into it further; I'll check it out tomorrow. One thing I did notice was
"50f02000" in the stack trace- that's VIA2's address. Hmmm.
I'm convinced that all these crashes are manifestations of the same
problem, so the more info, the better. I think we might get this nailed
down with in the next week or so. I hope.
-Andrew
Reply to: