Red Hat Bugzilla – Bug 203248
cdrecord hangs on write with Cyberdrive CD-RW drive
Last modified: 2007-11-30 17:11:40 EST
Description of problem: When attempting to burn with the drive, it just hangs: [root@localhost tmp]# cdrecord -v blank=fast dev=ATAPI:1,0,0 home.iso cdrecord: No write mode specified. cdrecord: Asuming -tao mode. cdrecord: Future versions of cdrecord may have different drive dependent defaults. cdrecord: Continuing in 5 seconds... Cdrecord-Clone 2.01.01a03-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2005 Jörg Schilling NOTE: This version contains the OSS DVD extensions for cdrtools and thus may have bugs related to DVD issues that are not present in the original cdrtools. Please send bug reports or support requests to http://bugzilla.redhat.com/bugzilla The original cdrtools author should not be bothered with problems in this version. TOC Type: 1 = CD-ROM scsidev: 'ATAPI:1,0,0' devname: 'ATAPI' scsibus: 1 target: 0 lun: 0 Use of ATA is preferred over ATAPI. Warning: Using ATA Packet interface. Warning: The related Linux kernel interface code seems to be unmaintained. Warning: There is absolutely NO DMA, operations thus are slow. Using libscg version 'schily-0.8'. SCSI buffer size: 64512 atapi: 1 Device type : Removable CD-ROM Version : 0 Response Format: 1 Vendor_info : 'CyberDrv' Identifikation : 'CW038D CD-R/RW ' Revision : '120C' Device seems to be: Generic mmc CD-RW. Current: 0x0002 Profile: 0x000A Profile: 0x0009 Profile: 0x0008 Profile: 0x0002 (current) Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-2 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R Drive buf size : 1806336 = 1764 KB (hangs here) The same error happens if I use dev=/dev/cdrom. In /var/log/messages I get messages like the following: Aug 17 07:46:12 localhost kernel: hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest } Aug 17 07:46:12 localhost kernel: ide: failed opcode was: unknown Aug 17 07:46:12 localhost kernel: hdc: drive not ready for command Aug 17 07:46:12 localhost kernel: hdc: status timeout: status=0xd0 { Busy } Aug 17 07:46:12 localhost kernel: ide: failed opcode was: unknown Aug 17 07:46:12 localhost kernel: hdc: DMA disabled Aug 17 07:46:12 localhost kernel: hdc: drive not ready for command Aug 17 07:46:12 localhost kernel: hdc: ATAPI reset complete Aug 17 07:46:12 localhost kernel: hdc: request sense failure: status=0x51 { DriveReady SeekComplete Error } Aug 17 07:46:12 localhost kernel: hdc: request sense failure: error=0x50 { LastFailedSense=0x05 } Aug 17 07:46:12 localhost kernel: hdc: request sense failure: status=0x51 { DriveReady SeekComplete Error } Aug 17 07:46:12 localhost kernel: hdc: request sense failure: error=0x50 { LastFailedSense=0x05 } Some googling shows that this problem has been around for a while: http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=265747 (in which J. Schilling claims that this is a kernel bug) http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137049 http://www.reactivated.net/weblog/archives/2005/04/the-definitive-guide-to-cd-writing-on-recent-26-kernels/ If this is indeed a kernel bug, I'll reassign it. When attempting to read a tarfile using star ztvf on a CD burned without padding, I get the following error at the end: 785539 -rw-rw-r-- andre/andre Mar 10 13:17 2004 andre/nowyouseeit.pdf star: Tar file too small (amount: 0 bytes). star: Unexpected EOF on input. star: Cannot recover from error - exiting. star: 16086 blocks + 4096 bytes (total of 164724736 bytes = 160864.00k). [andre@localhost ~]$ However, if I use padding, the error goes away. It looks like what happens is that it completes the read successfully and then misinterprets an exit code or something. In any case, it's not a big deal; the main problem is with writing. Version-Release number of selected component (if applicable): cdrecord-2.01.01.0.a03-3 (and all other current FC5 updates) How reproducible: always
It's been reported elsewhere that cdrdao works with these drives, even though cdrecord doesn't. I tried it and found that though cdrdao can successfully write a blanked CD-RW with this drive, it can't blank a nonblank CD-RW (it returns without error, but upon checking the CD is not blanked after all). This suggests that the bug(s) causing cdrecord to fail now at least partially affect cdrdao. The drive is clearly physically capable of burning. These drives are currently being sold for $17.99 with free shipping at pcdirect.com. Too bad they don't work properly (in Linux at least).
I tested cdrecord to see if the problem was limited to blanking, by taking a blanked CD and running cdrecord without blank=fast. Same result as before - it hangs. So cdrecord is totally nonfunctional, cdrdao is partially functional. Also, while cdrdao simply returns a false success on attempting a fast blank, trying a full blank causes a hang, though Ctrl-C eventually gets the prompt back. There seem to be no system log errors with cdrdao.
A similar bug was filed at bugzilla.kernel.org: http://bugzilla.kernel.org/show_bug.cgi?id=6745 The following is quoted from the last comment: Jörg Schilling wrote in <44A22FC3.nail3NU1XXW6C@burner> "The only new thing with cdrecord-2.01a33 is that it started to transfer more than 4 bytes with the "read buffer" command. As this is only issued in case that the "read buffer" command did succeed with 4 bytes transfer count and as cdrecord does not transfer more than the drive advertizes, I am just depending on a kernel that does not freeze from the SCSI command I am issuing." Hence I'm changing this to a kernel bug.
I changed the title since based on bug reports elsewhere, this also affects the CW058D, CW078D, and CW088D - everything Cyberdrive makes, basically.
Disregard what I said about cdrdao being only partly functional. Being unfamiliar with cdrdao, I was doing something wrong. When used properly, it works perfectly with this drive. The only problem is that the current FC5 version can't write as root - see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191684 but the current upstream version and current FC6 test versions don't have this problem, so it's some kind of FC5-specific build error, and in any case is not specific to this drive. To sum up, the drive can burn fine, but only using cdrdao. In https://launchpad.net/distros/ubuntu/+source/cdrtools/+bug/28210 it's suggested that the problem with this drive and cdrecord is that the drive sends spurious interrupts when polling DMA speed. Since the polling isn't necessary unless one is NOT using burnfree, CDR_FORCESPEED is NOT set, and -force is NOT specified, I suggested the simple workaround of checking in advance whether the result of the polling will be used, and not doing it unless it will. I haven't looked at the source and don't know if this explanation is true or how easy my workaround would be. It would probably be just a few lines of code. In any case, it's bad practice for cdrecord to make unnecessary system calls, since they're expensive. Also, I think burnfree should be the default for cdrecord anyway. This doesn't address the question of whether there is a kernel bug or not. Rumor has it that Mr. Schilling won't be the maintainer of cdrecord anymore; maybe his replacement can get along better with the kernel people and this can be resolved.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
Bug still exists in FC6 with kernel-2.6.18-1.2798.fc6 and cdrecord-2.01-10.
Unfortunately, this drive is not installed in either of my two boxes anymore, so I can no longer test for the bug.