Messages in this thread | | | Date | Wed, 30 Apr 2003 09:46:41 -0700 | Subject | Re: Bug in linux kernel when playing DVDs. | From | Elladan <> |
| |
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/
| |