On Wed, Apr 30, 2003 at 04:23:47PM +0100, James Courtier-Dutton wrote:
> Alan Cox wrote:
> >
> >NOTABUG
> >
> >User space keeps asking it to read so it keeps using CPU, fix the user
> >space
>
> The application does an initial seek() command, which succeeds.
> It then just does read() commands for then on.
> For bug tracking, I have put printf statements in my application.
> I.e.
>
> [...]
>
> When an error occurs on the DVD, "read done" message is never printed on
> the console and all applications fail to respond to user input. This is
> why I thought that the kernel hogs CPU 100% and the application never
> receives the error message.
> If I force a different error "tray open", by using a pin in the manual
> eject hole on the front of the dvd rom device, I then see the "read
> done" message and everything comes back to life.
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/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:35 EST