Thanks for the responses. My original question
>>I recently saw a summary regarding busy
>>tape tape devices, but no processes using it !!?? I would be very
>>gratefull if someone could forward it too me, because it's just
As I said in the mail, no processes were using the device,
I had many mails regarding grepping the process table for rmt, dump, tar
fuser -f /dev/rmt/0
fuser -u /dev/rmt/0
These yielded no output, and I had already tried these.....
Dave Worthington <email@example.com> sent me a sunsolve report on the
problem, but the sun report offered no solution, only acknowledgement!
Chris Marble <firstname.lastname@example.org mailed me saying that the only
way out was a reboot, which is what I had suspected all along :-((
The real reason, as I suspected was to do with the tape driver itself,
which is apparrently flaky in 2.4 (but now fixed in 2.5.1 ?).
A feasable reply came from Leo Willems ....
If a process enters a systemcall and the driver gets blocked, the
can not be killed: the kernel-handling of signals is processed when
the process is scheduled. Since the driver has blocked the process,
the process can not be scheduled, hence it won't be killed.
This blocking should not occur: poorly written drivers did suffer from
this behaviour (i.e. by missing interrupts).
To make a long story short: the ony thing you can do is powercycle
the tapeunit and hope the driver will get some kind of interrupt
(as you did) or reboot the unix-host.........
The solution in the end was a reboot :-((
Does anyone know of a patch fix this on 2.4 ?
Many Regards and Thanks,
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:55 CDT