> We've seen that before: try unplugging a PCMCIA IDE card unexpectedly.
> Guess what? It will start returning 0xff. And the machine dies, because
> the PCMCIA interrupt happened due to the removal event will also be shared
> by the IDE driver, so the IDE driver will react badly even before anybody
> has had a chance to tell it that the hardware no longer exists.
> So if you have code that doesn't work with 0xff, then that code is already
> a-priori buggy. And getting it fixed would be a damn good idea.
Yup, you are right. Removing a disk from a controller shall return
anything with bit 7 at 0 per spec, but removing the controller
itself will return 0xff. Actually, in my "wait for BSY low" loop
I added to the probe code for pmac (should be made generic sooner
or later), I did special case 0xff.
So we should indeed fix the various bits in IDE. 0xff out of
status, I beleive, never means anything and can always be considered
as "this interface is gone".
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/