SUMMARY: How to free a busy device?

From: Robert J. Cronin (rjcronin@uop.com)
Date: Sat Jan 09 1993 - 05:01:50 CST


Thanks to all! There were eleven responses, evenly split between
advisers and sympathizers. Seems to be a topic of interest, but there
doesn't seem to be any solution.

The original posting was:
>
> Is there any way, short of re-booting, to free a device which is busy?
> A specific example of this question is the following:
> SPARCstation IPC running SunOS 4.1.1.
> A corrupted DOS floppy disk was mounted on /pcfs. The command:
> "file /pcfs/*" got hung when trying to read from the corrupted portion
> of the disk, and was left in the DW state. (Or, worse, the user tried
> to open the /pcfs folder in the filemgr, hanging the filemgr, mouse and
> all.)
> It now seems impossible to use the floppy disk drive without
> re-booting, as the device is "busy". Removing and MAKEDEVing fd0
> doesn't work, and "kill -9" on the process in the DW (non-interruptible)
> state can't kill the process which is making the device busy.
> Can the OS be coaxed into freeing the busy device?

The answer to the general case question appears to be "NO!"

Several people had some suggestions for specific situations, such as
for serial line attached devices, and for devices for which driver
source code is available....

For serial attached devices, the suggestion is to:

> given similar problems with the real /dev/tty[ab] ports,
> I have had some luck by running as the superuser and
> forcing output to the device, or trying to output to
> the device and interrupting the process while it is
> hung, sometimes using the stty command, other times
> just doing any output to the device. In other words,
> I just screw around with the device. This may or may
> not be possible with devices other than the serial lines.

This does _not_ work with the floppy drive problem I have.

If source code is available for the driver, the suggestion is to:

> I've had some luck doing this with a 9-track tape drive. what I
> did was look at the source, find out which variable causes the
> driver to report EBUSY, and then use adb to reset that variable.
> seems to work for me.

Unfortunately, driver source code is not usually available to me.

For floppy drives in particular, several responders suggested:
"Force an eject with a paper clip, and insert a good disk."

This does _not_ work. However, you can get the new floppy to spin, and
by using a 1.44 MB floppy instead of the 720 kB which caused the hang
(or vice versa), you can even get the device driver to say interesting
things in the console by doing the following:

                echo " garbage " > /dev/fd0

fd0: read failed (40 1 0)
fd0: bad format
fd0: read failed (44 1 0)
fd0: bad format
fd0: read failed (40 1 0)
fd0: bad format

Yet, still the processes are hung, and /pcfs cannot be "umount"ed or
accessed. (sigh) Several people also suggested that the Sun pcfs
software not be used, but to use "mtools" instead.

FOR THE GENERAL CASE OF FREEING ANY "BUSY" DEVICE, THE FOLLOWING WORDS OF WISDOM WERE OFFERED:

> As far as I'm aware there is no way to free a process in the D state (non-
> interruptable short term wait) unless it receives it's required interrupt.
> This can occur either from a successful operation/error/timeout. If it
> doesn't go away of it's own (ie timeout) then I think your stuck with the
> need to reboot. (I get this all the time when developing device drivers, it's
> a real pain!)

AND,

> sounds like the device status word is hosed and the device driver will
> only be reentered when it is changed back (by the device driver itself
> responding to an intterupt). the other way to clear it is obviously to
> reload unix thus reinitializing all states. this happens on serial ports
> as well giving an error like "link down".
>
> sorry for the bad news.

Thanks again to one and all,

Bob Cronin
(RJCronin@uop.com)



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:20 CDT