bring up tape drive

Peter plp-ysDPMY98cNQDDBjDh4tngg at public.gmane.org
Tue Mar 21 23:19:19 UTC 2006


On Tue, 21 Mar 2006, Lennart Sorensen wrote:

> So schedule some downtime.  Hardware failures do happen.  At least the
> drive was nice enough to disconnect and stop doing thigns to avoid any
> further damage to itself (assuming a tape jam can cause drive damage).
> Some drives might just have held the bus hostage (I guess that might be
> why some people don't think tape drives should share a bus with other
> scsi devices :)

The drive cannot hold a bus hostage, but the driver in the os can, if it 
is not written with a watchdog type timeout that lets it finish a 
'frozen' operation gracefully. You can easily prove the point by pulling 
the SCSI cable from the suspect device (on an indle bus). In fact SCSI 
devices that have hard errors beyond a preset level usually disconnect 
from the bus entirely and 'disappear' from the controller's point of 
view. This is a part of why SCSI buses are highly regarded.

On NetBSD I am usually able to unwedge a stuck tape operation (very 
rare) by sending a scsictl bus reset command from a terminal. The 
asynchronous nature of the scsi subsystem guarantees that the reset goes 
in and cancels whatever was stuck waiting. But if the driver in the os 
is not robust against unexpected scsi errors and timeouts then it will 
loop forever (or until reboot).

Peter
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list