Re: 2.2.10 on Mac IIcx: SCSI doesn't work :-(
On Fri, 11 Aug 2000, Michael Schmitz wrote:
> > > 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.
>
Well, either way, I'm still suspicious of the interrupt code.
> > > *** 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.
>
How is it possible for something from MacOS to still be alive? How would
it even get called if we shut down all interrupt sources?
Like I said, I discovered a large string of db6's messing around in
MacsBug on a Classic II. I thought that I found it in ROM space (40f0xxx,
or something like that), but I don't remember. I suppose the stack pointer
is pointing somewhere in RAM, in this case, though.
Question: was Mode32 running in MacOS? What happens if you turn it on/off?
I don't see why that would make a difference, but maybe it's worth a
check.
> > 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.
>
The machine I ran it on was an SE/30, so presumably that was VIA2. Not
that the address of VIA2 buried in the stack necessarily means anything.
-Andrew
Reply to: