linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Help please: DVD ROM read difficulty
@ 2003-03-07  2:14 Guangyu Kang (Shanghai)
  2003-03-07  6:54 ` Elladan
  0 siblings, 1 reply; 4+ messages in thread
From: Guangyu Kang (Shanghai) @ 2003-03-07  2:14 UTC (permalink / raw)
  To: 'linux-kernel@vger.kernel.org'

Hi:
        Currently I'm working on a DVD player fo LINUX project.
        My player use libc read() function on /dev/hdc, i.e. dvd rom in my
system, to read data.
        The last issue I encountered is difficulties during reading
scratched discs.
        Such disc will cause the dvd rom drive get ECC error (code = 0x40)
when perorming the read action.
        And the kernel will keep retrying to get the correct data from the
disc.

        This is not what I want. In the worst case, the player's input
thread is trapped in the kernel trying to read data, seems even won't get
out from kernel for ever.
        Then the player is stalled and will not output anything, too bad.
        The read() function should report fail and return quickly when ECC
error occurs.
        This is generally the require for real time data transfer, data loss
is acceptable and delay is not acceptable.

        I drilled into the file /linux/drivers/ide/ide-cd.c and modified the
function cdrom_decode_status(), make it abort on senskey==HARDWARE_ERROR. It
do aborts, but the read() function do not return -1, it just return part of
the data read.
        What even worse is that there is too much latency. Normally there
will be a bunch of consecutive bad blocks ( logical block on DVD,
2048Bytes), each is read according to a *request* from system cache
mechanism, and each cause a DVD drive hardware time out ( about 10 seconds.
). This is still unacceptable.

        So, the target is to:
                Abort the whole read() call.
                Report FAIL to player. ( The player can do a jump and get to
some good position on the disc. )

        For abort:
                May be I can do a cdrom_end_request() on every local queue
element, thus abort to deal with all data to be read in the current read()
syscall, holding the request lock in hand and unlock it after last request
is ended.

                >>>>The first question is: WILL THIS WORK, and will it work
SAFELY?

        For report FAIL:
                >>>>The second questino is: HOW TO?
                I did not find any way to report this when the driver start
to read data, this should be due to the kernel archeticture, IMHO.
                But I am a newbie to this part of kernel, so I believe there
will be someone have the idea.

        And never the less, the third question:
                >>>>Any other idea on this case? Better solution is
welcomed!

        I have to deal with this issue, and I also hope this will contribute
to the kernel, this will give very good support to players working on LINUX,
and also make the cdrom/dvdrom works much more reasonable (IMHO we can have
two types of read() on such device that may encounter real difficulty when
doing R/W, we can do more retry when data correctness is mostly concerned,
but we won't retry for ever.)

        Thanks for your help!

Regards


                Guangyu

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Help please: DVD ROM read difficulty
  2003-03-07  2:14 Help please: DVD ROM read difficulty Guangyu Kang (Shanghai)
@ 2003-03-07  6:54 ` Elladan
  0 siblings, 0 replies; 4+ messages in thread
From: Elladan @ 2003-03-07  6:54 UTC (permalink / raw)
  To: Guangyu Kang (Shanghai); +Cc: 'linux-kernel@vger.kernel.org'

On Fri, Mar 07, 2003 at 10:14:59AM +0800, Guangyu Kang (Shanghai) wrote:
> Hi:
>         Currently I'm working on a DVD player fo LINUX project.
>         My player use libc read() function on /dev/hdc, i.e. dvd rom in my
> system, to read data.
>         The last issue I encountered is difficulties during reading
> scratched discs.
>         Such disc will cause the dvd rom drive get ECC error (code = 0x40)
> when perorming the read action.
>         And the kernel will keep retrying to get the correct data from the
> disc.

A related problem in this case is that the reader thread will be stuck
in uninterruptible sleep, probably for several minutes.  Meaning, the
process can't even be stopped or killed.

Since the read tends to just return short, without raising an error at
all, the process will often immediately go back into uninterruptible
sleep if it does wake up, too, since it's spinning on the system call.
Signal delivery seems to be pretty flaky in this case too - you'd expect
a signal 9 to be delivered as soon as the process tries to wake up, but
it tends to not.  I've had to try junk like:

	while true ; do kill -9 $stupid_process ; done

.. just to get something to die when it's reading bad media.

A quick way around this tends to be to hit the eject button on the CD
drive itself - it will cause the driver to abort the read quickly when
it sees that the drive is empty.  However, if the tray is locked, this
is impossible (and sometimes, the driver will get into a bad state and
won't let you unlock the tray, either).

All around, error handling on CD's and DVD's is extremely flaky.


At the very least, if the driver is going to be in some sort of long
term wait, it needs to put the process in an interruptible sleep and
have some capability of aborting the request.

Of course, it gets worse in kernels where ide-scsi is in use, since in
that case error messages are often not even delivered.  Do I cdrom read
audio ioctl, watch it go to sleep *forever* after the IDE layer gets
reset underneath it and the request gets lost completely.  I loved
trying to debug that one at the application level. :-)

