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
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
> > 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.