public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Derek Fawcus <dfawcus@cisco.com>
Cc: Pozsar Balazs <pozsy@sch.bme.hu>, linux-kernel@vger.kernel.org
Subject: Re: can't read DVD (under 2.4.[12] & 2.2.17)
Date: Wed, 7 Mar 2001 22:44:24 +0100	[thread overview]
Message-ID: <20010307224424.R4653@suse.de> (raw)
In-Reply-To: <20010307210848.E4653@suse.de> <Pine.GSO.4.30.0103072128180.6575-100000@balu> <20010307213632.H4653@suse.de> <20010307213625.A28742@uk-view2.cisco.com>
In-Reply-To: <20010307213625.A28742@uk-view2.cisco.com>; from dfawcus@cisco.com on Wed, Mar 07, 2001 at 09:36:25PM +0000

[-- Attachment #1: Type: text/plain, Size: 2337 bytes --]

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


[-- Attachment #2: dvd-read-phys-1 --]
[-- Type: text/plain, Size: 410 bytes --]

--- /opt/kernel/linux-2.4.3-pre2/drivers/cdrom/cdrom.c	Thu Feb 22 14:55:22 2001
+++ drivers/cdrom/cdrom.c	Wed Mar  7 22:25:14 2001
@@ -1172,7 +1172,7 @@
 static int dvd_read_physical(struct cdrom_device_info *cdi, dvd_struct *s)
 {
 	int ret, i;
-	u_char buf[4 + 4 * 20], *base;
+	u_char buf[20], *base;
 	struct dvd_layer *layer;
 	struct cdrom_generic_command cgc;
 	struct cdrom_device_ops *cdo = cdi->ops;

  reply	other threads:[~2001-03-07 21:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-07 20:03 can't read DVD (under 2.4.[12] & 2.2.17) Pozsar Balazs
2001-03-07 20:08 ` Jens Axboe
2001-03-07 20:32   ` Pozsar Balazs
2001-03-07 20:36     ` Jens Axboe
2001-03-07 21:36       ` Derek Fawcus
2001-03-07 21:44         ` Jens Axboe [this message]
2001-03-07 21:46           ` Jens Axboe
2001-03-07 22:26             ` Jens Axboe
2001-03-07 22:58               ` Pozsar Balazs
2001-03-07 23:22                 ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010307224424.R4653@suse.de \
    --to=axboe@suse.de \
    --cc=dfawcus@cisco.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pozsy@sch.bme.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox