Re: New cdrwtool (trying to format too many blocks)

newer
Locksmith School

older
please help

Norbert Preining

1 Feb 2002 1 Feb '02

10:08

Hi Ben! On Thu, 31 Jan 2002 11:31:16 -0800, Ben Fennema wrote:

...

If your seeing the new cdrwtool fail and the value for blocks is more than it used to be, could you send me the output of cdrwtool -i.

Here the problem first: $ cdrwtool -d /dev/sr0 -q using device /dev/sr0 4085KB internal buffer setting write speed to 12x Settings for /dev/sr0: Fixed packets, size 32 Mode-2 disc I'm going to do a quick setup of /dev/sr0. The disc is going to be blanked and formatted with one big track. All data on the device will be lost!! Press CTRL-C to cancel now. ENTER to continue. Initiating quick disc blank Disc capacity is 333748 blocks (667496KB/651MB) Formatting track wait_cmd: Invalid argument Command failed: 04 17 00 00 00 00 00 00 00 00 00 00 - sense 05.26.00 format disc: Invalid argument Now the Information: $ cdrwtool -d /dev/sr0 -i using device /dev/sr0 4085KB internal buffer setting write speed to 12x DISC INFO: erasable : Yes border = 0 Disc status = 0 number of first track = 1 number of sessions = 1 number of tracks = 1 status of last track = 1 uru = 0 did_v = 0 dbc_v = 0 disc type = 255 disc_id = 5251942 lead_in = 97:27:00 (438525) lead_out = 74:12:00 (333900) OPC entries = 0 TRACK INFO: Track 1 track_number = 1 session_number = 1 damage = 0 copy = 0 track_mode = 5 Rt = 0 blank = 1 packet = 1 fp = 1 data_mode = 2 lra_v = 0 nwa_v = 1 track_start = 0 next_writable = 0 last_recorded = 0 free_blocks = 273824 packet_size = 32 track_size = 273824 (547648KB) HP CD-Writer 9100 Best wishes Norbert ----------------------------------------------------------------------- Norbert Preining University of Technology Vienna, Austria gpg DSA: 0x09C5B094 ----------------------------------------------------------------------- HODNET (n.) The wooden safety platform supported by scaffolding round a building under construction from which the builders (at almost no personal risk) can drop pieces of cement on passers-by. --- Douglas Adams, The Meaning of Liff

Show replies by date

Ben Fennema

1 Feb 1 Feb

18:55

New subject: New cdrwtool (trying to format too many blocks)

On Fri, Feb 01, 2002 at 11:09:13AM +0100, Norbert Preining wrote:

...

Hi Ben!

On Thu, 31 Jan 2002 11:31:16 -0800, Ben Fennema wrote:

...
If your seeing the new cdrwtool fail and the value for blocks is more than it used to be, could you send me the output of cdrwtool -i.

