Re: 2.2.10 on Mac IIcx: SCSI doesn't work :-(
> > 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.
> >
> 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.
That might just mean it caught an interrupt inside the routine that probes
for slot 9.
> > *** 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
Stack hosed (badly).
> > 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.
Either that, or something still alive from MacOS scribbled db6 all over
the address space where the current process happens to have its stack
allocated.
> 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.
Which isn't always at that address, depending on the machine type.
Reply to: