i am not able to read movie dvd's anymore under 2.6.19-rc1. i get the
following in the syslog:
kernel: hdc: read_intr: Drive wants to transfer data the wrong way!
the drive in question is on a thinkpad t40:
kernel: hdc: UJDA745 DVD/CDRW, ATAPI CD/DVD-ROM drive
kernel: hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
i can read the disks under 2.6.18 so it's probably not the drive's
fault. any ideas?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Wed, Oct 11 2006, Alex Romosan wrote:
> i am not able to read movie dvd's anymore under 2.6.19-rc1. i get the
> following in the syslog:
>
> kernel: hdc: read_intr: Drive wants to transfer data the wrong way!
>
> the drive in question is on a thinkpad t40:
>
> kernel: hdc: UJDA745 DVD/CDRW, ATAPI CD/DVD-ROM drive
> kernel: hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
>
> i can read the disks under 2.6.18 so it's probably not the drive's
> fault. any ideas?
Test case, please.
--
Jens Axboe
On Thu, 2006-10-12 at 08:53 +0200, Jens Axboe wrote:
> On Wed, Oct 11 2006, Alex Romosan wrote:
> > i am not able to read movie dvd's anymore under 2.6.19-rc1. i get the
> > following in the syslog:
> >
> > kernel: hdc: read_intr: Drive wants to transfer data the wrong way!
aol
> 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.
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!
-Mike
Ar Mer, 2006-10-11 am 18:45 -0700, ysgrifennodd Alex Romosan:
> i am not able to read movie dvd's anymore under 2.6.19-rc1. i get the
> following in the syslog:
>
> kernel: hdc: read_intr: Drive wants to transfer data the wrong way!
>
> the drive in question is on a thinkpad t40:
>
> kernel: hdc: UJDA745 DVD/CDRW, ATAPI CD/DVD-ROM drive
> kernel: hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
>
> i can read the disks under 2.6.18 so it's probably not the drive's
> fault. any ideas?
What controller is this ?
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
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.
--
Jens Axboe
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
On Thu, 2006-10-12 at 14:09 +0200, Jens Axboe wrote:
> On Thu, Oct 12 2006, Mike Galbraith wrote:
> > 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.
I eyeballed that first off, and didn't see anything suspicious. I'll
have to stare harder I suppose. Thanks.
-Mike
On Thu, 2006-10-12 at 14:21 +0200, Jens Axboe wrote:
> Mike/Alex/Olaf, can you give this a spin? Totally untested here, but I
> think it should fix it.
Yup, all better here. Thanks.
-Mike
> 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,
> };
>
> /*
>
On Thu, Oct 12 2006, Mike Galbraith wrote:
> On Thu, 2006-10-12 at 14:21 +0200, Jens Axboe wrote:
>
> > Mike/Alex/Olaf, can you give this a spin? Totally untested here, but I
> > think it should fix it.
>
> Yup, all better here. Thanks.
Ah that's great, I'll add the patch for inclusion soon.
--
Jens Axboe
Jens Axboe <[email protected]> writes:
> 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,
> };
>
> /*
>
with this patch applied, i can read dvd's now (using mplayer). thanks.
i see this in syslog as the system boots up (it wasn't there before):
Uniform CD-ROM driver Revision: 3.20
ide-cd: bad rq: dev hdc: type=d, flags=1088
sector 0, nr/cnr 0/0
bio 00000000, biotail 00000000, buffer 00000000, data 00000000, len 0
ide-cd: bad rq: dev hdc: type=d, flags=1088
sector 0, nr/cnr 0/0
bio 00000000, biotail 00000000, buffer 00000000, data dff1fe78, len 8
ide-cd: bad rq: dev hdc: type=d, flags=1088
sector 0, nr/cnr 0/0
bio 00000000, biotail 00000000, buffer 00000000, data dfe5140c, len 4
ide-cd: bad rq: dev hdc: type=d, flags=1088
sector 0, nr/cnr 0/0
bio 00000000, biotail 00000000, buffer 00000000, data dfe5140c, len 20
ide-cd: bad rq: dev hdc: type=d, flags=1088
sector 0, nr/cnr 0/0
bio 00000000, biotail 00000000, buffer 00000000, data dff1fea8, len 12
ide-cd: bad rq: dev hdc: type=d, flags=1088
sector 0, nr/cnr 0/0
bio 00000000, biotail 00000000, buffer 00000000, data dff1fe34, len 2
ide-cd: bad rq: dev hdc: type=d, flags=1088
sector 0, nr/cnr 0/0
bio 00000000, biotail 00000000, buffer 00000000, data dff1fe34, len 2
spoke too soon. if i use xine i get this oops:
kernel: sector 0, nr/cnr 0/0
kernel: bio 00000000, biotail 00000000, buffer 00000000, data 00000000, len 0
kernel: ide-cd: bad rq: dev hdc: type=d, flags=88
kernel:
kernel: sector 0, nr/cnr 0/0
kernel: bio 00000000, biotail 00000000, buffer 00000000, data d4e79b44, len 8
kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
kernel: printing eip:
kernel: c0167de9
kernel: *pde = 00000000
kernel: Oops: 0000 [#1]
kernel: PREEMPT
kernel: Modules linked in: radeon drm binfmt_misc nfs sd_mod scsi_mod nfsd exportfs lockd sunrpc autofs4 pcmcia firmware_class joydev irtty_sir sir_dev nsc_ircc irda crc_ccitt parport_pc parport ehci_hcd uhci_hcd usbcore aes_i586 airo nls_iso8859_1 ntfs yenta_socket rsrc_nonstatic pcmcia_core
kernel: CPU: 0
kernel: EIP: 0060:[<c0167de9>] Not tainted VLI
kernel: EFLAGS: 00010292 (2.6.19-rc1 #202)
kernel: EIP is at create_empty_buffers+0x13/0x8d
kernel: eax: 00000000 ebx: c1276fe0 ecx: 00000001 edx: 00002000
kernel: esi: 00000000 edi: 00000000 ebp: c1276fe0 esp: d4e79cf4
kernel: ds: 007b es: 007b ss: 0068
kernel: Process xine (pid: 3767, ti=d4e78000 task=da77ea70 task.ti=d4e78000)
kernel: Stack: c1276fe0 00000000 c146dda0 c0169b20 c035c3d4 c016c134 00000001 c146dcfc
kernel: 00000000 c035c3d4 000201d0 00002000 c1276fe0 00000000 fffffffa c1276fe0
kernel: c146dda0 00000000 00000000 c0134270 c1276fe0 c1276fe0 00000000 c146dda0
kernel: Call Trace:
kernel: [<c0169b20>] block_read_full_page+0x4d/0x248
kernel: [<c016c134>] blkdev_get_block+0x0/0x33
kernel: [<c0134270>] add_to_page_cache+0x99/0xb3
kernel: [<c01397a8>] __do_page_cache_readahead+0x1b5/0x20e
kernel: [<c0184267>] inode2sd+0x122/0x137
kernel: [<c01935e8>] pathrelse+0x15/0x24
kernel: [<c0184976>] reiserfs_update_sd_size+0x236/0x23e
kernel: [<c0139847>] blockable_page_cache_readahead+0x46/0x99
kernel: [<c01399d9>] page_cache_readahead+0xb2/0x177
kernel: [<c01346b7>] do_generic_mapping_read+0x14b/0x436
kernel: [<c01364e5>] generic_file_aio_read+0x1ac/0x1f7
kernel: [<c0133eb9>] file_read_actor+0x0/0xc1
kernel: [<c014c8bd>] do_sync_read+0xc2/0x101
kernel: [<c0127389>] autoremove_wake_function+0x0/0x2d
kernel: [<c014b7c1>] do_filp_open+0x2b/0x31
kernel: [<c014c7fb>] do_sync_read+0x0/0x101
kernel: [<c014d015>] vfs_read+0x81/0x123
kernel: [<c014d3c0>] sys_read+0x3c/0x63
kernel: [<c0102cbf>] syscall_call+0x7/0xb
kernel: [<c02f007b>] __sched_text_start+0x123/0x560
kernel: =======================
kernel: Code: 74 0a e8 1e ff ff ff e9 68 ff ff ff 31 f6 83 c4 0c 89 f0 5b 5e 5f 5d c3 57 89 cf 56 b9 01 00 00 00 53 89 c3 e8 3b ff ff ff 89 c6 <8b> 50 04 09 38 85 d2 74 04 89 d0 eb f3 89 70 04 b8 01 00 00 00
kernel: EIP: [<c0167de9>] create_empty_buffers+0x13/0x8d SS:ESP 0068:d4e79cf4
not sure where this came from.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Thu, Oct 12 2006, Alex Romosan wrote:
> Jens Axboe <[email protected]> writes:
>
> > 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,
> > };
> >
> > /*
> >
>
> with this patch applied, i can read dvd's now (using mplayer). thanks.
> i see this in syslog as the system boots up (it wasn't there before):
Argh damn, it needs this on top of it as well. Your second problem
likely stems from that missing bit, please retest with this one applied
as well.
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index e7513e5..bddfebd 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -716,7 +716,7 @@ static int cdrom_decode_status(ide_drive
ide_error(drive, "request sense failure", stat);
return 1;
- } else if (blk_pc_request(rq)) {
+ } else if (blk_pc_request(rq) || rq->cmd_type == REQ_TYPE_ATA_PC) {
/* All other functions, except for READ. */
unsigned long flags;
--
Jens Axboe
Jens Axboe <[email protected]> writes:
> Argh damn, it needs this on top of it as well. Your second problem
> likely stems from that missing bit, please retest with this one applied
> as well.
>
> diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> index e7513e5..bddfebd 100644
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -716,7 +716,7 @@ static int cdrom_decode_status(ide_drive
> ide_error(drive, "request sense failure", stat);
> return 1;
>
> - } else if (blk_pc_request(rq)) {
> + } else if (blk_pc_request(rq) || rq->cmd_type == REQ_TYPE_ATA_PC) {
> /* All other functions, except for READ. */
> unsigned long flags;
>
please ignore my previous message, i am an idiot. if i actually put a
dvd in the drive then this patch works as expected. sorry for the
noise.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Thu, 2006-10-12 at 08:47 -0700, Alex Romosan wrote:
> Jens Axboe <[email protected]> writes:
>
> > Argh damn, it needs this on top of it as well. Your second problem
> > likely stems from that missing bit, please retest with this one applied
> > as well.
> >
> > diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> > index e7513e5..bddfebd 100644
> > --- a/drivers/ide/ide-cd.c
> > +++ b/drivers/ide/ide-cd.c
> > @@ -716,7 +716,7 @@ static int cdrom_decode_status(ide_drive
> > ide_error(drive, "request sense failure", stat);
> > return 1;
> >
> > - } else if (blk_pc_request(rq)) {
> > + } else if (blk_pc_request(rq) || rq->cmd_type == REQ_TYPE_ATA_PC) {
> > /* All other functions, except for READ. */
> > unsigned long flags;
> >
>
> no more strange messages but, once again, i am not able to read movie
> dvd's with the above patch applied.
Hmm. Xine still works fine here.
I tried starting xine with no dvd in the drive for grins, and _without_
this patch, I had to resort to SysRq-E to regain control of my box, and
that still took quite a while. I got no oops, but a zillion IO retries
and sector blah messages. DoSed me bigtime. With this patch, I just
got the expected can't open failure.
-Mike
Mike Galbraith <[email protected]> writes:
> On Thu, 2006-10-12 at 08:47 -0700, Alex Romosan wrote:
>> Jens Axboe <[email protected]> writes:
>>
>> > Argh damn, it needs this on top of it as well. Your second problem
>> > likely stems from that missing bit, please retest with this one applied
>> > as well.
>> >
>> > diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
>> > index e7513e5..bddfebd 100644
>> > --- a/drivers/ide/ide-cd.c
>> > +++ b/drivers/ide/ide-cd.c
>> > @@ -716,7 +716,7 @@ static int cdrom_decode_status(ide_drive
>> > ide_error(drive, "request sense failure", stat);
>> > return 1;
>> >
>> > - } else if (blk_pc_request(rq)) {
>> > + } else if (blk_pc_request(rq) || rq->cmd_type == REQ_TYPE_ATA_PC) {
>> > /* All other functions, except for READ. */
>> > unsigned long flags;
>> >
>>
>> no more strange messages but, once again, i am not able to read movie
>> dvd's with the above patch applied.
>
> Hmm. Xine still works fine here.
>
> I tried starting xine with no dvd in the drive for grins, and _without_
> this patch, I had to resort to SysRq-E to regain control of my box, and
> that still took quite a while. I got no oops, but a zillion IO retries
> and sector blah messages. DoSed me bigtime. With this patch, I just
> got the expected can't open failure.
works fine for me too as i said in my next message (i initially forgot
to put the dvd in the drive). i guess this is what happens when i try
to test things before my morning espresso...
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Thu, Oct 12 2006, Alex Romosan wrote:
> Jens Axboe <[email protected]> writes:
>
> > Argh damn, it needs this on top of it as well. Your second problem
> > likely stems from that missing bit, please retest with this one applied
> > as well.
> >
> > diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> > index e7513e5..bddfebd 100644
> > --- a/drivers/ide/ide-cd.c
> > +++ b/drivers/ide/ide-cd.c
> > @@ -716,7 +716,7 @@ static int cdrom_decode_status(ide_drive
> > ide_error(drive, "request sense failure", stat);
> > return 1;
> >
> > - } else if (blk_pc_request(rq)) {
> > + } else if (blk_pc_request(rq) || rq->cmd_type == REQ_TYPE_ATA_PC) {
> > /* All other functions, except for READ. */
> > unsigned long flags;
> >
>
> please ignore my previous message, i am an idiot. if i actually put a
> dvd in the drive then this patch works as expected. sorry for the
> noise.
Good, thanks for the update :-)
--
Jens Axboe
On Thu, Oct 12 2006, Mike Galbraith wrote:
> On Thu, 2006-10-12 at 08:47 -0700, Alex Romosan wrote:
> > Jens Axboe <[email protected]> writes:
> >
> > > Argh damn, it needs this on top of it as well. Your second problem
> > > likely stems from that missing bit, please retest with this one applied
> > > as well.
> > >
> > > diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> > > index e7513e5..bddfebd 100644
> > > --- a/drivers/ide/ide-cd.c
> > > +++ b/drivers/ide/ide-cd.c
> > > @@ -716,7 +716,7 @@ static int cdrom_decode_status(ide_drive
> > > ide_error(drive, "request sense failure", stat);
> > > return 1;
> > >
> > > - } else if (blk_pc_request(rq)) {
> > > + } else if (blk_pc_request(rq) || rq->cmd_type == REQ_TYPE_ATA_PC) {
> > > /* All other functions, except for READ. */
> > > unsigned long flags;
> > >
> >
> > no more strange messages but, once again, i am not able to read movie
> > dvd's with the above patch applied.
>
> Hmm. Xine still works fine here.
>
> I tried starting xine with no dvd in the drive for grins, and _without_
> this patch, I had to resort to SysRq-E to regain control of my box, and
> that still took quite a while. I got no oops, but a zillion IO retries
> and sector blah messages. DoSed me bigtime. With this patch, I just
> got the expected can't open failure.
Yeah, the problem if you don't have this extra one-liner is that error
handling gets totally screwed. Everything should be fine in Linus' tree
now, he has everything.
--
Jens Axboe
On Thu, Oct 12, Jens Axboe wrote:
> Mike/Alex/Olaf, can you give this a spin? Totally untested here, but I
> think it should fix it.
Current Linus tree detects the DVD again on my G5.
On Thu, Oct 12 2006, Olaf Hering wrote:
> On Thu, Oct 12, Jens Axboe wrote:
>
> > Mike/Alex/Olaf, can you give this a spin? Totally untested here, but I
> > think it should fix it.
>
> Current Linus tree detects the DVD again on my G5.
Super, so it was the same bug as expected. Thanks for retesting.
--
Jens Axboe
Jens Axboe <[email protected]> writes:
> On Thu, Oct 12 2006, Alex Romosan wrote:
>>
>> please ignore my previous message, i am an idiot. if i actually put a
>> dvd in the drive then this patch works as expected. sorry for the
>> noise.
>
> Good, thanks for the update :-)
looks like the dvd problem was fixed but this morning i got the same
message:
kernel: hdc: write_intr: wrong transfer direction!
trying to rip a cd with grip (cdparanoia). the process is stuck, i
can't kill it, and it's not making any more progress (but it still has
the smiling face so it probably thinks everything's fine). sysrq-t
shows this:
kernel: grip D 00000007 0 17133 3835 16719 (NOTLB)
kernel: d9677bac 00200082 d0ad2a70 00000007 d0ad2a70 23f93e80 000031a2 00000000
kernel: d0ad2b7c 00000000 d9677c44 540ae480 00000000 da8d7740 d9677c44 dfe9679c
kernel: d9677bc8 d9677bd0 c02f06ac 00000001 d0ad2a70 c011486c d9677c48 d9677c48
kernel: Call Trace:
kernel: [<c02f06ac>] wait_for_completion+0x85/0xd5
kernel: [<c011486c>] default_wake_function+0x0/0xc
kernel: [<c01b619d>] blk_execute_rq+0x78/0x8b
kernel: [<c01b59cf>] blk_end_sync_rq+0x0/0x23
kernel: [<c01b4c97>] blk_rq_bio_prep+0x28/0x7c
kernel: [<c01b8eb2>] sg_io+0x253/0x34e
kernel: [<c01b93ec>] scsi_cmd_ioctl+0x1ab/0x357
kernel: [<c01256a9>] __rcu_process_callbacks+0xf4/0x178
kernel: [<c011baf5>] tasklet_action+0x37/0x5c
kernel: [<c011ba67>] __do_softirq+0x59/0x85
kernel: [<c0118a2f>] profile_tick+0x3d/0x4e
kernel: [<c0258582>] cdrom_ioctl+0x22/0xb30
kernel: [<c0156228>] send_sigio+0x13b/0x146
kernel: [<c025301c>] idecd_ioctl+0x12d/0x142
kernel: [<c011ee00>] do_timer+0x679/0x6ff
kernel: [<c01b7a87>] blkdev_driver_ioctl+0x4b/0x5b
kernel: [<c01b80d8>] blkdev_ioctl+0x641/0x691
kernel: [<c0217a93>] add_timer_randomness+0x106/0x120
kernel: [<c025d3c0>] input_event+0x33/0x40e
kernel: [<c025d77a>] input_event+0x3ed/0x40e
kernel: [<c0137adf>] get_page_from_freelist+0x72/0x2f7
kernel: [<c0137c33>] get_page_from_freelist+0x1c6/0x2f7
kernel: [<c0137f1a>] __alloc_pages+0x4e/0x267
kernel: [<c013a250>] lru_cache_add_active+0x47/0x5d
kernel: [<c013e5d1>] __handle_mm_fault+0x458/0x7e4
kernel: [<c016b3e6>] block_ioctl+0x10/0x13
kernel: [<c016b3d6>] block_ioctl+0x0/0x13
kernel: [<c0156b08>] do_ioctl+0x1c/0x5d
kernel: [<c0156d90>] vfs_ioctl+0x247/0x25a
kernel: [<c0156dcf>] sys_ioctl+0x2c/0x45
kernel: [<c0102cbf>] syscall_call+0x7/0xb
kernel: [<c02f007b>] __sched_text_start+0x123/0x560
let me know if i can help debug this.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
Hi Alex,
Can you retest with this? This must be where the wrong write bit comes
from.
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 2dc3264..a19338e 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -246,10 +246,10 @@ static int sg_io(struct file *file, requ
switch (hdr->dxfer_direction) {
default:
return -EINVAL;
- case SG_DXFER_TO_FROM_DEV:
case SG_DXFER_TO_DEV:
writing = 1;
break;
+ case SG_DXFER_TO_FROM_DEV:
case SG_DXFER_FROM_DEV:
break;
}
--
Jens Axboe
Jens Axboe <[email protected]> writes:
> Can you retest with this? This must be where the wrong write bit comes
> from.
>
> diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
> index 2dc3264..a19338e 100644
> --- a/block/scsi_ioctl.c
> +++ b/block/scsi_ioctl.c
> @@ -246,10 +246,10 @@ static int sg_io(struct file *file, requ
> switch (hdr->dxfer_direction) {
> default:
> return -EINVAL;
> - case SG_DXFER_TO_FROM_DEV:
> case SG_DXFER_TO_DEV:
> writing = 1;
> break;
> + case SG_DXFER_TO_FROM_DEV:
> case SG_DXFER_FROM_DEV:
> break;
> }
>
i think this finally got it to work! when i start cdparanoia now i get
(all the previous debug patches are still applied):
kernel: ide-cd: starting INQ da76fee4
kernel: ide-cd: newpc da76fee4
kernel: ide-cd: newpc da76fee4
kernel: ide-cd: newpc end INQ da76fee4
and then when it gets to the parts where the cd might have some
problems i get a bunch of:
kernel: hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
kernel: hdc: packet command error: error=0xb4 { AbortedCommand LastFailedSense=0x0b }
kernel: ide: failed opcode was: unknown
kernel: ATAPI device hdc:
kernel: Error: Aborted command -- (Sense key=0x0b)
kernel: (reserved error code) -- (asc=0x11, ascq=0x11)
kernel: The failed "Read CD" packet command was:
kernel: "be 00 00 00 51 93 00 00 0d f8 00 00 00 00 00 00 "
but cdparanoia continues (albeit more slowly) and eventually finishes.
thank you!
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Fri, Nov 10 2006, Alex Romosan wrote:
> Jens Axboe <[email protected]> writes:
>
> > Can you retest with this? This must be where the wrong write bit comes
> > from.
> >
> > diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
> > index 2dc3264..a19338e 100644
> > --- a/block/scsi_ioctl.c
> > +++ b/block/scsi_ioctl.c
> > @@ -246,10 +246,10 @@ static int sg_io(struct file *file, requ
> > switch (hdr->dxfer_direction) {
> > default:
> > return -EINVAL;
> > - case SG_DXFER_TO_FROM_DEV:
> > case SG_DXFER_TO_DEV:
> > writing = 1;
> > break;
> > + case SG_DXFER_TO_FROM_DEV:
> > case SG_DXFER_FROM_DEV:
> > break;
> > }
> >
>
> i think this finally got it to work! when i start cdparanoia now i get
> (all the previous debug patches are still applied):
>
> kernel: ide-cd: starting INQ da76fee4
> kernel: ide-cd: newpc da76fee4
> kernel: ide-cd: newpc da76fee4
> kernel: ide-cd: newpc end INQ da76fee4
>
> and then when it gets to the parts where the cd might have some
> problems i get a bunch of:
>
> kernel: hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
> kernel: hdc: packet command error: error=0xb4 { AbortedCommand LastFailedSense=0x0b }
> kernel: ide: failed opcode was: unknown
> kernel: ATAPI device hdc:
> kernel: Error: Aborted command -- (Sense key=0x0b)
> kernel: (reserved error code) -- (asc=0x11, ascq=0x11)
> kernel: The failed "Read CD" packet command was:
> kernel: "be 00 00 00 51 93 00 00 0d f8 00 00 00 00 00 00 "
>
> but cdparanoia continues (albeit more slowly) and eventually finishes.
> thank you!
Great, problem fixed then, patch is already merged upstream so 2.6.19
and next -rc (if any :-) should work. Thanks for your persistent
testing.
--
Jens Axboe
Jens Axboe <[email protected]> writes:
> Great, problem fixed then, patch is already merged upstream so
> 2.6.19 and next -rc (if any :-) should work. Thanks for your
> persistent testing.
i've played with this a little bit more over the weekend. sometimes
cdparanoia gets stuck trying to read some sector. with your patches i
can now stop the process and restart it, and without touching the cd
at all this next time cdparanoia finishes just fine. usually this
happens after i try to rip a series of tracks so i wonder if some
error counters don't get reset or something like that. maybe this is
the expected behaviour, but i don't think i saw cdparanoia get stuck
on the first track ever, usually it happens after some time.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Mon, Nov 13 2006, Alex Romosan wrote:
> Jens Axboe <[email protected]> writes:
>
> > Great, problem fixed then, patch is already merged upstream so
> > 2.6.19 and next -rc (if any :-) should work. Thanks for your
> > persistent testing.
>
> i've played with this a little bit more over the weekend. sometimes
> cdparanoia gets stuck trying to read some sector. with your patches i
> can now stop the process and restart it, and without touching the cd
> at all this next time cdparanoia finishes just fine. usually this
> happens after i try to rip a series of tracks so i wonder if some
> error counters don't get reset or something like that. maybe this is
> the expected behaviour, but i don't think i saw cdparanoia get stuck
> on the first track ever, usually it happens after some time.
There is a second error handling patch merged with the first patch as
well, perhaps it'll help you out. Attached here as well.
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index bddfebd..8821494 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -724,7 +724,7 @@ static int cdrom_decode_status(ide_drive
* if we have an error, pass back CHECK_CONDITION as the
* scsi status byte
*/
- if (!rq->errors)
+ if (blk_pc_request(rq) && !rq->errors)
rq->errors = SAM_STAT_CHECK_CONDITION;
/* Check for tray open. */
--
Jens Axboe
Jens Axboe <[email protected]> writes:
> There is a second error handling patch merged with the first patch as
> well, perhaps it'll help you out. Attached here as well.
>
> diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> index bddfebd..8821494 100644
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -724,7 +724,7 @@ static int cdrom_decode_status(ide_drive
> * if we have an error, pass back CHECK_CONDITION as the
> * scsi status byte
> */
> - if (!rq->errors)
> + if (blk_pc_request(rq) && !rq->errors)
> rq->errors = SAM_STAT_CHECK_CONDITION;
>
> /* Check for tray open. */
>
tried it again with this patch (on top of all the other patches).
overall things are much better than they've been in a long time
(thanks!), but... when cdparanoia gets stuck, if i abort the process
and restart it the ripping proceeds very slowly (~5x before, ~1.5x
after). if i eject/insert the cd and then restart cdparanoia the speed
is as before (~5x). something doesn't get reset until the cd is
ejected, don't know if it's the kernel's fault though. same thing
happens if i get an error reading a sector but then cdparanoia manages
to recover. from that point on the speed is very slow (again until i
eject/insert the cd; a new instance of cdparanoia is just as slow).
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Tue, Nov 14 2006, Alex Romosan wrote:
> Jens Axboe <[email protected]> writes:
>
> > There is a second error handling patch merged with the first patch as
> > well, perhaps it'll help you out. Attached here as well.
> >
> > diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> > index bddfebd..8821494 100644
> > --- a/drivers/ide/ide-cd.c
> > +++ b/drivers/ide/ide-cd.c
> > @@ -724,7 +724,7 @@ static int cdrom_decode_status(ide_drive
> > * if we have an error, pass back CHECK_CONDITION as the
> > * scsi status byte
> > */
> > - if (!rq->errors)
> > + if (blk_pc_request(rq) && !rq->errors)
> > rq->errors = SAM_STAT_CHECK_CONDITION;
> >
> > /* Check for tray open. */
> >
>
> tried it again with this patch (on top of all the other patches).
> overall things are much better than they've been in a long time
> (thanks!), but... when cdparanoia gets stuck, if i abort the process
> and restart it the ripping proceeds very slowly (~5x before, ~1.5x
> after). if i eject/insert the cd and then restart cdparanoia the speed
> is as before (~5x). something doesn't get reset until the cd is
> ejected, don't know if it's the kernel's fault though. same thing
> happens if i get an error reading a sector but then cdparanoia manages
> to recover. from that point on the speed is very slow (again until i
> eject/insert the cd; a new instance of cdparanoia is just as slow).
When cdparanoia gets stuck, how is it stuck? Can you give me a backtrace
of that? If you can abort it, sounds like it isn't stuck in the kernel.
--
Jens Axboe
Jens Axboe <[email protected]> writes:
> When cdparanoia gets stuck, how is it stuck? Can you give me a
> backtrace of that? If you can abort it, sounds like it isn't stuck
> in the kernel.
i don't have my laptop with me but the error message i get in syslog
is somewhere along the lines of (this is copied from the initial bug
report):
kernel: ATAPI device hdc:
kernel: Error: Aborted command -- (Sense key=0x0b)
kernel: (reserved error code) -- (asc=0x11, ascq=0x11)
kernel: The failed "Read CD" packet command was:
kernel: "be 00 00 00 51 93 00 00 0d f8 00 00 00 00 00 00 "
kernel: hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
kernel: hdc: packet command error: error=0x30 { LastFailedSense=0x03 }
kernel: ide: failed opcode was: unknown
kernel: ATAPI device hdc:
kernel: Error: Medium error -- (Sense key=0x03)
kernel: Unrecovered read error -- (asc=0x11, ascq=0x00)
kernel: The failed "Read CD" packet command was:
kernel: "be 00 00 00 51 a0 00 00 07 f8 00 00 00 00 00 00 "
kernel: hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
kernel: hdc: packet command error: error=0xb4 { AbortedCommand LastFailedSense=0x0b }
kernel: ide: failed opcode was: unknown
kernel: ATAPI device hdc:
kernel: Error: Aborted command -- (Sense key=0x0b)
kernel: (reserved error code) -- (asc=0x11, ascq=0x11)
kernel: The failed "Read CD" packet command was:
kernel: "be 00 00 00 51 9b 00 00 0d f8 00 00 00 00 00 00 "
and i assume cdparanoia has problems reading that particular sector
and then it retries and i get similar messages every 5 seconds.
sometimes it recovers from this, at other times it's just stuck there
trying to read the same sector over and over again.
but after i get this message the ripping speed is greatly reduced
until i eject/insert the cd. then the speed goes back to normal. it
doesn't matter if cdparanoia recovers, or if i start a new cdparanoia
process, only if i eject/insert the cd. does this make sense?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |