On Tue, 12 Mar 1996, Bernard Gardner wrote:

> On Mar 12, 20:02, Russ Evans wrote:
> > Subject: Re: A couple of questions re my problem...
> 
> > network, as Jules suggested; it was simply that the Syquest was causing
> > the SCSI bus to hang (little yellow light on, Trev?

	Hmm.  Odd.  My EZ135 light is red :-)  or do you mean the Zip drive
is yellow?

I tried the EZ135 with NetBSD yesterday, after sticking a bunch of files 
on it with the installer, I tried a cd backup (mount point was /backup) 
and a "rm *".  Hung up solid.  Didn't try turning off the Syquest like 
you suggested.

Didn't I hear that somebody had a Zip drive working successfully?  Or was it
just that they got mkfs to work on the thing (finally)?  I believe something
about a kernel with linked commands permanently turned off was a solution
that seemed to work, but don't quote me on that.  I'm wondering if the 
same thing might solve the EZ135 problem.

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?

> I can do this 'till the cows come home, but when I have a file system on the
> same partition, and mount it, and then try cp /vmunix /mnt, the system hangs
> pretty solidly. I can't even get into the debugger. Yes, the little yellow
> light is on. I did some experiments last night in regard to file sizes, and
> found that it was OK to write reasonably small files, but that larger ones hung
> the system. I should hopefully be able to quantify large and small fairly soon.
> This occurs in single user mode, multi user mode with an idle console, and a
> user over serial, and every other configuration I've tried. The hang is pretty
> solid, mouse tracking stops in X, serial echo on a logged in tty stops, and I
> can't even use the "programmers switch".

Sounds like perhaps the driver is expecting information and the drive 
decided not to send it... probably just a phase error.  How long does 
NetBSD wait before re-requesting a block of data that doesn't get sent?  
Could that also be responsible for the "three minute bug" on the LCIII?  
Just another off-the-wall correlation.

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

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

> Hmm, I've just remebered that I was planning on power cycling the Zip to break
> out of the apparent deadlock, I must try that tonight.

Has anyone waited a few minutes to see if anything changes?



Later,

 /---------------------------------------------------------------------\
|David A. Gatwood             And Richard Cory, one calm summer night,  |
|davagatw@mars              Went home and put a bullet through his head.|
|dgatwood@nyx.cs.du.edu              --Edwin Arlington Robinson         |
|http://mars.utm.edu/~davagatw -or- http://nox.cs.du.edu:8001/~dgatwood |
 \---------------------------------------------------------------------/