Hello, Harald Dunkel wrote: > Hi Tejun, > > Sorry to say, but after applying your patch it still doesn't work. > > If I insert the DVD and wait before running xine, then I can watch > it. But if I keep the tray open and run xine, then xine closes > the tray. It gets stuck for some time, and then I get > > % xine dvd:/dev/scd0 > This is xine (X11 gui) - a free video player v0.99.5cvs. > (c) 2000-2006 The xine Team. > libdvdread: Using libdvdcss version 1.2.9 for DVD access > libdvdread: Could not open /dev/scd0 with libdvdcss. > libdvdread: Can't open /dev/scd0 for reading > > > kern.log says: [--snip--] > May 9 19:13:04 pluto kernel: ata2.00: configured for UDMA/33 > May 9 19:13:04 pluto kernel: ata2: EH complete The patch wasn't trying to fix the original problem. All it does it making sure the device itself doesn't get disabled after such an event - /dev/sr0 should be accessible even after garbled IDENTIFY. Can you try to trigger the condition where the device reports garbled IDENTIFY data and says... ata2.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0) Without the patch, the device will be offlined so you can't use it anymore unless you issue manual rescan or unplug and replug the device. With the patch, you should be able to access the device after EH is complete. > After that (the DVD is still in) I can rerun xine, and it works. > This is reproducible using CSS DVDs. Using a DVD without CSS there > is no such problem. It takes some time till the DVD is played, > but there is no soft reset. > > Using "gmplayer dvd://" I get the same problem. > > You told me some time ago that you bought the same drive. Can you > reproduce this problem? Please don't get me wrong, I am glad to > support you by trying out new patches. I'd love to but I'm half globe away from my toys at the moment and not going back till the end of this month, so.... If this isn't resolved till I get back, I'll test myself. It still could be that the dvd reading commands are issued with too short timeout. Does applying the attached patch make any difference? -- tejun
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c index 3625a05..e404464 100644 --- a/drivers/cdrom/cdrom.c +++ b/drivers/cdrom/cdrom.c @@ -341,7 +341,7 @@ static const char *mrw_address_space[] = * Another popular OS uses 7 seconds as the hard timeout for default * commands, so it is a good choice for us as well. */ -#define CDROM_DEF_TIMEOUT (7 * HZ) +#define CDROM_DEF_TIMEOUT (15 * HZ) /* Not-exported routines. */ static int open_for_data(struct cdrom_device_info * cdi);
