Re: 2.6.19-rc1 regression: unable to read dvd's

From: Jens Axboe
Date: Thu Oct 12 2006 - 08:22:04 EST


On Thu, Oct 12 2006, Jens Axboe wrote:
> On Thu, Oct 12 2006, Mike Galbraith wrote:
> > On Thu, 2006-10-12 at 10:28 +0000, Mike Galbraith wrote:
> > > On Thu, 2006-10-12 at 08:53 +0200, Jens Axboe wrote:
> > > > Test case, please.
> > >
> > > Xine.
> > >
> > > I just built it from scratch(the one that comes with SuSE 10.1 is
> > > useless for DVDs), and tried it in 2.6.19-rc1 after verifying that it
> > > worked fine in 2.6.17.
> >
> > s/17/18
> >
> > > hdd: BENQ DVD DD DW1625, ATAPI CD/DVD-ROM drive
> > > hdd: ATAPI 63X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
> > >
> > > hdd: read_intr: Drive wants to transfer data the wrong way!
> > > hdd: read_intr: Drive wants to transfer data the wrong way!
> >
> > We're having secret handshake troubles?
> >
> > [pid 8348] stat64("/dev/dvd", {st_dev=makedev(0, 13), st_ino=3750, st_mode=S_IFBLK|0640, st_nlink=1, st_uid=0, st_gid=6, st_blksize=4096, st_blocks=0, st_rdev=makedev(22, 64), st_atime=2006/10/12-10:03:04, st_mtime=2006/10/12-10:00:12, st_ctime=2006/10/12-10:00:17}) = 0
> > [pid 8348] open("/dev/dvd", O_RDONLY|O_LARGEFILE <unfinished ...>
> > [pid 8348] <... open resumed> ) = 8
> > [pid 8348] fstat64(8, {st_dev=makedev(0, 13), st_ino=3750, st_mode=S_IFBLK|0640, st_nlink=1, st_uid=0, st_gid=6, st_blksize=4096, st_blocks=0, st_rdev=makedev(22, 64), st_atime=2006/10/12-10:03:04, st_mtime=2006/10/12-10:00:12, st_ctime=2006/10/12-10:00:17}) = 0
> > [pid 8348] ioctl(8, DVD_READ_STRUCT <unfinished ...>
> > [pid 8348] <... ioctl resumed> , 0xbfc792a4) = 0
> > [pid 8348] ioctl(8, DVD_AUTH <unfinished ...>
> > [pid 8348] <... ioctl resumed> , 0xbfc7916c) = 0
> > [pid 8348] ioctl(8, DVD_AUTH <unfinished ...>
> > [pid 8348] <... ioctl resumed> , 0xbfc7916c) = 0
> > [pid 8348] ioctl(8, DVD_AUTH <unfinished ...>
> > [pid 8348] <... ioctl resumed> , 0xbfc7916c) = 0
> > [pid 8348] ioctl(8, DVD_AUTH <unfinished ...>
> > [pid 8348] <... ioctl resumed> , 0xbfc79170) = 0
> > [pid 8348] close(8) = 0
> > [pid 8348] write(2, "libdvdread: Could not open /dev/"..., 52 <unfinished ...>
> > [pid 8348] <... write resumed> ) = 52
> > [pid 8348] write(2, "libdvdread: Can\'t open /dev/dvd "..., 44 <unfinished ...>
> > [pid 8348] <... write resumed> ) = 44
> > [pid 8348] write(1, "libdvdnav: vm: faild to open/rea"..., 42 <unfinished ...>
> > [pid 8348] <... write resumed> ) = 42
> > [pid 8348] write(1, "libdvdnav: Using dvdnav version "..., 62 <unfinished ...>
> > [pid 8348] <... write resumed> ) = 62
> > [pid 8348] write(2, "libdvdread: Using libdvdcss vers"..., 57 <unfinished ...>
> > [pid 8348] <... write resumed> ) = 57
>
> It's the rq-cmd-type patch, it must be causing a disturbance for some of
> the internal cd commands. I bet it's the same thing affecting the report
> on broken dvd identification on ppc from Olaf.

Mike/Alex/Olaf, can you give this a spin? Totally untested here, but I
think it should fix it.

diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 69bbb62..e7513e5 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -597,7 +597,7 @@ static void cdrom_prepare_request(ide_dr
struct cdrom_info *cd = drive->driver_data;

ide_init_drive_cmd(rq);
- rq->cmd_type = REQ_TYPE_BLOCK_PC;
+ rq->cmd_type = REQ_TYPE_ATA_PC;
rq->rq_disk = cd->disk;
}

@@ -2023,7 +2023,8 @@ ide_do_rw_cdrom (ide_drive_t *drive, str
}
info->last_block = block;
return action;
- } else if (rq->cmd_type == REQ_TYPE_SENSE) {
+ } else if (rq->cmd_type == REQ_TYPE_SENSE ||
+ rq->cmd_type == REQ_TYPE_ATA_PC) {
return cdrom_do_packet_command(drive);
} else if (blk_pc_request(rq)) {
return cdrom_do_block_pc(drive, rq);
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 26f7856..d370d2c 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -157,6 +157,7 @@ enum rq_cmd_type_bits {
REQ_TYPE_ATA_CMD,
REQ_TYPE_ATA_TASK,
REQ_TYPE_ATA_TASKFILE,
+ REQ_TYPE_ATA_PC,
};

/*

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/