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