Mailinglist Archive: packet-writing (84 mails)

< Previous Next >
Re: New cdrwtool, mkudffs fails? (HP8230e)
  • From: Ben Fennema <bfennema@xxxxxxxxxxxxx>
  • Date: Wed, 6 Feb 2002 16:56:27 +0000 (UTC)
  • Message-id: <20020206085804.A9217@xxxxxxxxxxxxxxxxxxxxxxxxxx>
On Thu, Feb 07, 2002 at 12:46:14AM +1100, Drew Parsons wrote:
> On Wed, Feb 06, 2002 at 12:32:43AM -0800, Ben Fennema wrote:
> >
> > The first write succeeded, at least so it claims. If you look at block 16, 17, and 18, do
> > you see anything (use dumpsect)? Can you read anything beyond the first packet?
> > (namely block 256-287, which is the first write the fails)...
>
> The blocks appear to be blank (by the way, dumpsect is absent from udftools
> 1.0.0b, but I got it from 0.9.5). How many bytes should I read?
> 4 bytes yields:
>
> $ dumpsect /dev/sr1 16 4
> 16: seek to 64 ok, retval 64
> retval= 4
> 00000010-000: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
> $ dumpsect /dev/sr1 17 4
> 17: seek to 68 ok, retval 68
> retval= 4
> 00000011-000: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
> $ dumpsect /dev/sr1 18 4
> 18: seek to 72 ok, retval 72
> retval= 4
> 00000012-000: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
>
> Sectors 254-257 are similarly full of 0's. Likewise 286-289. Or am I using
> dumpsect the wrong way?

Your using dumpsect the wrong way.. your changing the blocksize to 4 =)
Just run dumpsect /dev/sr1 16...

> So I guess the value of status is what comes out in that buffer after the
> URB has processed the given command. Which doesn't really help in
> understanding what "status=50" means. Sorry I can't make more sense of it
> than that, I barely even know what a URB is! 0x50 = 80, 0x58=88, which
> corresponds to ELIBBAD and ENOTSOCK in errno.h, unless my arithmetic is bad,
> neither of which really make sense in this context, and aren't remapped to a
> USB code in linux/usb.h, like some other standard error codes are. Should I
> ask the usb-storage maintainer to help?

Probably.. The writes shouldn't be failing =)
>
> > And you can just run cdrwtool -m 275744 (in your case) to run mkudffs.. Once its formated, assuming
> > it's formated ok, you don't need to format again.
>
> Did you mean cdrwtool -u 275744 ? -m just went and ran FORMAT_UNIT again
> (another 40 minutes gone...) But cdrwtool -u 275744 gets the same problem
> after the second WRITE_10.

Ya, it was late =)

Ben

< Previous Next >