From: Derek Fawcus <dfawcus@cisco.com>
To: Jens Axboe <axboe@suse.de>, Pozsar Balazs <pozsy@sch.bme.hu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: can't read DVD (under 2.4.[12] & 2.2.17)
Date: Wed, 7 Mar 2001 21:36:25 +0000 [thread overview]
Message-ID: <20010307213625.A28742@uk-view2.cisco.com> (raw)
In-Reply-To: <20010307210848.E4653@suse.de> <Pine.GSO.4.30.0103072128180.6575-100000@balu> <20010307213632.H4653@suse.de>
In-Reply-To: <20010307213632.H4653@suse.de>; from axboe@suse.de on Wed, Mar 07, 2001 at 09:36:32PM +0100
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
next prev parent reply other threads:[~2001-03-07 21:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-07 20:03 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 [this message]
2001-03-07 21:44 ` Jens Axboe
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=20010307213625.A28742@uk-view2.cisco.com \
--to=dfawcus@cisco.com \
--cc=axboe@suse.de \
--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
all inboxes | Powered by JetHome®