On Tue, 13 Jan 2004, Doug Holland wrote:

...

I'm running on an 650MHz Athlon, and the CD-RW drive in question is a generically rebranded Lite-On Combo LTC-48161H (16x DVD/48x read/48x CD-R/24x CD-RW combo drive.)

I just compiled kernel 2.6.0, with the packet-writing patch (packet-2.6.1-rc1-2.patch.bz2) on a Debian unstable system. I followed the instructions in the hint file (http://cvs.linuxfromscratch.org/index.cgi/hints/Attic/cdrw-hint.txt?rev=1.3) to get it working, and it's working to an extent.

The problem is that when I copy medium-large sized files (a few megabytes, such as an mp3,) the drive just keeps running & running, with the LED lit in amber (meaning it's writing). Running sync to get the drive to finish the job doesn't seem to do anything, and if I umount and remount the CD-RW, some of the files I tried to copy to it are missing.

When I run dmesg, I get thousands of these error messages.

ide-cd: write_intr decode_status bad hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 end_request: I/O error, dev hdc, sector 5736 ide-cd: write_intr decode_status bad hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 end_request: I/O error, dev hdc, sector 5744 ide-cd: write_intr decode_status bad hdc: command error: status=0x51 { DriveReady SeekComplete Error } hdc: command error: error=0x54 ... Does anybody here have any ideas on how to get rid of these errors?

I don't know yet, but I have the same problem on one of my IDE drives (Sony CRX175A). I only have a problem when using native ide support in a 2.6 kernel. In 2.4 the drive works with both native ide and scsi emulation, and it also works with scsi emulation in 2.6.

I have another IDE drive (HP 8100) on the same ide channel which works perfectly with native ide in 2.6, so it can't be that packet writing using native ide is completely broken in 2.6.

It looks like I/O requests sent from the packet driver to the ide driver get shifted 4 sectors. In the log file below, the requested sectors (the numbers within parenthesis on the pkt_gather_data lines) exactly match the reported read sectors (in pkt_end_io_read), except for the 4 sector offset.

I also get an "access beyond end of device" if I try to access the last sector on the disc, so it seems like the offset is added before the actual I/O operation starts.

run_state_machine: pkt 5 pkt_gather_data: Adding frame 0 (120500), page:c1098f80 offs:0 pkt_gather_data: Adding frame 1 (120504), page:c1098f80 offs:2048 pkt_gather_data: Adding frame 2 (120508), page:c10940c0 offs:0 pkt_gather_data: Adding frame 3 (12050c), page:c10940c0 offs:2048 pkt_gather_data: Adding frame 4 (120510), page:c1095498 offs:0 pkt_gather_data: Adding frame 5 (120514), page:c1095498 offs:2048 pkt_gather_data: Adding frame 6 (120518), page:c10933c8 offs:0 pkt_gather_data: Adding frame 7 (12051c), page:c10933c8 offs:2048 pkt_gather_data: Adding frame 8 (120520), page:c1095b28 offs:0 pkt_gather_data: Adding frame 9 (120524), page:c1095b28 offs:2048 pkt_gather_data: Adding frame 10 (120528), page:c1095b00 offs:0 pkt_gather_data: Adding frame 11 (12052c), page:c1095b00 offs:2048 pkt_gather_data: Adding frame 12 (120530), page:c1093148 offs:0 pkt_gather_data: Adding frame 13 (120534), page:c1093148 offs:2048 pkt_gather_data: Adding frame 20 (120550), page:c10941d8 offs:0 pkt_gather_data: Adding frame 21 (120554), page:c10941d8 offs:2048 pkt_gather_data: Adding frame 22 (120558), page:c10941b0 offs:0 pkt_gather_data: Adding frame 23 (12055c), page:c10941b0 offs:2048 pkt_gather_data: Adding frame 24 (120560), page:c108e328 offs:0 pkt_gather_data: Adding frame 25 (120564), page:c108e328 offs:2048 pkt_gather_data: Adding frame 26 (120568), page:c108e300 offs:0 pkt_gather_data: Adding frame 27 (12056c), page:c108e300 offs:2048 pkt_gather_data: Adding frame 28 (120570), page:c10958a8 offs:0 pkt_gather_data: Adding frame 29 (120574), page:c10958a8 offs:2048 pkt_gather_data: Adding frame 31 (12057c), page:c1095880 offs:2048 pkt_gather_data: need 25 frames for zone 120500 pkt 5 : s=120500 WAITING -> READ_WAIT ... pkt_gather_data: Adding frame 31 (7c), page:c10929c8 offs:2048 pkt_gather_data: need 29 frames for zone 0 pkt 1 : s= 0 WAITING -> READ_WAIT pkt_end_io_read: bio=c3acd908 sec0=120500 sec=120580 err=-5 kcdrwd: i:0 ow:0 rw:5 ww:0 rec:0 fin:0 kcdrwd: sleeping pkt_end_io_read: bio=c3acdc4c sec0=120500 sec=120554 err=0 pkt_end_io_read: bio=c3acdc00 sec0=120500 sec=120558 err=0 pkt_end_io_read: bio=c3acdbb4 sec0=120500 sec=12055c err=0 pkt_end_io_read: bio=c3acd234 sec0=120500 sec=120560 err=0 pkt_end_io_read: bio=c3acdb1c sec0=120500 sec=120564 err=0 pkt_end_io_read: bio=c3acdad0 sec0=120500 sec=120568 err=0 pkt_end_io_read: bio=c3acda84 sec0=120500 sec=12056c err=0 pkt_end_io_read: bio=c3acdf90 sec0=120500 sec=120570 err=0 pkt_end_io_read: bio=c3acdf44 sec0=120500 sec=120574 err=0 pkt_end_io_read: bio=c3acd9a0 sec0=120500 sec=120578 err=0 pkt_end_io_read: bio=c3acd4e0 sec0=120500 sec=120504 err=0 pkt_end_io_read: bio=c3acd494 sec0=120500 sec=120508 err=0 pkt_end_io_read: bio=c3acd448 sec0=120500 sec=12050c err=0 pkt_end_io_read: bio=c3acd3fc sec0=120500 sec=120510 err=0 pkt_end_io_read: bio=c3acd3b0 sec0=120500 sec=120514 err=0 pkt_end_io_read: bio=c3acd364 sec0=120500 sec=120518 err=0 pkt_end_io_read: bio=c3acd318 sec0=120500 sec=12051c err=0 pkt_end_io_read: bio=c3a9778c sec0=120500 sec=120520 err=0 pkt_end_io_read: bio=c3a97150 sec0=120500 sec=120524 err=0 pkt_end_io_read: bio=c3a97104 sec0=120500 sec=120528 err=0 pkt_end_io_read: bio=c3a97a38 sec0=120500 sec=12052c err=0 pkt_end_io_read: bio=c3a979ec sec0=120500 sec=120530 err=0 pkt_end_io_read: bio=c3a979a0 sec0=120500 sec=120534 err=0 pkt_end_io_read: bio=c3acde60 sec0=120500 sec=120538 err=0 kcdrwd: wake up handle_queue

I noticed the attached (packet.txt.gz - 1832 bytes) with one of my CDs under 2.6.0 with UDF CVS: I don't know what I did from 17:36:48 to 17:37:23, but it isn't much time to write or remove any files... I guess I didn't do anything or just had the time to enter /mnt/udf or subdirectories. Then I ran udf_test: Error count: 5 total occurrences: 8 Warning count: 3 total occurrences: 4 PS: I attached it because the list rejected (message > 30000 bytes). -- http://www.pervalidus.net/contact.html