hi all,
Whatever I tried, I couldn't get my DVDs read. I get:
sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
or, I don't use ide-scsi, i get the ATAPI equivalent.
I have udf support compiled in, i have successfully authenticated the
disk(s), but lo luck.
The drive is:
Vendor: PIONEER Model: DVD-ROM DVD-105 Rev: 1.22
I tried 2.2.17, 2.4.1 & 2.4.2 (and a few different compiled versions of
them)
What might be the problem?
Balazs Pozsar.
On Wed, Mar 07 2001, Pozsar Balazs wrote:
>
> hi all,
>
> Whatever I tried, I couldn't get my DVDs read. I get:
> sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
> or, I don't use ide-scsi, i get the ATAPI equivalent.
> I have udf support compiled in, i have successfully authenticated the
> disk(s), but lo luck.
>
> The drive is:
> Vendor: PIONEER Model: DVD-ROM DVD-105 Rev: 1.22
>
> I tried 2.2.17, 2.4.1 & 2.4.2 (and a few different compiled versions of
> them)
>
> What might be the problem?
I don't know, you provide virtually no information. Use the ATAPI
driver, and dump dmesg info when this happens. Then send that along.
--
Jens Axboe
Details: (dmesg)
Linux version 2.4.2-3mdk ([email protected]) (gcc version
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Feb 27 02:14:17
CET 2001
...
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio, hdd:DMA
HPT370: IDE controller on PCI bus 00 dev 70
PCI: Found IRQ 11 for device 00:0e.0
HPT370: chipset revision 3
HPT370: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio
hdd: Pioneer DVD-ROM ATAPIModel DVD-105S 012, ATAPI CD/DVD-ROM drive
hdg: QUANTUM FIREBALLlct20 20, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
ide3 at 0xe400-0xe407,0xe802 on irq 11
hdg: 39876480 sectors (20417 MB) w/418KiB Cache, CHS=39560/16/63,
UDMA(100)
hdd: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
hdg: hdg1 hdg2 hdg3 hdg4
...
When I run "dvdinfo /dev/hdd" I get:
Disc is encrypted.
Layer 0[3]
Book Version: 0
Book Type: 13
Min Rate: 0
Disc Size: 0
Layer Type: 0
Track Path: 1
Num Layers: 2
Track Density: 0
Linear Density: 0
BCA: 1
Start Sector 0xd000
End Sector 0xd000
End Sector L0 0xd000
Layer 1[3]
Book Version: 0
Book Type: 13
Min Rate: 0
Disc Size: 0
Layer Type: 0
Track Path: 1
Num Layers: 2
Track Density: 0
Linear Density: 0
BCA: 1
Start Sector 0xd000
End Sector 0x1d000
End Sector L0 0xd000
hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdd: packet command error: error=0x50
ATAPI device hdd:
Error: Illegal request -- (Sense key=0x05)
Invalid field in command packet -- (asc=0x24, ascq=0x00)
The failed "Send DVD Structure" packet command was:
"ad 00 00 00 00 00 02 00 00 54 00 00 "
Could not read Physical layer 2
Copyright: CPST=1, RMI=0xfd
I also get this in syslog:
hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdd: packet command error: error=0x50
ATAPI device hdd:
Error: Illegal request -- (Sense key=0x05)
Invalid field in command packet -- (asc=0x24, ascq=0x00)
The failed "Send DVD Structure" packet command was:
"ad 00 00 00 00 00 02 00 00 54 00 00 "
Tell me i can give you any more info.
Balazs Pozsar.
On Wed, 7 Mar 2001, Jens Axboe wrote:
> On Wed, Mar 07 2001, Pozsar Balazs wrote:
> >
> > hi all,
> >
> > Whatever I tried, I couldn't get my DVDs read. I get:
> > sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
> > or, I don't use ide-scsi, i get the ATAPI equivalent.
> > I have udf support compiled in, i have successfully authenticated the
> > disk(s), but lo luck.
> >
> > The drive is:
> > Vendor: PIONEER Model: DVD-ROM DVD-105 Rev: 1.22
> >
> > I tried 2.2.17, 2.4.1 & 2.4.2 (and a few different compiled versions of
> > them)
> >
> > What might be the problem?
>
> I don't know, you provide virtually no information. Use the ATAPI
> driver, and dump dmesg info when this happens. Then send that along.
>
>
On Wed, Mar 07 2001, Pozsar Balazs wrote:
> Details: (dmesg)
>
> Linux version 2.4.2-3mdk ([email protected]) (gcc version
> egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Feb 27 02:14:17
> CET 2001
> ...
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> VP_IDE: IDE controller on PCI bus 00 dev 39
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
> ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:pio, hdb:pio
> ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio, hdd:DMA
> HPT370: IDE controller on PCI bus 00 dev 70
> PCI: Found IRQ 11 for device 00:0e.0
> HPT370: chipset revision 3
> HPT370: not 100% native mode: will probe irqs later
> ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:pio, hdf:pio
> ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio
> hdd: Pioneer DVD-ROM ATAPIModel DVD-105S 012, ATAPI CD/DVD-ROM drive
> hdg: QUANTUM FIREBALLlct20 20, ATA DISK drive
> ide1 at 0x170-0x177,0x376 on irq 15
> ide3 at 0xe400-0xe407,0xe802 on irq 11
> hdg: 39876480 sectors (20417 MB) w/418KiB Cache, CHS=39560/16/63,
> UDMA(100)
> hdd: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.12
> Partition check:
> hdg: hdg1 hdg2 hdg3 hdg4
> ...
>
>
>
> When I run "dvdinfo /dev/hdd" I get:
> Disc is encrypted.
> Layer 0[3]
> Book Version: 0
> Book Type: 13
> Min Rate: 0
> Disc Size: 0
> Layer Type: 0
> Track Path: 1
> Num Layers: 2
> Track Density: 0
> Linear Density: 0
> BCA: 1
> Start Sector 0xd000
> End Sector 0xd000
> End Sector L0 0xd000
> Layer 1[3]
> Book Version: 0
> Book Type: 13
> Min Rate: 0
> Disc Size: 0
> Layer Type: 0
> Track Path: 1
> Num Layers: 2
> Track Density: 0
> Linear Density: 0
> BCA: 1
> Start Sector 0xd000
> End Sector 0x1d000
> End Sector L0 0xd000
> hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
> hdd: packet command error: error=0x50
> ATAPI device hdd:
> Error: Illegal request -- (Sense key=0x05)
> Invalid field in command packet -- (asc=0x24, ascq=0x00)
> The failed "Send DVD Structure" packet command was:
> "ad 00 00 00 00 00 02 00 00 54 00 00 "
> Could not read Physical layer 2
> Copyright: CPST=1, RMI=0xfd
I don't know the program you mention, but it's definitely buggy. It
sets byte 6 to 0x02 which is not valid at all. Byte 7 is the format
code, but 0x02 is reserved there too. Who wrote this program? Tell
him it's buggy, it's not the driver.
--
Jens Axboe
On Wed, Mar 07, 2001 at 09:36:32PM +0100, Jens Axboe wrote:
> On Wed, Mar 07 2001, Pozsar Balazs wrote:
> > Details: (dmesg)
> >
> > When I run "dvdinfo /dev/hdd" I get:
> > Disc is encrypted.
> > Layer 0[3]
> > Num Layers: 2
> > Start Sector 0xd000
> > End Sector 0xd000
> > End Sector L0 0xd000
> > Layer 1[3]
> > Num Layers: 2
> > Start Sector 0xd000
> > End Sector 0x1d000
> > End Sector L0 0xd000
> > hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
> > hdd: packet command error: error=0x50
> > ATAPI device hdd:
> > Error: Illegal request -- (Sense key=0x05)
> > Invalid field in command packet -- (asc=0x24, ascq=0x00)
> > The failed "Send DVD Structure" packet command was:
> > "ad 00 00 00 00 00 02 00 00 54 00 00 "
> > Could not read Physical layer 2
> > Copyright: CPST=1, RMI=0xfd
>
> I don't know the program you mention, but it's definitely buggy. It
> sets byte 6 to 0x02 which is not valid at all.
The program is attempting to read from the third layer! Thats why it
fails. This value gets set from the .layer_num element supplied
in the struct dvd_physical supplied to the ioctl call.
> Byte 7 is the format code, but 0x02 is reserved there too. Who wrote
> this program? Tell him it's buggy, it's not the driver.
Originally me (a couple of years ago), and I'm not supprised at it
being buggy, it was a simple program to explore a couple of the
ioctl calls. I never got particularly sensible data from a multi-layer
DVD (maybe the firmware in my drives is dodgy).
the original code was something like:
dvd_struct d;
int layer, layers = 4;
d.physical.type = DVD_STRUCT_PHYSICAL;
for (layer = 0; layer < layers; ++layer) {
d.physical.layer_num = layer;
ioctl(fd, DVD_READ_STRUCT, &d);
printf("Layer %d[%d]\n", layer, layers);
display data in d.physical.layer[layer]
layers = d.physical.layer[layer].nlayers + 1;
}
This was from observations of the data returned by my DVD drive, where
the .nlayers was always returned as 0 or 1 for single or dual layer
discs, and always as 0 for flippers. Having a drive return the number
of layers as 2 doesn't agree with this. Unless his drive is simply
returning 1 based numbers, whereas mine returned 0 based numbers.
Actually I never forund the API especially sensible - this could just be
due to the data I saw back from my DVD drive.
The way I interpreted this API is that one requests the layer number to
read the data from, and that index in the array would be filled in with
data. However this seems a bit pointless - if only one layers worth of
data will be returned at a time, then why have an array of 4 entries?
Or is it intended that you should be able to read identical data from
either layer (on either side). That all layers on the disk would have
had this structure physically recorded identically, and that for a
disk with n 'layers', n elements of the array will be filled as
appropriate.
On my drive for array indicies > 0 the data in the structure elements
is always 0. It also makes no difference which layer I read (assuming
that its actually dual layer), the results of the 2 ioctl calls are
identical.
DF
On Wed, Mar 07 2001, Jens Axboe wrote:
> Really good question, I sent this patch in the private thread between
> me and Pozsar just in case the length is what the drive complains about.
Agrh, that's not all. I will fix this properly, sorry about the noise.
--
Jens Axboe
On Wed, Mar 07 2001, Jens Axboe wrote:
> On Wed, Mar 07 2001, Jens Axboe wrote:
> > Really good question, I sent this patch in the private thread between
> > me and Pozsar just in case the length is what the drive complains about.
>
> Agrh, that's not all. I will fix this properly, sorry about the noise.
This should work. Pozsar, could you test?
I suspect that Derik is right though, that the 05/24/00 is because
the dvdinfo is requesting info for a non-existant physical layer.
I've attempted to quiet that error. You dvdinfo output did look
very odd.
--
Jens Axboe
On Wed, Mar 07 2001, Derek Fawcus wrote:
> > > hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
> > > hdd: packet command error: error=0x50
> > > ATAPI device hdd:
> > > Error: Illegal request -- (Sense key=0x05)
> > > Invalid field in command packet -- (asc=0x24, ascq=0x00)
> > > The failed "Send DVD Structure" packet command was:
> > > "ad 00 00 00 00 00 02 00 00 54 00 00 "
> > > Could not read Physical layer 2
> > > Copyright: CPST=1, RMI=0xfd
> >
> > I don't know the program you mention, but it's definitely buggy. It
> > sets byte 6 to 0x02 which is not valid at all.
>
> The program is attempting to read from the third layer! Thats why it
> fails. This value gets set from the .layer_num element supplied
> in the struct dvd_physical supplied to the ioctl call.
>
> > Byte 7 is the format code, but 0x02 is reserved there too. Who wrote
> > this program? Tell him it's buggy, it's not the driver.
>
> Originally me (a couple of years ago), and I'm not supprised at it
> being buggy, it was a simple program to explore a couple of the
> ioctl calls. I never got particularly sensible data from a multi-layer
> DVD (maybe the firmware in my drives is dodgy).
The report sense was buggy, and that fooled me. The cdb is not wrong
at all, apart from the length which you mention further on. It's a
READ_DVD_STRUCTURE command, not a SEND_DVD_STRUCTURE.
> the original code was something like:
>
> dvd_struct d;
> int layer, layers = 4;
>
> d.physical.type = DVD_STRUCT_PHYSICAL;
>
> for (layer = 0; layer < layers; ++layer) {
> d.physical.layer_num = layer;
>
> ioctl(fd, DVD_READ_STRUCT, &d);
>
> printf("Layer %d[%d]\n", layer, layers);
> display data in d.physical.layer[layer]
>
> layers = d.physical.layer[layer].nlayers + 1;
> }
Much the same today, the program was forwarded to me ;-)
> The way I interpreted this API is that one requests the layer number to
> read the data from, and that index in the array would be filled in with
> data. However this seems a bit pointless - if only one layers worth of
> data will be returned at a time, then why have an array of 4 entries?
Really good question, I sent this patch in the private thread between
me and Pozsar just in case the length is what the drive complains about.
--
Jens Axboe
Adding the
cgc.buflen = 20;
line into drivers/cdrom/cdrom.c: dvd_read_physical(...)
solves my problem.
I don't know the difference, but first you mentioned
cgc.buflen = 16;
so i tried that also, and it worked the same.
I'll write again if i'm having problems. :)
Thanks for the fast patch.
I think you should also check 2.2.
Balazs Pozsar.
On Wed, 7 Mar 2001, Jens Axboe wrote:
> On Wed, Mar 07 2001, Jens Axboe wrote:
> > On Wed, Mar 07 2001, Jens Axboe wrote:
> > > Really good question, I sent this patch in the private thread between
> > > me and Pozsar just in case the length is what the drive complains about.
> >
> > Agrh, that's not all. I will fix this properly, sorry about the noise.
>
> This should work. Pozsar, could you test?
>
> I suspect that Derik is right though, that the 05/24/00 is because
> the dvdinfo is requesting info for a non-existant physical layer.
> I've attempted to quiet that error. You dvdinfo output did look
> very odd.
>
>
On Wed, Mar 07 2001, Pozsar Balazs wrote:
>
> Adding the
> cgc.buflen = 20;
> line into drivers/cdrom/cdrom.c: dvd_read_physical(...)
> solves my problem.
>
> I don't know the difference, but first you mentioned
> cgc.buflen = 16;
> so i tried that also, and it worked the same.
>
> I'll write again if i'm having problems. :)
> Thanks for the fast patch.
Great, it worked out in the end :-)
> I think you should also check 2.2.
Definitely, 2.2 and 2.4 are 100% similar in this regard.
--
Jens Axboe