Are you sure it never returns, ever?
The behavior most people seem to see here 90% of the time seems to be
that the IDE layer retries the request a few dozen times before
returning an error result. This usually takes 1-5 minutes.
So, does it return if you, say, go to lunch and then come back?
Of course, the other 10% of the time, things do seem to become
completely broken. I've certainly observed this sort of behavior
before.
Not to mention, blocking for 1-5 minutes even on a CD-ROM read is
broken, and is certainly very unwanted for the task of playing a DVD. I
think there needs to be a documented call to tell the kernel that the
application prefers to get I/O errors immediately instead of retries,
and it should always use a lot fewer retries on removable devices where
damaged media is common.
The other bug here is that the IDE layer seems uninterruptible in
software while it's doing this. The tasks go into uninterruptible sleep
for up to 5 minutes at a time (sometimes forever), and can't be stopped
except by forcing a hardware exception eg. with eject. You really need
to be able to kill a task and interrupt the file operation somehow when
it's in some sort of long-term CD error recovery situation.
-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/