From: "David Burg" <dburg@nero.com>
To: "'David Balazic'" <david.balazic@hermes.si>,
"'Pat LaVarre'" <p.lavarre@ieee.org>
Cc: <linux_udf@hpesjro.fc.hp.com>, <linux-kernel@vger.kernel.org>
Subject: RE: Can not read UDF CD
Date: Thu, 29 Jul 2004 18:23:38 +0200 [thread overview]
Message-ID: <000301c47588$6850e2f0$7a02a8c0@cwx235> (raw)
In-Reply-To: <B1ECE240295BB146BAF3A94E00F2DBFF090203@piramida.hermes.si>
Hello Pat,
Could it be that Nero is to be blamed? I see in the verifier log:
AVDP at N-256
AVDP error: Volume Descriptor Sequence Extent not equal to
- the one read in first AVDP
- Main: length,location: 32768, 30654 expected: 32768, 32
- Reserve: length,location: 32768, 30670 expected: 32768, 48
Let me know if you also think the medium produced by Nero has a mistake and
our Nero UDF engineers have a bug to fix.
Best regards,
David Burg
----------------------------------------------------------------
David Burg
Software Development,
InCD Project Leader
Ahead Software AG
Im Stoeckmaedle 18 fax: +49 (0)7248 911 888
76307 Karlsbad email: dburg@nero.com
Germany http://www.nero.com
----------------------------------------------------------------
-----Original Message-----
From: linux_udf-owner@hpesjro.ipf.fc.hp.com
[mailto:linux_udf-owner@hpesjro.ipf.fc.hp.com] On Behalf Of David Balazic
Sent: Thursday, July 29, 2004 5:33 PM
To: David Balazic; 'Pat LaVarre'
Cc: 'linux_udf@hpesjro.fc.hp.com'; 'linux-kernel@vger.kernel.org'
Subject: RE: Can not read UDF CD
> From: Pat LaVarre[SMTP:p.lavarre@ieee.org]
>
> David B:
>
> /// In short,
>
> I suggest quickly trying the mount -o lastblock= and anchor= udf.ko
> options described at:
>
> http://lxr.linux.no/source/Documentation/filesystems/udf.txt?v=2.6.5
>
> else working thru til able to try the phgfsck described at my page:
>
> http://udfko.blog-city.com/read/577369.htm
>
> If you do post the phgfsck report on the web, I'll gladly link to it.
I attach the "udf_test -scsi 1:0" output.
> /// At length, in Seven parts ...
>
> /// 1) Similarly
snip
> /// 2) Where
>
> What kind of cable do you use, what is your device name, what is your
> mount point?
cable is 80 wire ATA-66
dev is /dev/cdrom2 -> /dev/hdc
/mnt/cdrom2
> Til I know, I will cover both USB and PATAPI and pretend you want to
> mount /dev/scd0 at /mnt/scd0.
>
> /// 3) -o lastblock="$n"
>
> Up in user land, my workaround was:
>
> n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 -
> p\"`" sudo mount -r -o lastblock="$n" /dev/scd0 /mnt/scd0
Will try...
> /// 4) patch -p1 ...
>
> To recover the feature:
>
> sudo mount -r /dev/scd0 /mnt/scd0
>
> for such unfriendly discs, I web-published the patch quoted below to
> the patches-udf.lastblock package of
> http://iomrrdtools.sourceforge.net/
Wil try ...
> /// 5) -o anchor=...
>
> If -o lastblock="$n" doesn't work for you, then one more blind try is
> -o anchor="$n" i.e.
>
> n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 -
> p\"`" sudo mount -r -o anchor="$n" /dev/scd0 /mnt/scd0
>
> Please note -o anchor is arguably reckless except when combined with
> -r.
>
> /// 6) phgfsck
>
> If neither blind try works for you, then to make sense of the disc
> you can try phgfsck. For example, here, I see:
>
> $ sudo phgfsck -scsi /dev/sg0 | grep 'AVDPs at'
> Number of AVDPs: 2, AVDPs at N-256, N
> $
>
> Seeing "AVDP ... at ... N" tells me to try what I mentioned above:
>
> n="`dc -e \"\`sudo blockdev --getsize /dev/scd0\` 512 * 2048 / 1 -
> p\"`" sudo mount -r -o anchor="$n" /dev/scd0 /mnt/scd0
>
> /// 7) reconfiguring Linux to permit phgfsck
>
> http://www.extra.research.philips.com/udf/
> is the Philips page that offers the phgfsck, aka the "Philips UDF
> Verifier".
>
> My clarification of that page is:
>
> http://udfko.blog-city.com/read/577369.htm
>
> Philips deserves nothing but kudos for donating the phgfsck to
> improve UDF interoperability worldwide ... except the fact remains
> they haven't chosen to release their copyright under a license
> approved as open source by such authorities as sourceforge.net.
>
> Consequently, the phgfsck can be unusually hard to use in Linux.
> Specifically, it does Not incorporate any of the better SCSI pass
> thru libraries. Privately, as yet I've heard from Two employees of
> different corporations who privately requested and privately were
> denied permission to donate code into the phgfsck, because its source
> is partly closed.
>
> First, as yet with the phgfsck, you have to substitute an sg name for
> the regular dev name, even when running 2.6.
>
> To discover your sg name, you can try each of /dev/sg* to see what
> happens, or you can download yet another tool, such as sg_scan -i or
> my own plscsi -w, found at http://members.aol.com/plscsi/linux/
>
> In theory `phgfsck -showscsi` will give you device names, but for me
> that query doesn't work reliably. Trying here just now in
> 2.6.8-rc2-bk7, it hangs. In the past, I've seen it miss names.
>
> Often you need root privilege to discover the sg name.
>
> You will probably have an sg name to find only if your kernel has a
> drivers/scsi/sg.ko and your device name was among the /dev/scd*
>
> Else you might have to get into substituting ide-scsi.ko for
> ide-cd.ko, especially if your device name was among the /dev/hd*.
> linux-scsi speaks occasionally of the issues such substitutions
> raise.
>
> Pat LaVarre
> http://iomrrdtools.sourceforge.net/
> http://udfko.blog-city.com/
>
> --- From:
> http://sourceforge.net/project/showfiles.php?group_id=101444&package_
>id=12 5426
>
> See also: Readme.txt
> ... Copyright (c) 2004 Iomega Corp
> ... free software ...
> ... GNU General Public License as ... either ... or ...
> ...
>
> diff -urp linux-2.6.8-rc2-bk7/fs/udf/lowlevel.c
> linux-2.6.8-rc2-bk7-pel/fs/udf/lowlevel.c
> --- linux-2.6.8-rc2-bk7/fs/udf/lowlevel.c 2004-06-15
> 23:19:36.000000000 -0600
> +++ linux-2.6.8-rc2-bk7-pel/fs/udf/lowlevel.c 2004-07-28
> 14:46:02.373806296 -0600
> @@ -73,9 +73,9 @@ udf_get_last_block(struct super_block *s
> struct block_device *bdev = sb->s_bdev;
> unsigned long lblock = 0;
>
> - if (ioctl_by_bdev(bdev, CDROM_LAST_WRITTEN, (unsigned long)
> &lblock))
> - lblock = bdev->bd_inode->i_size >> sb->s_blocksize_bits;
> -
> + if (!ioctl_by_bdev(bdev, CDROM_LAST_WRITTEN, (unsigned long)
> &lblock))
> + return lblock;
> + lblock = bdev->bd_inode->i_size >> sb->s_blocksize_bits;
> if (lblock)
> return lblock - 1;
> else
> diff -urp linux-2.6.8-rc2-bk7/fs/udf/super.c
> linux-2.6.8-rc2-bk7-pel/fs/udf/super.c
> --- linux-2.6.8-rc2-bk7/fs/udf/super.c 2004-07-28
> 10:36:35.928051888 -0600
> +++ linux-2.6.8-rc2-bk7-pel/fs/udf/super.c 2004-07-28
> 14:45:45.356393336 -0600
> @@ -1562,6 +1562,9 @@ static int udf_fill_super(struct super_b
> goto error_out;
> }
>
> + if (!UDF_SB_LASTBLOCK(sb)) {
> + UDF_SB_LASTBLOCK(sb) = udf_get_last_block(sb);
> + }
> udf_find_anchor(sb);
>
> /* Fill in the rest of the superblock */
>
> <<report_1_stein.txt>>
next prev parent reply other threads:[~2004-07-29 16:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-29 15:32 Can not read UDF CD David Balazic
2004-07-29 16:23 ` David Burg [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-08-17 14:24 David Balazic
2004-08-11 12:27 xerces8
2004-08-10 8:31 David Balazic
2004-08-09 14:27 David Balazic
2004-08-09 7:33 David Balazic
2004-08-09 16:22 ` Pat LaVarre
2004-07-30 7:17 David Balazic
2004-08-02 14:42 ` Pat LaVarre
2004-08-17 14:05 ` Pat LaVarre
2004-07-30 7:16 David Balazic
2004-07-29 16:32 David Balazic
2004-07-29 17:06 ` Pat LaVarre
2004-07-29 17:33 ` Ben Fennema
2004-07-29 8:48 David Balazic
2004-07-29 14:44 ` Pat LaVarre
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='000301c47588$6850e2f0$7a02a8c0@cwx235' \
--to=dburg@nero.com \
--cc=david.balazic@hermes.si \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_udf@hpesjro.fc.hp.com \
--cc=p.lavarre@ieee.org \
/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