A related problem in this case is that the reader thread will be stuck
in uninterruptible sleep, probably for several minutes. Meaning, the
process can't even be stopped or killed.
Since the read tends to just return short, without raising an error at
all, the process will often immediately go back into uninterruptible
sleep if it does wake up, too, since it's spinning on the system call.
Signal delivery seems to be pretty flaky in this case too - you'd expect
a signal 9 to be delivered as soon as the process tries to wake up, but
it tends to not. I've had to try junk like:
while true ; do kill -9 $stupid_process ; done
.. just to get something to die when it's reading bad media.
A quick way around this tends to be to hit the eject button on the CD
drive itself - it will cause the driver to abort the read quickly when
it sees that the drive is empty. However, if the tray is locked, this
is impossible (and sometimes, the driver will get into a bad state and
won't let you unlock the tray, either).
All around, error handling on CD's and DVD's is extremely flaky.
At the very least, if the driver is going to be in some sort of long
term wait, it needs to put the process in an interruptible sleep and
have some capability of aborting the request.
Of course, it gets worse in kernels where ide-scsi is in use, since in
that case error messages are often not even delivered. Do I cdrom read
audio ioctl, watch it go to sleep *forever* after the IDE layer gets
reset underneath it and the request gets lost completely. I loved
trying to debug that one at the application level. :-)
-J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/