Ok, give this patch a try.. It should fix the problem. Ben diff -u -p -r1.3 main.c --- main.c 2002/01/30 21:39:59 1.3 +++ main.c 2002/02/01 18:48:13 @@ -136,7 +136,7 @@ int quick_setup(int fd, struct cdrw_disc return ret; blocks = msf_to_lba(di.lead_out_m, di.lead_out_s, di.lead_out_f) - 152; - if (disc->fpacket && !(ti.packet && ti.fp)) + if (disc->fpacket) { /* fixed packets format usable blocks */ blocks = ((blocks + 7) / (disc->packet_size + 7)) * disc->packet_size;

Sergiy Kudryk

2 Feb 2 Feb

14:18

New subject: New cdrwtool (trying to format too many blocks); Success

Hello Ben. Thank you for good work. After applying your patch all problems with formatting (Verbatim CDRW disc, 700 MB) disappears. Here is console output: [serge@my 1.0.0a]# cdrwtool -d /dev/sr0 -i using device /dev/sr0 1312KB internal buffer setting write speed to 12x DISC INFO: erasable : Yes border = 0 Disc status = 0 number of first track = 1 number of sessions = 1 number of tracks = 1 status of last track = 1 uru = 0 did_v = 0 dbc_v = 0 disc type = 255 disc_id = 0 lead_in = 97:34:22 (439072) lead_out = 79:59:74 (359999) OPC entries = 0 TRACK INFO: Track 1 track_number = 1 session_number = 1 damage = 0 copy = 0 track_mode = 4 Rt = 0 blank = 1 packet = 0 fp = 0 data_mode = 15 lra_v = 0 nwa_v = 1 track_start = 0 next_writable = 0 last_recorded = 0 free_blocks = 359847 packet_size = 0 track_size = 359847 (719694KB) [serge@my 1.0.0a]# cdrwtool -d /dev/sr0 -q using device /dev/sr0 1312KB internal buffer setting write speed to 12x Settings for /dev/sr0: Fixed packets, size 32 Mode-2 disc I'm going to do a quick setup of /dev/sr0. The disc is going to be blanked and formatted with one big track. All data on the device will be lost!! Press CTRL-C to cancel now. ENTER to continue. Initiating quick disc blank Disc capacity is 295264 blocks (590528KB/576MB) Formatting track start=0, blocks=16, type=RESERVED start=16, blocks=3, type=VRS start=19, blocks=237, type=USPACE start=256, blocks=1, type=ANCHOR start=257, blocks=31, type=USPACE start=288, blocks=32, type=PVDS start=320, blocks=32, type=LVID start=352, blocks=32, type=STABLE start=384, blocks=1024, type=SSPACE start=1408, blocks=293568, type=PSPACE start=294976, blocks=31, type=USPACE start=295007, blocks=1, type=ANCHOR start=295008, blocks=160, type=USPACE start=295168, blocks=32, type=STABLE start=295200, blocks=32, type=RVDS start=295232, blocks=31, type=USPACE start=295263, blocks=1, type=ANCHOR Writing UDF structures to disc Quick setup complete! [serge@my 1.0.0a]# .. Regards, Sergiy Kudryk --- Ben Fennema wrote:

...

On Fri, Feb 01, 2002 at 11:09:13AM +0100, Norbert Preining wrote:

...
Hi Ben!

On Thu, 31 Jan 2002 11:31:16 -0800, Ben Fennema wrote:

...
If your seeing the new cdrwtool fail and the value for blocks is more than it used to be, could you send me the output of cdrwtool -i.

Ok, give this patch a try.. It should fix the problem.

Ben

diff -u -p -r1.3 main.c --- main.c 2002/01/30 21:39:59 1.3 +++ main.c 2002/02/01 18:48:13 @@ -136,7 +136,7 @@ int quick_setup(int fd, struct cdrw_disc return ret;

blocks = msf_to_lba(di.lead_out_m, di.lead_out_s, di.lead_out_f) - 152; - if (disc->fpacket && !(ti.packet && ti.fp)) + if (disc->fpacket) { /* fixed packets format usable blocks */ blocks = ((blocks + 7) / (disc->packet_size + 7)) * disc->packet_size;

-- To unsubscribe, e-mail: packet-writing-unsubscribe@suse.com For additional commands, e-mail: packet-writing-help@suse.com

__________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com

Norbert Preining

3 Feb 3 Feb

22:10

New subject: New cdrwtool (trying to format too many blocks)

On Fre, 01 Feb 2002, Ben Fennema wrote:

...

...
...
If your seeing the new cdrwtool fail and the value for blocks is more than it used to be, could you send me the output of cdrwtool -i.

Ok, give this patch a try.. It should fix the problem.

It worked out, here's the output of cdrwtool -d /dev/sr0 -q: [root: ~] cdrwtool -d /dev/sr0 -q using device /dev/sr0 4085KB internal buffer setting write speed to 12x Settings for /dev/sr0: Fixed packets, size 32 Mode-2 disc I'm going to do a quick setup of /dev/sr0. The disc is going to be blanked and formatted with one big track. All data on the device will be lost!! Press CTRL-C to cancel now. ENTER to continue. Initiating quick disc blank Disc capacity is 273824 blocks (547648KB/534MB) Formatting track start=0, blocks=16, type=RESERVED start=16, blocks=3, type=VRS start=19, blocks=237, type=USPACE start=256, blocks=1, type=ANCHOR start=257, blocks=31, type=USPACE start=288, blocks=32, type=PVDS start=320, blocks=32, type=LVID start=352, blocks=32, type=STABLE start=384, blocks=1024, type=SSPACE start=1408, blocks=272128, type=PSPACE start=273536, blocks=31, type=USPACE start=273567, blocks=1, type=ANCHOR start=273568, blocks=160, type=USPACE start=273728, blocks=32, type=STABLE start=273760, blocks=32, type=RVDS start=273792, blocks=31, type=USPACE start=273823, blocks=1, type=ANCHOR Writing UDF structures to disc Quick setup complete! Thanks a lot and best wishes. Best wishes Norbert ----------------------------------------------------------------------- Norbert Preining University of Technology Vienna, Austria gpg DSA: 0x09C5B094 ----------------------------------------------------------------------- `A curse,' said Slartibartfast, `which will engulf the Galaxy in fire and destruction, and possibly bring the Universe to a premature doom. I mean it,' he added. `Sounds like a bad time,' said Ford, `with luck I'll be drunk enough not to notice.' --- Ford ensuring everyone knew where his priorities lay. --- Douglas Adams, The Hitchhikers Guide to the Galaxy

Norbert Preining

4 Feb 4 Feb

10:39

New subject: New cdrwtool (trying to format too many blocks)

On Son, 03 Feb 2002, Norbert Preining wrote:

...

It worked out, here's the output of cdrwtool -d /dev/sr0 -q:

I copied a big file, stopped the pktdevice, and then I tried to read the disc under windows, no chance. It always shows me an empty disc. BTW: Is mkudffs necessary after cdrwtool -q ? I could start copying to the disc without mkudffs. Best wishes Norbert ----------------------------------------------------------------------- Norbert Preining University of Technology Vienna, Austria gpg DSA: 0x09C5B094 ----------------------------------------------------------------------- TAMPA (n.) The sound of a rubber eraser coming to rest after dropping off a desk in a very quiet room. --- Douglas Adams, The Meaning of Liff

Sergiy Kudryk

11:23

New subject: New cdrwtool (trying to format too many blocks)

Hi --- Norbert Preining wrote:

...

On Son, 03 Feb 2002, Norbert Preining wrote:

...
It worked out, here's the output of cdrwtool -d /dev/sr0 -q:

I copied a big file, stopped the pktdevice, and then I tried to read the disc under windows, no chance. It always shows me an empty disc.

Is there I/O errors (/var/log/messages) during writing to CDRW disc ? I think you have on that disc not correctly finished write transaction. At this time i don't have stable (big portion (> 50 MB) of data) writing to CDRW disc too, but Windows DirectCD 5.0 can read files writed without i/o errors. Regards, Sergiy Kudryk.

...

BTW: Is mkudffs necessary after cdrwtool -q ? I could start copying to the disc without mkudffs.

Best wishes

Norbert

----------------------------------------------------------------------- Norbert Preining University of Technology Vienna, Austria gpg DSA: 0x09C5B094 ----------------------------------------------------------------------- TAMPA (n.)

The sound of a rubber eraser coming to rest after dropping off a desk in a very quiet room.

--- Douglas Adams, The Meaning of Liff

__________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com

Ben Fennema

17:33

New subject: New cdrwtool (trying to format too many blocks)

On Mon, Feb 04, 2002 at 11:40:34AM +0100, Norbert Preining wrote:

...

On Son, 03 Feb 2002, Norbert Preining wrote:

...
It worked out, here's the output of cdrwtool -d /dev/sr0 -q:

I copied a big file, stopped the pktdevice, and then I tried to read the disc under windows, no chance. It always shows me an empty disc.

BTW: Is mkudffs necessary after cdrwtool -q ? I could start copying to the disc without mkudffs.

-q runs mkudffs, and happens to default to udf 2.01 and not 1.5 which is most likely why windows can't read the disc. I just added a flag yesterday to set the udf version under cdrwtool - so the current version has no way to change to 1.5, without mounting via pktsetup and running mkudffs directly on /dev/pktcdvd0.. Ben

Norbert Preining

5 Feb 5 Feb

07:25

New subject: New cdrwtool (trying to format too many blocks)

On Mon, 04 Feb 2002, Ben Fennema wrote:

...

-q runs mkudffs, and happens to default to udf 2.01 and not 1.5 which is most likely why windows can't read the disc. I just added a flag yesterday to set the udf version under cdrwtool - so the current version has no way to change to 1.5, without mounting via pktsetup and running mkudffs directly on /dev/pktcdvd0..

What are the options necessary to call mkudffs the same way besides rev 1.5 from the commandline: I tried mkudffs -r0x0150 /dev/pktcdvd0 (after reading the source to find how to give the revision) and I got [root: ~] mkudffs -r0x0150 /dev/pktcdvd0 trying to change type of multiple extents Is it possible to fetch a cvs version where I can tell cdrwtool -r0x0150? Thanks for the good work! Best wishes Norbert ----------------------------------------------------------------------- Norbert Preining University of Technology Vienna, Austria gpg DSA: 0x09C5B094 ----------------------------------------------------------------------- The suit into which the man's body had been stuffed looked as if it's only purpose in life was to demonstrate how difficult it was to get this sort of body into a suit. --- Douglas Adams, The Hitchhikers Guide to the Galaxy

Ben Fennema

07:46

New subject: New cdrwtool (trying to format too many blocks)

On Tue, Feb 05, 2002 at 08:26:46AM +0100, Norbert Preining wrote:

...

On Mon, 04 Feb 2002, Ben Fennema wrote:

...
-q runs mkudffs, and happens to default to udf 2.01 and not 1.5 which is most likely why windows can't read the disc. I just added a flag yesterday to set the udf version under cdrwtool - so the current version has no way to change to 1.5, without mounting via pktsetup and running mkudffs directly on /dev/pktcdvd0..

What are the options necessary to call mkudffs the same way besides rev 1.5 from the commandline: I tried mkudffs -r0x0150 /dev/pktcdvd0 (after reading the source to find how to give the revision) and I got

[root: ~] mkudffs -r0x0150 /dev/pktcdvd0 trying to change type of multiple extents

It's probably not getting the # of blocks right.. specifying it explicitly should work. mkudffs -r0x0150 /dev/pktcdvd0 <# blocks> If not, attached is a patch to cdrwtool.. -v <version> (-r is already taken) diff -u -p -r1.2 options.c --- options.c 2002/01/30 21:39:59 1.2 +++ options.c 2002/02/05 07:40:03 @@ -36,7 +36,8 @@ struct option long_options[] = { { "get write parameters", no_argument, NULL, 'g' }, { "blank cdrw disc", 1, NULL, 'b' }, { "format cdrw disc", 1,NULL, 'm' }, - { "run mkudf on track", 1,NULL, 'u' }, + { "run mkudffs on track", 1, NULL, 'u' }, + { "set mkudffs version", 1, NULL, 'v' }, { "set cd writing speed", 1, NULL, 't' }, { "write fixed packets", 1, NULL, 'p' }, { "perform quick setup", no_argument, NULL, 'q' }, @@ -67,7 +68,7 @@ void parse_args(int argc, char *argv[], { int retval; - while ((retval = getopt_long(argc, argv, "r:t:im:u:d:sgqcb:p:z:l:w:f:o:h", long_options, NULL)) != EOF) + while ((retval = getopt_long(argc, argv, "r:t:im:u:v:d:sgqcb:p:z:l:w:f:o:h", long_options, NULL)) != EOF) { switch (retval) { @@ -90,6 +91,34 @@ void parse_args(int argc, char *argv[], disc->mkudf = 1; disc->offset = strtol(optarg, NULL, 10); printf("mkudfing %lu blocks\n", disc->offset); + break; + } + case 'v': + { + struct logicalVolIntegrityDescImpUse *lvidiu; + + disc->udf_disc.udf_rev = strtol(optarg, NULL, 16); + if (disc->udf_disc.udf_rev != 0x0102 && + disc->udf_disc.udf_rev != 0x0150 && + disc->udf_disc.udf_rev != 0x0200 && + disc->udf_disc.udf_rev != 0x0201) + { + exit(1); + } + printf("udf version set to 0x%04x\n", disc->udf_disc.udf_rev); + if (disc->udf_disc.udf_rev < 0x0200) + { + disc->udf_disc.flags &= ~FLAG_EFE; + strcpy(disc->udf_disc.udf_pd[0]->partitionContents.ident, PD_PARTITION_CONTENTS_NSR02); + } + ((uint16_t *)disc->udf_disc.udf_fsd->domainIdent.identSuffix)[0] = cpu_to_le16(disc->udf_disc.udf_rev); + ((uint16_t *)disc->udf_disc.udf_lvd[0]->domainIdent.identSuffix)[0] = cpu_to_le16(disc->udf_disc.udf_rev); + ((uint16_t *)disc->udf_disc.udf_iuvd[0]->impIdent.identSuffix)[0] = le16_to_cpu(disc->udf_disc.udf_rev); + lvidiu = (struct logicalVolIntegrityDescImpUse *)&(disc->udf_disc.udf_lvid->impUse[le32_to_cpu(disc->udf_disc.udf_lvd[0]->numPartitionMaps) * 2 * sizeof(uint32_t)]); + lvidiu->minUDFReadRev = le16_to_cpu(disc->udf_disc.udf_rev); + lvidiu->minUDFWriteRev = le16_to_cpu(disc->udf_disc.udf_rev); + lvidiu->maxUDFWriteRev = le16_to_cpu(disc->udf_disc.udf_rev); + ((uint16_t *)disc->udf_disc.udf_stable[0]->sparingIdent.identSuffix)[0] = le16_to_cpu(disc->udf_disc.udf_rev); break; } case 'r':

Norbert Preining

11:16

New subject: New cdrwtool (trying to format too many blocks)

On Mon, 04 Feb 2002, Ben Fennema wrote:

...

If not, attached is a patch to cdrwtool.. -v <version> (-r is already taken)

Bingo. Thanks a lot. I made cdrwtool -q -d /dev/sr0 -v 0x0150 and after this mounted the pktcdvd0 device, copied one big (300M) and several small files onto the disc, then tried it under windows (98se) and, voila, there they are. Thanks again! (BTW: hp cdwriter 9100i) Best wishes Norbert ----------------------------------------------------------------------- Norbert Preining University of Technology Vienna, Austria gpg DSA: 0x09C5B094 ----------------------------------------------------------------------- HOFF (vb.) To deny indignantly something which is palpably true. --- Douglas Adams, The Meaning of Liff

Sergiy Kudryk

6 Feb 6 Feb

18:35

New subject: New cdrwtool (trying to format too many blocks)

Hello --- Norbert Preining wrote:

...

On Mon, 04 Feb 2002, Ben Fennema wrote:

...
If not, attached is a patch to cdrwtool.. -v <version> (-r is already taken)

Bingo. Thanks a lot. I made cdrwtool -q -d /dev/sr0 -v 0x0150 and after this mounted the pktcdvd0 device, copied one big (300M) and several small files onto the disc, then tried it under windows (98se) and, voila, there they are.

Can anybody help ? I can't successfully write to CDRW disc a large file (> 50 MB) - too many i/o errors. How i can decrease writing speed of pktcdvd layer ? I have CDRW drive with 4X write speed and when i start to copy big file (500 Mbytes) to /mnt/cdrw using mc system shows writing speed about 9 MB/s (should be no more then 600 KB/s). System freeze after i/o errors at 7 % of copying process scale. I can copy small files (total size < 50 MB) at once to CDRW disc without big problems (only several i/o errors occurs) Disc was formatted at 4x speed using cdrwtool (1.0.0b) with latest pacthes. What is the way for correction of speed of data exchange between mount directory and drive ? Thank you. Sergiy.

...

Thanks again!

(BTW: hp cdwriter 9100i)

Best wishes

Norbert

----------------------------------------------------------------------- Norbert Preining University of Technology Vienna, Austria gpg DSA: 0x09C5B094 ----------------------------------------------------------------------- HOFF (vb.)

To deny indignantly something which is palpably true.

--- Douglas Adams, The Meaning of Liff

-- To unsubscribe, e-mail: packet-writing-unsubscribe@suse.com For additional commands, e-mail: packet-writing-help@suse.com

__________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com

Peter Osterlund

20:17

New subject: New cdrwtool (trying to format too many blocks)

On Wed, 6 Feb 2002, Sergiy Kudryk wrote:

...

Hello

Can anybody help ?

I can't successfully write to CDRW disc a large file (> 50 MB) - too many i/o errors.

How i can decrease writing speed of pktcdvd layer ?

You have to edit the source code. In the pkt_open_write function, there is a call to pkt_adjust_speed. Change the "16" to the speed you want to use.

...

I have CDRW drive with 4X write speed and when i start to copy big file (500 Mbytes) to /mnt/cdrw using mc system shows writing speed about 9 MB/s (should be no more then 600 KB/s).

Maybe if the writes start to fail, they can fail with a speed faster than 600Kb/s.

...

System freeze after i/o errors at 7 % of copying process scale.

Do you get anything in /var/log/messages or on the console? -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340

Petr Nejedly

20:31

New subject: New cdrwtool (trying to format too many blocks)

Peter Osterlund wrote:

...

On Wed, 6 Feb 2002, Sergiy Kudryk wrote:

...
Hello

Can anybody help ?

I can't successfully write to CDRW disc a large file (> 50 MB) - too many i/o errors.

How i can decrease writing speed of pktcdvd layer ?

You have to edit the source code. In the pkt_open_write function, there is a call to pkt_adjust_speed. Change the "16" to the speed you want to use.

...
I have CDRW drive with 4X write speed and when i start to copy big file (500 Mbytes) to /mnt/cdrw using mc system shows writing speed about 9 MB/s (should be no more then 600 KB/s).

Maybe if the writes start to fail, they can fail with a speed faster than 600Kb/s.

No, the truth is that the data is "copied" to buffer cache and that does the writing in the background. I consider this very unfortunate solution as I have a e.g. network connection faster than the HDD and when copying big files from the network to the disk, it eats all my memory for caches (Having 256MB and every app starts to swap heavily).

...

...
System freeze after i/o errors at 7 % of copying process scale.

Do you get anything in /var/log/messages or on the console?

-- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340

-- To unsubscribe, e-mail: packet-writing-unsubscribe@suse.com For additional commands, e-mail: packet-writing-help@suse.com

Peter Osterlund

20:39

New subject: New cdrwtool (trying to format too many blocks)

On Wed, 6 Feb 2002, Petr Nejedly wrote:

...

Peter Osterlund wrote:

...
On Wed, 6 Feb 2002, Sergiy Kudryk wrote:

...
Hello

Can anybody help ?

I can't successfully write to CDRW disc a large file (> 50 MB) - too many i/o errors.

How i can decrease writing speed of pktcdvd layer ?

You have to edit the source code. In the pkt_open_write function, there is a call to pkt_adjust_speed. Change the "16" to the speed you want to use.

...
I have CDRW drive with 4X write speed and when i start to copy big file (500 Mbytes) to /mnt/cdrw using mc system shows writing speed about 9 MB/s (should be no more then 600 KB/s).

Maybe if the writes start to fail, they can fail with a speed faster than 600Kb/s.

No, the truth is that the data is "copied" to buffer cache and that does the writing in the background.

Yes I know that, but I thought the phrase "system shows writing speed ..." was referring to information from "vmstat" or equivalent, which shows how much data goes to the device. If the 9Mb/s value came from mc, I agree the information is not very useful because of the caching. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340

Sergiy Kudryk

8 Feb 8 Feb

14:37

New subject: New cdrwtool (trying to format too many blocks)

Hello Peter Unfortunally your hint doesn't help me to achieve stable writing (synchronously or in background) to CDRW disc. Copying any big portion of data (tested with mc help) failed after few second with message "no space left on device" on console and many i/o errors in /var/log/messages Here some logs: 1)-- file 100MB, writing speed 4X, ide-scsi mode , write cashing enabled, buffer 512, hdc dma off -- Feb 7 15:01:04 my kernel: pktcdvd: inserted media is CD-RW Feb 7 15:01:04 my kernel: pktcdvd: Fixed packets, 32 blocks, Mode-2 disc Feb 7 15:01:04 my kernel: pktcdvd: enabled write caching on pktcdvd0 Feb 7 15:01:04 my kernel: pktcdvd: speed (R/W) 12/8 Feb 7 15:01:04 my kernel: pktcdvd: 590528kB available on disc Feb 7 15:01:05 my kernel: UDF-fs INFO UDF 0.9.5-rw (2001/10/10) Mounting volume 'LinuxUDF', timestamp 2002/02/07 13:15 (1078) Feb 7 15:01:37 my kernel: I/O error: dev 0b:00, sector 6272 Feb 7 15:01:37 my kernel: udf: udf_read_inode(ino 1568) failed !bh Feb 7 15:02:01 my kernel: pktcdvd: inserted media is CD-RW Feb 7 15:02:01 my kernel: pktcdvd: Fixed packets, 32 blocks, Mode-2 disc Feb 7 15:02:01 my kernel: pktcdvd: enabled write caching on pktcdvd0 Feb 7 15:02:01 my kernel: pktcdvd: speed (R/W) 12/8 Feb 7 15:02:01 my kernel: pktcdvd: 590528kB available on disc Feb 7 15:02:03 my kernel: UDF-fs INFO UDF 0.9.5-rw (2001/10/10) Mounting volume 'LinuxUDF', timestamp 2002/02/07 13:15 (1078) Feb 7 15:02:54 my kernel: I/O error: dev 0b:00, sector 6144 Feb 7 15:02:54 my kernel: Ignoring read error on sector:6144 Feb 7 15:02:54 my kernel: I/O error: dev 0b:00, sector 14208 Feb 7 15:02:54 my kernel: Ignoring read error on sector:14208 .. # Comment: first atempt to read (mnt -t udf /dev/pktcdvd0 /mnt/cdrw -o rw,noatime) # formatted disc (15:01:37) fails with error "directory lostfound exist but cannot be stated", # after disc remounting this error disappear 2) -- multiple files (300MB), hdc dma on, write cashing enabled, cache size 512KB, 4X speed,.. Feb 7 15:30:31 my kernel: pktcdvd: inserted media is CD-RW Feb 7 15:30:31 my kernel: pktcdvd: Fixed packets, 32 blocks, Mode-2 disc Feb 7 15:30:31 my kernel: pktcdvd: enabled write caching on pktcdvd0 Feb 7 15:30:31 my kernel: pktcdvd: speed (R/W) 12/8 Feb 7 15:30:31 my kernel: pktcdvd: 590528kB available on disc Feb 7 15:30:32 my kernel: UDF-fs INFO UDF 0.9.5-rw (2001/10/10) Mounting volume 'LinuxUDF', timestamp 2002/02/07 13:15 (1078) Feb 7 15:31:29 my su(pam_unix)[929]: session opened for user root by serge(uid=500) Feb 7 15:31:34 my kernel: pktcdvd: inserted media is CD-RW Feb 7 15:31:34 my kernel: pktcdvd: Fixed packets, 32 blocks, Mode-2 disc Feb 7 15:31:34 my kernel: pktcdvd: enabled write caching on pktcdvd0 Feb 7 15:31:34 my kernel: pktcdvd: speed (R/W) 12/8 Feb 7 15:31:34 my kernel: pktcdvd: 590528kB available on disc Feb 7 15:31:36 my kernel: UDF-fs INFO UDF 0.9.5-rw (2001/10/10) Mounting volume 'LinuxUDF', timestamp 2002/02/07 13:15 (1078) Feb 7 15:32:13 my kernel: I/O error: dev 0b:00, sector 5648 Feb 7 15:32:13 my kernel: Ignoring read error on sector:5648 ... Feb 7 15:32:41 my kernel: Ignoring read error on sector:1400 Feb 7 15:32:41 my kernel: Ignoring read error on sector:1404 Feb 7 15:32:42 my kernel: I/O error: dev 0b:00, sector 124548 Feb 7 15:32:44 my last message repeated 855 times Feb 7 15:32:54 my kernel: I/O error: dev 0b:00, sector 213988 Feb 7 15:32:54 my kernel: I/O error: dev 0b:00, sector 213988 Feb 7 15:32:54 my kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000034 Feb 7 15:32:54 my kernel: printing eip: Feb 7 15:32:54 my kernel: c0173c07 Feb 7 15:32:54 my kernel: *pde = 00000000 Feb 7 15:32:54 my kernel: Oops: 0000 Feb 7 15:32:54 my kernel: CPU: 0 Feb 7 15:32:54 my kernel: EIP: 0010:[udf_add_entry+2407/3044] Not tainted Feb 7 15:32:54 my kernel: EIP: 0010:[<c0173c07>] Not tainted Feb 7 15:32:54 my kernel: EFLAGS: 00010246 Feb 7 15:32:54 my kernel: eax: 00000000 ebx: c580ea40 ecx: 00000100 edx: 000000d8 Feb 7 15:32:54 my kernel: esi: c580ea40 edi: c95a5f50 ebp: c95a5ec4 esp: c95a5b48 Feb 7 15:32:54 my kernel: ds: 0018 es: 0018 ss: 0018 Feb 7 15:32:54 my kernel: Process mc (pid: 964, stackpage=c95a5000) Feb 7 15:32:54 my kernel: Stack: c580ea40 c580e860 c95a5f50 c95a5ba0 00000000 c95a5ba4 c95a5ba8 00000000 Feb 7 15:32:54 my kernel: 00000000 00000000 00000000 1e000000 00000028 00000036 00000000 00000000 Feb 7 15:32:54 my kernel: c9c72fac ca38dc00 0000cb79 0000005e 00000000 00000000 00000000 00000000 Feb 7 15:32:54 my kernel: Call Trace: [udf_add_aext+1051/1248] [getblk+24/64] [bread+34/108] [udf_tread+52/56] [udf_fileident_read+546/1016] Feb 7 15:32:54 my kernel: Call Trace: [<c0171827>] [<c012fd3c>] [<c012ff2a>] [<c0179e9c>] [<c0179a3e>] Feb 7 15:32:54 my kernel: [getblk+24/64] [bread+34/108] [udf_find_entry+726/1204] [udf_release_data+14/20] [udf_find_entry+1186/1204] [ext3_get_block_handle+133/580] Feb 7 15:32:54 my kernel: [<c012fd3c>] [<c012ff2a>] [<c0173002>] [<c017a56a>] [<c01731ce>] [<c014d899>] Feb 7 15:32:54 my kernel: [do_get_write_access+1135/1172] [__journal_file_buffer+133/400] [udf_bitmap_new_block+180/1676] [udf_bitmap_new_block+1597/1676] [udf_get_pblock+109/128] [udf_new_inode+612/652] Feb 7 15:32:54 my kernel: [<c0154fdb>] [<c0155ee5>] [<c016be84>] [<c016c40d>] [<c0175b7d>] [<c016e278>] Feb 7 15:32:54 my kernel: [udf_mkdir+116/568] [in_group_p+30/40] [vfs_permission+115/240] [vfs_mkdir+116/172] [sys_mkdir+137/208] [system_call+51/64] Feb 7 15:32:54 my kernel: [<c0174214>] [<c011e63a>] [<c0135f6f>] [<c0137584>] [<c0137645>] [<c0106d33>] Feb 7 15:32:54 my kernel: Feb 7 15:32:54 my kernel: Code: 8b 40 34 01 c2 89 95 c4 fc ff ff e9 52 01 00 00 8b 4d 10 89 Feb 7 15:32:54 my kernel: I/O error: dev 0b:00, sector 6144 Feb 7 15:32:54 my kernel: Ignoring read error on sector:6144 .. Yes you right - speed rate reported by mc is related only for system data caching. So i try to do all data transfer synchronously: mount -t udf /dev/pktcdvd0 /mnt/cdrw -o noatime,rw,sync After mounting i get more realtime write process (like Windows DirectCD does) but after few seconds of writing with mc i get "segmentation fault" error ... System messages from /var/log/messages are the same - "kernel: Ignoring read error on sector: NNNN" In any case after write fault i can't unmount disc (get error "device is busy") - device is locked. Any help ? Thanks. Regards, Sergiy Kudryk --- Peter Osterlund wrote:

...

On Wed, 6 Feb 2002, Petr Nejedly wrote:

...
Peter Osterlund wrote:

...
On Wed, 6 Feb 2002, Sergiy Kudryk wrote:

...
Hello

Can anybody help ?

I can't successfully write to CDRW disc a large file (> 50 MB) - too many i/o errors.

How i can decrease writing speed of pktcdvd layer ?

You have to edit the source code. In the pkt_open_write function, there is a call to pkt_adjust_speed. Change the "16" to the speed you want to use.

...
I have CDRW drive with 4X write speed and when i start to copy big file (500 Mbytes) to /mnt/cdrw using mc system shows writing speed about 9 MB/s (should be no more then 600 KB/s).

Maybe if the writes start to fail, they can fail with a speed faster than 600Kb/s.

No, the truth is that the data is "copied" to buffer cache and that does the writing in the background.

Yes I know that, but I thought the phrase "system shows writing speed ..." was referring to information from "vmstat" or equivalent, which shows how much data goes to the device. If the 9Mb/s value came from mc, I agree the information is not very useful because of the caching.

-- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340

...

__________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com

Peter Osterlund

20:15

New subject: New cdrwtool (trying to format too many blocks)

On Fri, 8 Feb 2002, Sergiy Kudryk wrote:

...

Hello Peter

Unfortunally your hint doesn't help me to achieve stable writing (synchronously or in background) to CDRW disc.

Copying any big portion of data (tested with mc help) failed after few second with message "no space left on device" on console and many i/o errors in /var/log/messages

Is the same disc working in DirectCD in windows? A worn out disc would probably generate the same errors you are seeing. Another thing you could try is to make the read speed equal to the write speed. Your drive/disc combination seemed to be able to handle 8x, so you could use this patch. (I have no idea if this will really help.) --- pktcdvd.c.old Fri Feb 8 21:09:59 2002 +++ pktcdvd.c Fri Feb 8 21:09:17 2002 @@ -1670,7 +1670,7 @@ * and gather data. maybe 1/1 factor is faster, needs a bit of testing. */ speed = speed * 0xb0; - read_speed = (speed * 3) >> 1; + read_speed = speed; read_speed = min_t(unsigned, read_speed, 0xffff); init_cdrom_command(&cgc, NULL, 0, CGC_DATA_NONE); @@ -1784,7 +1784,7 @@ (void) pkt_write_caching(pd, USE_WCACHING); - if ((ret = pkt_adjust_speed(pd, 16))) { + if ((ret = pkt_adjust_speed(pd, 8))) { DPRINTK("pktcdvd: %s couldn't set write speed\n", pd->name); return -EIO; }

...

Feb 7 15:31:34 my kernel: pktcdvd: Fixed packets, 32 blocks, Mode-2 disc Feb 7 15:31:34 my kernel: pktcdvd: enabled write caching on pktcdvd0 Feb 7 15:31:34 my kernel: pktcdvd: speed (R/W) 12/8 Feb 7 15:31:34 my kernel: pktcdvd: 590528kB available on disc Feb 7 15:31:36 my kernel: UDF-fs INFO UDF 0.9.5-rw (2001/10/10) Mounting volume 'LinuxUDF', timestamp 2002/02/07 13:15 (1078) Feb 7 15:32:13 my kernel: I/O error: dev 0b:00, sector 5648 Feb 7 15:32:13 my kernel: Ignoring read error on sector:5648 ...

Feb 7 15:32:41 my kernel: Ignoring read error on sector:1400 Feb 7 15:32:41 my kernel: Ignoring read error on sector:1404 Feb 7 15:32:42 my kernel: I/O error: dev 0b:00, sector 124548 Feb 7 15:32:44 my last message repeated 855 times Feb 7 15:32:54 my kernel: I/O error: dev 0b:00, sector 213988 Feb 7 15:32:54 my kernel: I/O error: dev 0b:00, sector 213988 Feb 7 15:32:54 my kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000034 Feb 7 15:32:54 my kernel: printing eip: Feb 7 15:32:54 my kernel: c0173c07 Feb 7 15:32:54 my kernel: *pde = 00000000 Feb 7 15:32:54 my kernel: Oops: 0000 Feb 7 15:32:54 my kernel: CPU: 0 Feb 7 15:32:54 my kernel: EIP: 0010:[udf_add_entry+2407/3044] Not tainted

...

In any case after write fault i can't unmount disc (get error "device is busy") - device is locked.

It seems the udf filesystem can't handle the massive amount of media errors you get. Instead it oopses and the device is left in "busy" state. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340

Carlo

17:48

New subject: New cdrwtool (trying to format too many blocks)

Alle 21:18, mercoledì 6 febbraio 2002, hai scritto:

...

On Wed, 6 Feb 2002, Sergiy Kudryk wrote:

...
Hello

Can anybody help ?

I can't successfully write to CDRW disc a large file (> 50 MB) - too many i/o errors.

How i can decrease writing speed of pktcdvd layer ?

You have to edit the source code. In the pkt_open_write function, there is a call to pkt_adjust_speed. Change the "16" to the speed you want to use.

Me too have a 4x diskwriter. It mean that the packet-cd write at 16? I don't have any problem to write big files (41 Mb writes without problems,program used mc). This is any problem for the cd-writer lens in the long term (and i have to adjust the pkt_adjust_speed.) or i can leave the speed at 16 (that is obviously ignored). Carlo. P.s.: Tested 2.4.18-pre7 patch (cache enabled 4096) and udftools 1.0.0b1 with patch -v it work very well, also with Directcd 5.0. If i increase cache i can increase the speed with large number of little files.

Sergiy Kudryk

18:22

New subject: patch problem ?

Hello Ben After applying your new patch (changing udf version) i don't get correct (as it seems to me) lead_out value for Verbatim CDRW disc 700 MB: [root@my etc]# cdrwtool -d /dev/sr0 -i using device /dev/sr0 1312KB internal buffer setting write speed to 12x DISC INFO: erasable : Yes border = 3 Disc status = 2 number of first track = 1 number of sessions = 1 number of tracks = 1 status of last track = 1 uru = 0 did_v = 1 dbc_v = 0 disc type = 32 disc_id = 3555345 lead_in = 255:255:255 (1166880) lead_out = 255:255:255 (1166880) OPC entries = 2 TRACK INFO: Track 1 track_number = 1 session_number = 1 damage = 0 copy = 0 track_mode = 7 Rt = 1 blank = 0 packet = 1 fp = 1 data_mode = 2 lra_v = 0 nwa_v = 0 track_start = 0 next_writable = 0 last_recorded = 0 free_blocks = 0 packet_size = 32 track_size = 295264 (590528KB) Nevertheless i can format CDRW disc without errors using option -v 0x0150 Before this pacth i have: serge@my 1.0.0a]# cdrwtool -d /dev/sr0 -i using device /dev/sr0 1312KB internal buffer setting write speed to 12x DISC INFO: erasable : Yes border = 0 Disc status = 0 number of first track = 1 number of sessions = 1 number of tracks = 1 status of last track = 1 uru = 0 did_v = 0 dbc_v = 0 disc type = 255 disc_id = 0 lead_in = 97:34:22 (439072) lead_out = 79:59:74 (359999) OPC entries = 0 TRACK INFO: Track 1 track_number = 1 session_number = 1 damage = 0 copy = 0 track_mode = 4 Rt = 0 blank = 1 packet = 0 fp = 0 data_mode = 15 lra_v = 0 nwa_v = 1 track_start = 0 next_writable = 0 last_recorded = 0 free_blocks = 359847 packet_size = 0 track_size = 359847 (719694KB) Any comment ? Regards, Sergiy Kudryk. --- Ben Fennema wrote:

...

On Tue, Feb 05, 2002 at 08:26:46AM +0100, Norbert Preining wrote:

...
On Mon, 04 Feb 2002, Ben Fennema wrote:

...
-q runs mkudffs, and happens to default to udf 2.01 and not 1.5 which is most likely why windows can't read the disc. I just added a flag yesterday to set the udf version under cdrwtool - so the current version has no way to change to 1.5, without mounting via pktsetup and running mkudffs directly on /dev/pktcdvd0..

.... __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com

Ben Fennema

9 Feb 9 Feb

01:33

New subject: patch problem ?

On Fri, Feb 08, 2002 at 10:23:48AM -0800, Sergiy Kudryk wrote:

...

Hello Ben

After applying your new patch (changing udf version) i don't get correct (as it seems to me) lead_out value for Verbatim CDRW disc 700 MB:

Some drives don't report a value for lead_out when the disk isn't blank.. Ben

Drew Parsons

4 Feb 4 Feb

14:26

New subject: New cdrwtool, mkudffs fails? (HP8230e)

On Fri, Feb 01, 2002 at 10:57:08AM -0800, Ben Fennema wrote:

...

Ok, give this patch a try.. It should fix the problem.

Ben

diff -u -p -r1.3 main.c --- main.c 2002/01/30 21:39:59 1.3 +++ main.c 2002/02/01 18:48:13 @@ -136,7 +136,7 @@ int quick_setup(int fd, struct cdrw_disc return ret;

blocks = msf_to_lba(di.lead_out_m, di.lead_out_s, di.lead_out_f) - 152; - if (disc->fpacket && !(ti.packet && ti.fp)) + if (disc->fpacket) { /* fixed packets format usable blocks */ blocks = ((blocks + 7) / (disc->packet_size + 7)) * disc->packet_size;

I've just upgraded to the 2.4.18-pre7 patch, applying to the 2.4.17 kernel (is this a problem?), with udftools 1.0.0b1. I needed to add the patch given above. Now formatting still works (still 40 min), but writing UDF structures fails, although cdrwtool still claims it finished succcessfully: # cdrwtool -d /dev/sr1 -t 4 -q using device /dev/sr1 setting speed to 4 4085KB internal buffer setting write speed to 4x Settings for /dev/sr1: Fixed packets, size 32 Mode-2 disc I'm going to do a quick setup of /dev/sr1. The disc is going to be blanked and formatted with one big track. All data on the device will be lost!! Press CTRL-C to cancel now. ENTER to continue. Initiating quick disc blank Disc capacity is 275744 blocks (551488KB/538MB) Formatting track start=0, blocks=16, type=RESERVED start=16, blocks=3, type=VRS start=19, blocks=237, type=USPACE start=256, blocks=1, type=ANCHOR start=257, blocks=31, type=USPACE start=288, blocks=32, type=PVDS start=320, blocks=32, type=LVID start=352, blocks=32, type=STABLE start=384, blocks=1024, type=SSPACE start=1408, blocks=274048, type=PSPACE start=275456, blocks=31, type=USPACE start=275487, blocks=1, type=ANCHOR start=275488, blocks=160, type=USPACE start=275648, blocks=32, type=STABLE start=275680, blocks=32, type=RVDS start=275712, blocks=31, type=USPACE start=275743, blocks=1, type=ANCHOR Writing UDF structures to disc wait_cmd: Invalid argument Command failed: 2a 00 00 00 01 00 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 01 20 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 01 40 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 01 60 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 05 80 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 05 a0 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 05 c0 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 05 e0 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 06 00 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 06 20 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 04 34 00 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 04 34 c0 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 04 34 e0 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 04 35 00 00 00 20 00 00 00 - sense 05.24.00 Quick setup complete! Predictably, using the CD fails: # pktsetup /dev/pktcdvd0 /dev/sr1 # mount /dev/pktcdvd0 /cdrom -t udf -o rw,noatime mount: /dev/pktcdvd0: can't read superblock Excerpts from the log (from FORMAT_UNIT) look like: ... Feb 5 00:25:59 strider kernel: usb-storage: Command FORMAT_UNIT (6 bytes) Feb 5 00:25:59 strider kernel: usb-storage: 04 17 00 00 00 00 00 00 00 00 00 00 Feb 5 00:25:59 strider kernel: usb-storage: Status = 50 Feb 5 00:25:59 strider kernel: usb-storage: In hp8200e_transport() before usb_rw_block_test() for SCSI_DATA_WRITE. Feb 5 00:25:59 strider kernel: usb-storage: Transferred out 38 of 38 bytes Feb 5 00:25:59 strider kernel: usb-storage: Transferred out 16 of 16 bytes Feb 5 00:25:59 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 75 minutes. Feb 5 00:38:01 strider /USR/SBIN/CRON[1627]: (mail) CMD ( if [ -x /usr/sbin/exim -a -f /etc/exim/exim.conf ]; then /usr/sbin/exim -q ; fi) Feb 5 00:53:01 strider /USR/SBIN/CRON[1649]: (mail) CMD ( if [ -x /usr/sbin/exim -a -f /etc/exim/exim.conf ]; then /usr/sbin/exim -q ; fi) Feb 5 01:05:22 strider kernel: usb-storage: Waited not busy for 3463 steps Feb 5 01:05:22 strider kernel: usb-storage: In hp8200e_transport(), usb_rw_block_test() complete with result=0. Feb 5 01:05:22 strider kernel: usb-storage: Wrote 0000004C bytes Feb 5 01:05:22 strider kernel: usb-storage: scsi cmd done, result=0x0 Feb 5 01:05:22 strider kernel: usb-storage: *** thread sleeping. Feb 5 01:05:22 strider kernel: usb-storage: queuecommand() called Feb 5 01:05:22 strider kernel: usb-storage: *** thread awakened. Feb 5 01:05:22 strider kernel: usb-storage: Command WRITE_10 (10 bytes) Feb 5 01:05:22 strider kernel: usb-storage: 2a 00 00 00 00 00 00 00 20 00 00 00 Feb 5 01:05:22 strider kernel: usb-storage: Status = 50 Feb 5 01:05:22 strider kernel: usb-storage: In hp8200e_transport() before usb_rw_block_test() for SCSI_DATA_WRITE. Feb 5 01:05:22 strider kernel: usb-storage: Transferred out 38 of 38 bytes Feb 5 01:05:22 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 75 minutes. Feb 5 01:05:22 strider kernel: usb-storage: Waited not busy for 1 steps Feb 5 01:05:22 strider kernel: usb-storage: In hp8200e_transport(), usb_rw_block_test() complete with result=0. Feb 5 01:05:22 strider kernel: usb-storage: Wrote 0001004C bytes Feb 5 01:05:22 strider kernel: usb-storage: scsi cmd done, result=0x0 Feb 5 01:05:22 strider kernel: usb-storage: *** thread sleeping. Feb 5 01:05:22 strider kernel: usb-storage: queuecommand() called Feb 5 01:05:22 strider kernel: usb-storage: *** thread awakened. Feb 5 01:05:22 strider kernel: usb-storage: Command WRITE_10 (10 bytes) Feb 5 01:05:22 strider kernel: usb-storage: 2a 00 00 00 01 00 00 00 20 00 00 00 Feb 5 01:05:22 strider kernel: usb-storage: Status = 58 Feb 5 01:05:22 strider kernel: usb-storage: In hp8200e_transport() before usb_rw_block_test() for SCSI_DATA_WRITE. Feb 5 01:05:22 strider kernel: usb-storage: Transferred out 38 of 38 bytes Feb 5 01:05:22 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 75 minutes. Feb 5 01:05:22 strider kernel: usb-storage: In hp8200e_transport(), usb_rw_block_test() complete with result=1. Feb 5 01:05:22 strider kernel: usb-storage: -- transport indicates command failure Feb 5 01:05:22 strider kernel: usb-storage: Issuing auto-REQUEST_SENSE Feb 5 01:05:22 strider kernel: usb-storage: Status = 00 Feb 5 01:05:22 strider kernel: usb-storage: Transferred out 14 of 14 bytes Feb 5 01:05:22 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 0 minutes. Feb 5 01:05:22 strider kernel: usb-storage: Waited not busy for 0 steps Feb 5 01:05:22 strider kernel: usb-storage: In hp8200e_transport() before usb_write_block(), cmnd = 0x3. Feb 5 01:05:22 strider kernel: usb-storage: Transferred out 12 of 12 bytes Feb 5 01:05:22 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 10 minutes. Feb 5 01:05:22 strider kernel: usb-storage: Waited not busy for 1 steps Feb 5 01:05:22 strider kernel: usb-storage: Transferred in 18 of 18 bytes Feb 5 01:05:22 strider kernel: usb-storage: 70 00 05 00 00 00 00 12 00 00 00 00 24 00 00 C0 Feb 5 01:05:22 strider kernel: usb-storage: 00 02 Feb 5 01:05:22 strider kernel: usb-storage: -- Result from auto-sense is 0 Feb 5 01:05:22 strider kernel: usb-storage: -- code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0 Feb 5 01:05:22 strider kernel: usb-storage: Illegal Request: invalid field in CDB Feb 5 01:05:22 strider kernel: usb-storage: scsi cmd done, result=0x2 Feb 5 01:05:22 strider kernel: usb-storage: *** thread sleeping. ... Feb 5 01:05:23 strider kernel: sr1: CDROM (ioctl) reports ILLEGAL REQUEST. Feb 5 01:05:23 strider kernel: usb-storage: queuecommand() called Feb 5 01:05:23 strider kernel: usb-storage: *** thread awakened. Feb 5 01:05:23 strider kernel: usb-storage: Command SYNCHRONIZE_CACHE (10 bytes) Feb 5 01:05:23 strider kernel: usb-storage: 35 02 00 00 00 00 00 00 00 00 00 00 Feb 5 01:05:23 strider kernel: usb-storage: Status = 50 Feb 5 01:05:23 strider kernel: usb-storage: Transferred out 14 of 14 bytes Feb 5 01:05:23 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 0 minutes. Feb 5 01:05:23 strider kernel: usb-storage: Waited not busy for 0 steps Feb 5 01:05:23 strider kernel: usb-storage: In hp8200e_transport() before usb_write_block(), cmnd = 0x35. Feb 5 01:05:23 strider kernel: usb-storage: Transferred out 12 of 12 bytes Feb 5 01:05:23 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 10 minutes. Feb 5 01:05:23 strider kernel: usb-storage: Waited not busy for 0 steps Feb 5 01:05:23 strider kernel: usb-storage: scsi cmd done, result=0x0 Feb 5 01:05:23 strider kernel: usb-storage: *** thread sleeping. Feb 5 01:05:23 strider kernel: usb-storage: queuecommand() called Feb 5 01:05:23 strider kernel: usb-storage: *** thread awakened. Feb 5 01:05:23 strider kernel: usb-storage: Command ALLOW_MEDIUM_REMOVAL (6 bytes) Feb 5 01:05:23 strider kernel: usb-storage: 1e 00 00 00 00 00 00 00 e0 f9 7a c5 Feb 5 01:05:23 strider kernel: usb-storage: Status = 50 Feb 5 01:05:23 strider kernel: usb-storage: Transferred out 14 of 14 bytes Feb 5 01:05:23 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 0 minutes. Feb 5 01:05:23 strider kernel: usb-storage: Waited not busy for 0 steps Feb 5 01:05:23 strider kernel: usb-storage: In hp8200e_transport() before usb_write_block(), cmnd = 0x1e. Feb 5 01:05:23 strider kernel: usb-storage: Transferred out 12 of 12 bytes Feb 5 01:05:23 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 10 minutes. Feb 5 01:05:23 strider kernel: usb-storage: Waited not busy for 0 steps Feb 5 01:05:23 strider kernel: usb-storage: scsi cmd done, result=0x0 Feb 5 01:05:23 strider kernel: usb-storage: *** thread sleeping. Feb 5 01:05:23 strider kernel: usb-storage: queuecommand() called Feb 5 01:05:23 strider kernel: usb-storage: *** thread awakened. Feb 5 01:05:23 strider kernel: usb-storage: Command ALLOW_MEDIUM_REMOVAL (6 bytes) Feb 5 01:05:23 strider kernel: usb-storage: 1e 00 00 00 00 00 7a c5 00 00 00 00 Feb 5 01:05:23 strider kernel: usb-storage: Status = 50 Feb 5 01:05:23 strider kernel: usb-storage: Transferred out 14 of 14 bytes Feb 5 01:05:23 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 0 minutes. Feb 5 01:05:23 strider kernel: usb-storage: Waited not busy for 0 steps Feb 5 01:05:23 strider kernel: usb-storage: In hp8200e_transport() before usb_write_block(), cmnd = 0x1e. Feb 5 01:05:23 strider kernel: usb-storage: Transferred out 12 of 12 bytes Feb 5 01:05:23 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 10 minutes. Feb 5 01:05:23 strider kernel: usb-storage: Waited not busy for 0 steps Feb 5 01:05:23 strider kernel: usb-storage: scsi cmd done, result=0x0 Feb 5 01:05:23 strider kernel: usb-storage: *** thread sleeping. Feb 5 01:08:01 strider /USR/SBIN/CRON[1670]: (mail) CMD ( if [ -x /usr/sbin/exim -a -f /etc/exim/exim.conf ]; then /usr/sbin/exim -q ; fi) cdrwtool -i then gives: # cdrwtool -d /dev/sr1 -t 4 -i using device /dev/sr1 setting speed to 4 4085KB internal buffer setting write speed to 4x wait_cmd: Invalid argument Command failed: bb 00 ff ff 02 c0 00 00 00 00 00 00 - sense 05.24.00 set speed or upon resetting (pulling the USB cord out and back in): # cdrwtool -d /dev/sr1 -t 4 -i using device /dev/sr1 setting speed to 4 4085KB internal buffer setting write speed to 4x DISC INFO: erasable : Yes border = 3 Disc status = 2 number of first track = 1 number of sessions = 1 number of tracks = 1 status of last track = 1 uru = 0 did_v = 1 dbc_v = 0 disc type = 32 disc_id = 5476675 lead_in = 255:255:255 (1166880) lead_out = 74:43:00 (336225) OPC entries = 0 TRACK INFO: Track 1 track_number = 1 session_number = 1 damage = 0 copy = 0 track_mode = 5 Rt = 1 blank = 0 packet = 1 fp = 1 data_mode = 2 lra_v = 0 nwa_v = 0 track_start = 0 next_writable = 4294967295 last_recorded = 0 free_blocks = 0 packet_size = 32 track_size = 275744 (551488KB) That's all for now. Drew ps I'd still like to hear if I must do cdrwtool -q next time and wait the 40 min all over again, or can I avoid that? -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A

Ben Fennema

6 Feb 6 Feb

08:30

New subject: New cdrwtool, mkudffs fails? (HP8230e)

...

Writing UDF structures to disc wait_cmd: Invalid argument Command failed: 2a 00 00 00 01 00 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 01 20 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 01 40 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 01 60 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 05 80 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 05 a0 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 05 c0 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 05 e0 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 06 00 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 00 06 20 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 04 34 00 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 04 34 c0 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 04 34 e0 00 00 20 00 00 00 - sense 05.24.00 wait_cmd: Invalid argument Command failed: 2a 00 00 04 35 00 00 00 20 00 00 00 - sense 05.24.00

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)... If you run mkudffs on /dev/pktcdvd0, can you get it to format (you probably need to specify the number of blocks)? Or do you get the same type of errors... You could also try generating a multi-packet chunk of data and writing it to the disc using cdrwtool -f <file> and see if you can get it to write more than just the first packet... Here's the first (theoretically successful) write...

...

Feb 5 01:05:22 strider kernel: usb-storage: Command WRITE_10 (10 bytes) Feb 5 01:05:22 strider kernel: usb-storage: 2a 00 00 00 00 00 00 00 20 00 00 00 Feb 5 01:05:22 strider kernel: usb-storage: Status = 50 Feb 5 01:05:22 strider kernel: usb-storage: In hp8200e_transport() before usb_rw_block_test() for SCSI_DATA_WRITE. Feb 5 01:05:22 strider kernel: usb-storage: Transferred out 38 of 38 bytes Feb 5 01:05:22 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 75 minutes. Feb 5 01:05:22 strider kernel: usb-storage: Waited not busy for 1 steps Feb 5 01:05:22 strider kernel: usb-storage: In hp8200e_transport(), usb_rw_block_test() complete with result=0. Feb 5 01:05:22 strider kernel: usb-storage: Wrote 0001004C bytes Feb 5 01:05:22 strider kernel: usb-storage: scsi cmd done, result=0x0 Feb 5 01:05:22 strider kernel: usb-storage: *** thread sleeping. Feb 5 01:05:22 strider kernel: usb-storage: queuecommand() called Feb 5 01:05:22 strider kernel: usb-storage: *** thread awakened.

And this one seems to fail.. Know what the Status = XX means?

...

Feb 5 01:05:22 strider kernel: usb-storage: Command WRITE_10 (10 bytes) Feb 5 01:05:22 strider kernel: usb-storage: 2a 00 00 00 01 00 00 00 20 00 00 00 Feb 5 01:05:22 strider kernel: usb-storage: Status = 58 Feb 5 01:05:22 strider kernel: usb-storage: In hp8200e_transport() before usb_rw_block_test() for SCSI_DATA_WRITE. Feb 5 01:05:22 strider kernel: usb-storage: Transferred out 38 of 38 bytes Feb 5 01:05:22 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 75 minutes. Feb 5 01:05:22 strider kernel: usb-storage: In hp8200e_transport(), usb_rw_block_test() complete with result=1.

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. The track_mode is kinda funky.. 5 is, the way I read it - saying digital copy is prohibited.. which is strange since we turn bit 2 on explicitly.. *shrug* Dunno what that means =) Ben

Drew Parsons

13:48

New subject: New cdrwtool, mkudffs fails? (HP8230e)

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?

...

If you run mkudffs on /dev/pktcdvd0, can you get it to format (you probably need to specify the number of blocks)? Or do you get the same type of errors...

It appeared to run with no extra arguments, put no error messages to stdout: # mkudffs /dev/pktcdvd0 start=0, blocks=16, type=RESERVED start=16, blocks=3, type=VRS start=19, blocks=237, type=USPACE start=256, blocks=1, type=ANCHOR start=257, blocks=16, type=PVDS start=273, blocks=1, type=LVID start=274, blocks=275213, type=PSPACE start=275487, blocks=1, type=ANCHOR start=275488, blocks=239, type=USPACE start=275727, blocks=16, type=RVDS start=275743, blocks=1, type=ANCHOR But I'm not sure about syslog: Feb 6 22:49:07 strider kernel: usb-storage: Command MODE_SELECT_10 (10 bytes) Feb 6 22:49:07 strider kernel: usb-storage: 55 10 00 00 00 00 00 00 14 00 00 00 Feb 6 22:49:07 strider kernel: usb-storage: Status = 50 Feb 6 22:49:07 strider kernel: usb-storage: In hp8200e_transport() before usb_rw_block_test() for SCSI_DATA_WRITE. Feb 6 22:49:07 strider kernel: usb-storage: Transferred out 38 of 38 bytes Feb 6 22:49:07 strider kernel: usb-storage: Transferred out 20 of 20 bytes Feb 6 22:49:07 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 75 minutes. Feb 6 22:49:07 strider kernel: usb-storage: Waited not busy for 0 steps Feb 6 22:49:07 strider kernel: usb-storage: In hp8200e_transport(), usb_rw_block_test() complete with result=0. Feb 6 22:49:07 strider kernel: usb-storage: Wrote 00000050 bytes Feb 6 22:49:07 strider kernel: usb-storage: scsi cmd done, result=0x0 Feb 6 22:49:07 strider kernel: usb-storage: *** thread sleeping. Feb 6 22:49:07 strider kernel: usb-storage: queuecommand() called Feb 6 22:49:07 strider kernel: usb-storage: *** thread awakened. Feb 6 22:49:07 strider kernel: usb-storage: Command SET CD SPEED (12 bytes) Feb 6 22:49:07 strider kernel: usb-storage: bb 00 10 80 0b 00 00 00 00 00 00 00 Feb 6 22:49:07 strider kernel: usb-storage: Status = 50 Feb 6 22:49:07 strider kernel: usb-storage: Transferred out 14 of 14 bytes Feb 6 22:49:07 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 0 minutes. Feb 6 22:49:07 strider kernel: usb-storage: Waited not busy for 0 steps Feb 6 22:49:07 strider kernel: usb-storage: In hp8200e_transport() before usb_write_block(), cmnd = 0xbb. Feb 6 22:49:07 strider kernel: usb-storage: Transferred out 12 of 12 bytes Feb 6 22:49:07 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 10 minutes. Feb 6 22:49:07 strider kernel: usb-storage: In hp8200e_transport(), usb_write_block() complete with result=1. Feb 6 22:49:07 strider kernel: usb-storage: -- transport indicates command failure Feb 6 22:49:07 strider kernel: usb-storage: Issuing auto-REQUEST_SENSE Feb 6 22:49:07 strider kernel: usb-storage: Status = 00 Feb 6 22:49:07 strider kernel: usb-storage: Transferred out 14 of 14 bytes Feb 6 22:49:07 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 0 minutes. Feb 6 22:49:07 strider kernel: usb-storage: Waited not busy for 0 steps Feb 6 22:49:07 strider kernel: usb-storage: In hp8200e_transport() before usb_write_block(), cmnd = 0x3. Feb 6 22:49:07 strider kernel: usb-storage: Transferred out 12 of 12 bytes Feb 6 22:49:07 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 10 minutes. Feb 6 22:49:07 strider kernel: usb-storage: Waited not busy for 0 steps Feb 6 22:49:07 strider kernel: usb-storage: Transferred in 18 of 18 bytes Feb 6 22:49:07 strider kernel: usb-storage: 70 00 05 00 00 00 00 12 00 00 00 00 24 00 00 00 Feb 6 22:49:07 strider kernel: usb-storage: 00 00 Feb 6 22:49:07 strider kernel: usb-storage: -- Result from auto-sense is 0 Feb 6 22:49:07 strider kernel: usb-storage: -- code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0 Feb 6 22:49:07 strider kernel: usb-storage: Illegal Request: invalid field in CDB Feb 6 22:49:07 strider kernel: usb-storage: scsi cmd done, result=0x2 Feb 6 22:49:07 strider kernel: usb-storage: *** thread sleeping. Feb 6 22:49:07 strider kernel: sr1: CDROM (ioctl) reports ILLEGAL REQUEST. Feb 6 22:49:07 strider kernel: pktcdvd: pktcdvd0 couldn't set write speed Feb 6 22:49:07 strider kernel: usb-storage: queuecommand() called Feb 6 22:49:07 strider kernel: usb-storage: *** thread awakened. Feb 6 22:49:07 strider kernel: usb-storage: Command ALLOW_MEDIUM_REMOVAL (6 bytes) ... Setting the write speed seemed to fail. Does mkudffs default to 12x like cdrwtool does? I couldn't see any option to set it to 4x. And I still can't mount the CD (mount: /dev/pktcdvd0: can't read superblock).

...

You could also try generating a multi-packet chunk of data and writing it to the disc using cdrwtool -f <file> and see if you can get it to write more than just the first packet...

Seems to be a similar problem. netspace-homeadsl.pdf is 292840 bytes. # cdrwtool -d /dev/sr1 -t 4 -f netspace-homeadsl.pdf using device /dev/sr1 setting speed to 4 write file netspace-homeadsl.pdf 4085KB internal buffer setting write speed to 4x writing at lba = 0, blocks = 32 writing at lba = 32, blocks = 32 wait_cmd: Invalid argument Command failed: 2a 00 00 00 00 20 00 00 20 00 00 00 - sense 05.24.00 Log file, from first WRITE_10, is: Feb 6 23:00:56 strider kernel: usb-storage: Command WRITE_10 (10 bytes) Feb 6 23:00:56 strider kernel: usb-storage: 2a 00 00 00 00 00 00 00 20 00 00 00 Feb 6 23:00:56 strider kernel: usb-storage: Status = 50 Feb 6 23:00:56 strider kernel: usb-storage: In hp8200e_transport() before usb_rw_block_test() for SCSI_DATA_WRITE. Feb 6 23:00:56 strider kernel: usb-storage: Transferred out 38 of 38 bytes Feb 6 23:00:56 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 75 minutes. Feb 6 23:00:56 strider kernel: usb-storage: Waited not busy for 1 steps Feb 6 23:00:56 strider kernel: usb-storage: In hp8200e_transport(), usb_rw_block_test() complete with result=0. Feb 6 23:00:56 strider kernel: usb-storage: Wrote 0001003C bytes Feb 6 23:00:56 strider kernel: usb-storage: scsi cmd done, result=0x0 Feb 6 23:00:56 strider kernel: usb-storage: *** thread sleeping. Feb 6 23:00:56 strider kernel: usb-storage: queuecommand() called Feb 6 23:00:56 strider kernel: usb-storage: *** thread awakened. Feb 6 23:00:56 strider kernel: usb-storage: Command SYNCHRONIZE_CACHE (10 bytes) Feb 6 23:00:56 strider kernel: usb-storage: 35 02 00 00 00 00 00 00 00 00 00 00 Feb 6 23:00:56 strider kernel: usb-storage: Status = 58 Feb 6 23:00:56 strider kernel: usb-storage: Transferred out 14 of 14 bytes Feb 6 23:00:56 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 0 minutes. Feb 6 23:00:56 strider kernel: usb-storage: Waited not busy for 0 steps Feb 6 23:00:56 strider kernel: usb-storage: In hp8200e_transport() before usb_write_block(), cmnd = 0x35. Feb 6 23:00:56 strider kernel: usb-storage: Transferred out 12 of 12 bytes Feb 6 23:00:56 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 10 minutes. Feb 6 23:00:56 strider kernel: usb-storage: Waited not busy for 0 steps Feb 6 23:00:56 strider kernel: usb-storage: scsi cmd done, result=0x0 Feb 6 23:00:56 strider kernel: usb-storage: *** thread sleeping. Feb 6 23:00:56 strider kernel: usb-storage: queuecommand() called Feb 6 23:00:56 strider kernel: usb-storage: *** thread awakened. Feb 6 23:00:56 strider kernel: usb-storage: Command WRITE_10 (10 bytes) Feb 6 23:00:56 strider kernel: usb-storage: 2a 00 00 00 00 20 00 00 20 00 00 00 Feb 6 23:00:56 strider kernel: usb-storage: Status = 50 Feb 6 23:00:56 strider kernel: usb-storage: In hp8200e_transport() before usb_rw_block_test() for SCSI_DATA_WRITE. Feb 6 23:00:56 strider kernel: usb-storage: Transferred out 38 of 38 bytes Feb 6 23:00:56 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 75 minutes. Feb 6 23:00:56 strider kernel: usb-storage: In hp8200e_transport(), usb_rw_block_test() complete with result=1. Feb 6 23:00:56 strider kernel: usb-storage: -- transport indicates command failure Feb 6 23:00:56 strider kernel: usb-storage: Issuing auto-REQUEST_SENSE Feb 6 23:00:56 strider kernel: usb-storage: Status = 00 Feb 6 23:00:56 strider kernel: usb-storage: Transferred out 14 of 14 bytes Feb 6 23:00:56 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 0 minutes. Feb 6 23:00:57 strider kernel: usb-storage: Waited not busy for 0 steps Feb 6 23:00:57 strider kernel: usb-storage: In hp8200e_transport() before usb_write_block(), cmnd = 0x3. Feb 6 23:00:57 strider kernel: usb-storage: Transferred out 12 of 12 bytes Feb 6 23:00:57 strider kernel: usb-storage: In usbat_wait_not_busy(), waiting for 10 minutes. Feb 6 23:00:57 strider kernel: usb-storage: Waited not busy for 1 steps Feb 6 23:00:57 strider kernel: usb-storage: Transferred in 18 of 18 bytes Feb 6 23:00:57 strider kernel: usb-storage: 70 00 05 00 00 00 00 12 00 00 00 00 24 00 00 C0 Feb 6 23:00:57 strider kernel: usb-storage: 00 02 Feb 6 23:00:57 strider kernel: usb-storage: -- Result from auto-sense is 0 Feb 6 23:00:57 strider kernel: usb-storage: -- code: 0x70, key: 0x5, ASC: 0x24, ASCQ: 0x0 Feb 6 23:00:57 strider kernel: usb-storage: Illegal Request: invalid field in CDB Feb 6 23:00:57 strider kernel: usb-storage: scsi cmd done, result=0x2

...

Here's the first (theoretically successful) write...

...
Feb 5 01:05:22 strider kernel: usb-storage: Command WRITE_10 (10 bytes) Feb 5 01:05:22 strider kernel: usb-storage: 2a 00 00 00 00 00 00 00 20 00 00 00 Feb 5 01:05:22 strider kernel: usb-storage: Status = 50

And this one seems to fail.. Know what the Status = XX means?

Status is the (unsigned char) value, formatted as %02X, from: result = usbat_read(us, USBAT_ATA, 0x17, &status); in hp8200e_transport() of usb/storage/shuttle_usbat.c. usbat_read() defers definition of status to usbat_send_control(), where it is called xfer_data. Thence to usb_stor_control_msg(), which is defined in transport.c, where status is now known as "data". It then gets passed to FILL_CONTROL_URB, defined in linux/usb.h, in which the status (what is ultimately an input/output buffer), gets set to (argument d in FILL_CONTROL_URB): us->current_urb->transfer_buffer 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?

...

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. Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A

Ben Fennema

16:56

New subject: New cdrwtool, mkudffs fails? (HP8230e)

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

8113

Age (days ago)

8121

Last active (days ago)

List overview

Download

22 comments

7 participants

participants (7)

Ben Fennema
Carlo
Drew Parsons
Norbert Preining
Peter Osterlund
Petr Nejedly
Sergiy Kudryk