> > This unkillable process/unusable device deadlock does occur for floppy
> > drives and externally powered devices (eg Zip drives). In the latter
> > case, the power supply to the Zip drive could accidentally be yanked
> > out. If the user does not notice this, then a process that accesses the
> > drive will cause the deadlock. A reboot will be necessary.
>
> This should not happen! In the case of the Zip drive, the driver should
> implement a timeout after which it returns an error to the process.
Hmm, a good idea, but what if the disk was somehow changed (I don't have
a Zip, so I have no idea if this is possible -- I assume the disk eject
button is electronic rather than mechanical, but know nothing beyond this).
> There's no oops, at least on 2.0.27, but there is a panic. And process
> will deadlock as you've described.
Hmm, last time I tried this was back in 1.1.x days, but wasn't willing to
try it again. :) A cursory examination of floppy.c shows it is interrupt
driven, so timeouts would have to be done by semaphores and such like, I
would imagine. The problem of knowing what diskette was in the drive
still remains: the layered methodology might prevent the driver from
knowing anything specific about the filesystem to tell it what disk is
present (eg. serial numbers, etc.).
-- William Burrow -- Fredericton Area Network, New Brunswick, Canada Copyright 1996 William Burrow Canada's federal regulator says it may regulate content on the Internet to provide for more Canadian content. (Ottawa Citizen 15 Nov 96 D15)