Alan Cox wrote:
>On Mer, 2003-04-30 at 13:10, Denis Vlasenko wrote:
>
>
>>>Having the kernel not use 100% CPU?
>>>
>>>
>>I suspect IDE error recovery path was never audited for that
>>
>>
>
>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.
printf("About to seek\n");
result seek();
printf("Seek done.\n");
BigLoop:
printf("About to read\n");
result = read(fd,buffer, x_bytes);
printf("read done.\n");
If (result != x_types) assert(0);
else loop back to BigLoop:
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.
To me, this is somewhat strange behaviour, a bug even.
Is there some other user space parts between the kernel and the "read
done" message that I don't know about?
So, from the logs, it looks like the kernel tries to keep reading the
DVD, but it is not the user application requesting that!
Is there some sort of caching code between read() and the kernel, and if
so, how do I turn it off.
Cheers
James
-
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