Very Computer

I'm using an Exabyte 8mm tape drive through "/dev/rmt/0lbn" unser Solaris 2.4.

If something goes wrong with the tape during execution of "mt ..." command,
this command hangs in a state in which it can't be interrupted or killed.
The device remains busy even if I can manually eject the tape. The only
way to get the access to the tape is to reboot the system.

Is it possible to kill "mt" somehow or make the tape device NOT BUSY some
other way? Are there any timeouts defined for the "mt"/device (if so,
can they be made shorter) ?

any help will be appreciated,

regards, Michal.

****************************************************************************


  Al. Ujazdowskie 4                   Voice:    48-22-294011 ext 23
  00-478 Warszawa, POLAND             FAX:      48-22-294967
****************************************************************************

Quote:

>If something goes wrong with the tape during execution of "mt ..." command,
>this command hangs in a state in which it can't be interrupted or killed.
>The device remains busy even if I can manually eject the tape. The only
>way to get the access to the tape is to reboot the system.

     % dd if=/dev/zero of=/dev/rmt/0 bs=1000k

When the drive reached the end of tape, it generated the following syslog
messages:

   Dec  1 16:05:14 phantom unix:  Disconnected command timeout for Target 4.0

And then it hung just as yours did.  I've also had this happen with
ufsdump (using a blocking factor of 512) and with mt commands, and in
each case the only way to unhang the tape drive was to reboot the system
(actually from one test I suspect that there may be a timeout--albeit a
very large one).  Several problem reports mention this bug, notably
1194930 and 1214726, but no fix information is available (although one
suggestion is to set st:st_space_time to 5400 in /etc/system).  Does
anyone know if this bug has been fixed and if so which patch fixes it?

--
John Caruso, Senior Technical Consultant
ADP Claims Solutions Group                 Phone: (800) 366-4237 x2102
2010 Crow Canyon Place                     FAX  : (510) 866-4839

- >
- >If something goes wrong with the tape during execution of "mt ..." command,
- >this command hangs in a state in which it can't be interrupted or killed.
- >The device remains busy even if I can manually eject the tape. The only
- >way to get the access to the tape is to reboot the system.
-
- We've had nearly the same problem with Sun's SPARCstorage Library model
- 8/140.  I tested it by running the following dd command:
-
-      % dd if=/dev/zero of=/dev/rmt/0 bs=1000k
-
- When the drive reached the end of tape, it generated the following syslog
- messages:
-

-    Dec  1 16:05:14 phantom unix:  Disconnected command timeout for Target 4.0
-
- And then it hung just as yours did.

We had some tape problems with solaris 2.4, too. There are esp
(102002-03) and st (102035-01) fixes available.  These have fixed the
problem (process accessing the tape remains in un-killable state) for
us.

Note: If an st I/O operation times out (kernel parameter st_io_time:
120 sec), the st driver often retries the operation (kernel parameter
st_retry_count: 20 times) after resetting the scsi bus.  If your tape
hardware is in some kind of `strange blocked state' for some reason,
the st driver needs a **long** time (40 minutes) to eventually give up
on a single tape access.  During this time the process accessing the
tape is un-killable.

--