> Here's a strange thought.  Is there a way to get NetBSD to use the driver 
> stored on a drive instead of its internal SCSI driver?  I know it's not
> exactly SCSI Mgr. 4.2 or anything, but would there be any way to code 
> such external hooks?  That would effectively make the NetBSD driver a "last 
> resort" in case of severe filesystem corruption just good enoguh to run 
> fsck and restart.  Any thoughts on that?  I'm assuming that it would be 
> possible to reverse-engineer Apple's guidelines for writing hard disk 
> drivers and from that, figure out a way to interface with the drivers.  
> Does that sound possible or is this just another "MacMint trying to 
> interface with MacTCP drivers"-type situation?

Uhm, no. Apple tells how to write drivers for MacOS, and for us, MacOS is
no where to be found. The driver out on that disk is unusable to us.

The real problem is that we're having difficulties with the equivelant of
the SCSI Manager in MacOS. The drivers are all made to use this manager,
so using the on-drive driver will not help us avoid the our problems.
If we had a solid SCSI manager, we have enough higher-level driver
support to make things work. :-)

> > Can anyone suggest what I can do to get into the debugger on a IIsi when
> > commmand power doesn't work?
> 
> Nope.  If it had an interrupt switch on the back, in all likelihood, that 
> wouldn't work, either.  Unless you'd like to hack the kernel into 
> watching for a non-maskable interrupt from the internal slot and then 
> build a card with a wire leading ton external switch....  And even then, 
> depending on what kind of interrupt it's servicing, it's likely that 
> NetBSD would ignore even that.  Hard drive access falls at the top, 
> doesn't it?  If it's waiting for the drive to return data, no interrupt 
> can override that, right?

The programmer switch generates an NMI, which the CPU will always
respond to. The problem can be one of two things: the system can be so
royally hosed that the NMI response points to never-never land.

The other problem can have something to do with your mouse (it might
not). I've found that if my three-button mouse is plugged in to the computer,
I loose the ability to have control-power and command-control-power
work on my IIsi. I traced the problem to the fact that my mouse
pretends to be a keyboard, so I end up w/ having two ADB keyboards.
One stays at the standard number (3 I think), while the other gets booted
to 15. Usually my extended keyboard is the one which is booted to 15.
The ADB system seems to only respond to control-power when it's
from keyboard 3 (the mouse in these cases), so I loose the functionality.

If you have a standard Apple mouse, this obviously isn't the problem. :-)

> > I'm working on the assumption that this is a file system problem, rather than
> > solely the fault of the SCSI driver.
> 
> I'd think it's a compatibility issue -- something in the drive not 
> responding like the driver thinks it will.

Sounds like our driver's at fault. :-(

take care,

Bill