The VM issues turned out to be nastier than I thought. It would wedge consistently with the hardware mapped. I then tried leaving the RAM backing that chunk of address space, and it -still- hung. Hmm. Changed it to allocate memory in a wired fashion and the hang disappeared. Turned back on the mapping of hardware addresses over that space and the hang came back.

Hmm. Rebuilt the kernel with a debug build so I could see where things were going wrong in the path through the VM system, since clearly something wasn't getting set up correctly in the page tables.

Odd, the debug kernel goes right through the problem spot, eventually generating a panic from calling certain VM routines without being at splvm. D'oh! Wrapped the code with s=splvm() and splx(s).

At last count, it correctly probes empty slots. When it tries to probe a full slot, as best I can tell, it's wedging whenever it hits the byte lane where the actual Nubus declaration ROM occurs. Probing different cards yields different, repeatable hangs.

What's odd is that it is successfully reading from a given address, then wedges on about the fifth or sixth access to that address. At this point, I'm starting to wonder if there's something wrong with the probe code port itself.

I've pinged the netbsd-mac68k mailing list to ask the developers if they've ever seen anything similar on the original platform. Failing that, I'm going to have to hand compare the code to the original mac68k code, and possibly hand-compare it to the Linux nubus code as well to get a second perspective from code that is known to work on PPC machines to some extent.

Now getting back to drawing my comic strip for tomorrow....