Re: 2.2.10 on Mac IIcx: SCSI doesn't work :-(
On Fri, 11 Aug 2000, Tony Mantler wrote:
> At 12:31 PM -0500 8/11/2000, Andrew McPherson wrote:
> [...]
> >How about Mode32?
> [...]
>
> Mode32 is a set of ROM patches that slices out any and all 32-bit dirty
> code from the ROMs on startup. It does nothing else.
>
> No MacOS code can execute after Penguin shuts off the interrupts.
> Interrupts are not re enabled until the kernel has overwritten the
> interrupt and exception tables.
>
> There is no DMA hardware in macs outside the 840, 660, 9x0, IIfx, and SONIC
> equipped models. The exception to this being some PDS cards, which can
> legally busmaster on any PDS-slot equipped macs.
>
> 68k macs (perhaps with the exception of the 660/840, but I doubt it) do not
> support NuBus DMA transfers.
>
>
> Just as a side note, I never noticed any ill effects booting my IIx in 24
> bit mode, back before my IIx bit the big one.
>
OK, so forget Mode32. That's not likely to be the problem. Booting in
24-bit mode on my SE/30 gave me the same result (extensions were off,
BTW). Interestingly, I can't boot in 24-bit mode on my PB 180c. Oh well,
it's not important.
I've dug up some more info as well. First, a possible kernel bug. Right
now, init_IRQ calls via_register_interrupt, which in turn calls
request_irq(IRQ_MAC_NUBUS). That will try to enable the NuBus interrupt.
However, via_nubus_init never gets called until much later in the startup
process. The old interrupt code called request_irq(IRQ_MAC_NUBUS) the
first time someone requested a slot interrupt handler. My Mac kept
crashing in init_IRQ, so I changed it to that scheme, which seemed to
work. Now I get farther in the bootup process.
However, I'm stuck in NuBus slot probing. From the debugging I added, the
probes go fine so long as there's no card in the slot. On the SE/30, it
finds something in slot E, and it goes into nubus_add_board. Everything
works OK until the kmalloc, which is where it crashes. That is, inside
kmalloc somewhere. It's odd, I would have thought kmalloc was a highly
stable function.
And I think I figured out the "db6db6..." mystery. Apparently db6 is the
magic hash that the system uses when testing memory on bootup. Or at
least, it's what the unused memory is full of. About 4-5M of my 8 Megs of
memory was solid "6db6db". So what that means is when we see 6db6db in the
stack traces or other debugging info, the kernel is trying to use some
location in memory that hasn't been initialized. Unfortunately, that's a
pretty generic problem.
Keep in mind all of this only happens while using a ramdisk. I wonder why.
-Andrew
Reply to: