> On Sun, 21 Sep 1997, Charlie Brady wrote:
>
> ...
> > The problem I get is (I can't quote, as the messages aren't logged, and
> > has scrolled off - I'll try to catch this someow) is scsi timeout while
> > accessing the SCSI tape drive. I think an access to the SCSI hard drive
> > triggers it. The "mt" process is stuck in the st driver, but I can still
> > access the SCSI tape drive.
> >
> Have you looked at where in the st driver the mt process is stuck? You can
> probably see this with 'ps -l'. The st driver should allow only one
> process to access the drive and it is surprising that you can so that with
> another process.
Woops. I meant to say that I can still access the SCSI disk drive. That's
a very different story.
I've found out a bit more since.
Contrary to my previous statement, I had not tried both 53C810 low level
SCSI drivers - I had only been trying the 53c7,8xx driver (the original
Linux one). The reason for my confusion was that the 53c7,8xx driver was
loaded in an initial ramdisk, so changing the scsi driver specification in
/etc/conf.modules was insufficient to change the driver being used.
For some reason, the 53c7,8xx driver module was compiled with
SCSI_DISCONNECT disabled. Maybe RedHat ship it that way. Enabling
DISCONNECT and recompiling the modules eliminates the SCSI timeouts. I did
still get one:
Sep 21 16:30:12 budge kernel: scsi0: REQ before WAIT DISCONNECT IID
Can someone explain?
I've also tried the ncr53c8xx driver, and haven't noticed any problems
with it.
I can now do backups with it fine, but I consider the behaviour I saw
pathological. Way back in the old days... :-), if DISCONNECT was disabled,
the scsi hard drive would wait patiently for slow tape drive commands.
Should support of DISCONNECT become mandatory for low level SCSI drivers?
email charlieb@nlc.net.au
WWW http://www.nlc.net.au/~charlieb/