-J

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: Help please: DVD ROM read difficulty
@ 2003-03-09  5:48 Guangyu Kang (Shanghai)
  0 siblings, 0 replies; 4+ messages in thread
From: Guangyu Kang (Shanghai) @ 2003-03-09  5:48 UTC (permalink / raw)
  To: 'Elladan'; +Cc: 'linux-kernel@vger.kernel.org'

Thanks, and I forget to cc every one :-P
I just come up from the lower layer, I suspected that it's the ide/ide-cd's
flaw.
If the upper layer is fine, there should be some thing due to interface. 
To me, ide just seems fine, ide-cd have some trival issue on error handling,
I don't think they are so bad that can be called flaw. While do abort on
this or that error case is just all I can do in ide-cd.

Now I do not have any more point - I will try what I said, just wait for my
result, hehe.

On Sun, Mar 09, 2003 at 11:35:53AM +0800, Guangyu Kang (Shanghai) wrote:
> >> Looks like:
> >> CDROM_IOCTL_LOCK
> >> CDROM_IOCTRL_REALTIME_LOGICBLOCK_READ
> >> The lock will make the driver refuse any more open to the driver, thus
> the
> >> driver can concdern on read
> >> operation from my ioctl while not the request. If some one opened the
> driver
> >> already, lock will fail.
> >> The read will be an re-organize of request handler code, adding more
> >> straight-forward error handling,
> >> which will get data from drive and copy it to user. Without the cache
> layer,
> >> in player case,
> >> better performance may be the additional gain.
> 
> >Maybe what you need here is a variant of O_DIRECT ?
> -J
> 
> 
> 
> Yeah should be it. Now I got another advice to use RAW device feature.
> 
> My old idea of the two ioctl will work like the stand alone DVD player set
> which put its output directly into a TV. I mean there will be a single
> buffer managed by player, seeking will done by player itself, and the dvd
> rom driver works much more straight forward. 
> 
> And I took a look at the raw device code yesterday, it looks like an
> re-organize of request processing code in ide-cd.c, I mean it works in a
> loop that send the request one by one, there will not be too much request
> that causes long delay. I think the cache mechanism will send a lot of
> requests and thus driver must do a lot of 10 second device time out.
> 
> RAW read still will not return failt easily, and it has its own seeking
> mechanism. This is troublesome.  You know libdvdread I'm using will do its
> own UDF handling and seeking, etc. and then read the device /dev/hdc.
> 
> I think a combine of modified ide-cd.c that abort on HARDWARE_ERROR and
RAW
> and read/seek check will be sufficient.

I dunno, I really don't know enough about the IDE driver and the block
layer to help much here.  :-(

I tried to read the IDE/Block/ISO9660 layers once to figure out why it
sometimes crashes and puts processes into permanent D state, and the
block and fs layers were nice and sensible, but as soon as I hit the IDE
driver I just gave up.  Ugh.  More special cases than code.

People in the mailist list don't seem all that interested, though, but
they're the one with a clue...

-J

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: Help please: DVD ROM read difficulty
@ 2003-03-07  7:49 Guangyu Kang (Shanghai)
  0 siblings, 0 replies; 4+ messages in thread
From: Guangyu Kang (Shanghai) @ 2003-03-07  7:49 UTC (permalink / raw)
  To: 'Elladan'; +Cc: 'linux-kernel@vger.kernel.org'

Elladan, thank you for your reply :)

>I've had to try junk like:
>
>	while true ; do kill -9 $stupid_process ; done
>
>.. just to get something to die when it's reading bad media.
>A quick way around this tends to be to hit the eject button on the CD
>drive itself - it will cause the driver to abort the read quickly when
>it sees that the drive is empty.

You are quite right, this is exactly what I got. Maybe the cache mechanism
will do some check
before send request to the ide-cd driver, and it will abort at that point,
since there is an path
for the failure report.

While to me, this issue is some how player quality related, I have to deal
with it. And you said that
the error handling is not good at all, I think its hopeless for me to hack
into fs and cache. Now I have
an idea in mind to implement an ioctl() set to do this.
Looks like:
CDROM_IOCTL_LOCK
CDROM_IOCTRL_REALTIME_LOGICBLOCK_READ
The lock will make the driver refuse any more open to the driver, thus the
driver can concdern on read
operation from my ioctl while not the reauest. If some one opened the driver
already, lock will fail.
The read will be an re-organize of request handler code, adding more
straight-forward error handling,
which will get data from drive and copy it to user. Without the cache layer,
in player case,
better performance may be the additional gain.

Ugly though, this should be some how easier.

Any comment and advice is welcomed!

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-03-09  5:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-07  2:14 Help please: DVD ROM read difficulty Guangyu Kang (Shanghai)
2003-03-07  6:54 ` Elladan
2003-03-07  7:49 Guangyu Kang (Shanghai)
2003-03-09  5:48 Guangyu Kang (Shanghai)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).