Description of problem: I get timeouts while burning CDR's with my NEC ND 1300a. Version-Release number of selected component (if applicable): cdrecord-2.01.1-9 invoked via k3b-0.11.23-3 How reproducible: It happens most of the time on my system, but there may be something particular to my other hardware that effects this. I don't have an easy way to test this drive model in other boxes. Steps to Reproduce: 1. Try to burn a CD-R using K3B 2. 3. Actual results: Looking at the debugging output will show that there was a timeout after the cue sheet was sent. Expected results: A successful burn. Additional info: This was also a problem under FC2 and FC3 and using cdroast instead of k3b. I don't burn a lot of disks. The couple of DVD RWs I have burnt worked normally. THe really odd part is that I can erase and burn CDRWs almost all of the time and doing so will normally change something so that I can burn CDRs for a while. I am not sure for how long, but normally I have had a reboot in between attempts to burn CDRs. I don't have the latest firmware revision on the drive. I had updated it to the latest version I could using DOS. But the latest version of NEC's flash tool required windows to work. The problem existed before I did anything with the firmware. The firmware upgrade was prompted by the this problem and did not seem to have any effect on it. I do seem to also be able to totally lock up the drive if I cancel the burn process without waiting for a timeout some of the time. Then I need to power cycle the machine. I am pretty sure the documentation warns about this though so it isn't really a bug. But maybe it is related to the timeout problem. I have this drive in a dual athlon box. There is also a DVD/CD ROM drive in the box. I can provide you with more information if you think something else will be helpful.
Since someone has made a linux flashing tool for NEC burners, I was able to upgrade my firmware and decided to retest this problem. I upgraded to a third party version of 1.0c (previously I was stuck at 1.0a since NEC's later upgrades required Windows 98). This didn't seem to change the problem, but I did collect a few more details. Once I can burn CDs, I don't seem to have problems again until I reboot (cold or warm). I was able to get a burn to work after several tries of just burning, so that doing an erase isn't a critical step. I have also started using cdrecord directly for some stuff (when k3b broke for a while I got a chance to learn it) and have some output from it that may suggest something. If you need anything else let me know. [bruno@bruno ~]$ cdrecord -blank=fast -dev=/dev/hdd; cdrecord -dev=/dev/hdd temp.raw Cdrecord-Clone 2.01-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling Note: This version is an unofficial (modified) version with DVD support Note: and therefore may have bugs that are not present in the original. Note: Please send bug reports or support requests to http://bugzilla.redhat.com/bugzilla Note: The author of cdrecord should not be bothered with problems in this version. cdrecord: Cannot allocate memory. WARNING: Cannot do mlockall(2). cdrecord: WARNING: This causes a high risk for buffer underruns. cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler cdrecord: Permission denied. WARNING: Cannot set priority using setpriority(). cdrecord: WARNING: This causes a high risk for buffer underruns. scsidev: '/dev/hdd' devname: '/dev/hdd' scsibus: -2 target: -2 lun: -2 Linux sg driver version: 3.5.27 Using libscg version 'schily-0.8'. cdrecord: Warning: using inofficial libscg transport code version (schily - Red Hat-scsi-linux-sg.c-1.83-RH '@(#)scsi-linux-sg.c 1.83 04/05/20 Copyright 1997 J. Schilling'). Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : '_NEC ' Identifikation : 'DVD_RW ND-1300A ' Revision : '1.0C' Device seems to be: Generic mmc2 DVD-R/DVD-RW. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96R RAW/R96R Speed set to 706 KB/s Starting to write CD/DVD at speed 4.0 in real BLANK mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. 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-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling Note: This version is an unofficial (modified) version with DVD support Note: and therefore may have bugs that are not present in the original. Note: Please send bug reports or support requests to http://bugzilla.redhat.com/bugzilla Note: The author of cdrecord should not be bothered with problems in this version. cdrecord: Cannot allocate memory. WARNING: Cannot do mlockall(2). cdrecord: WARNING: This causes a high risk for buffer underruns. cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler cdrecord: Permission denied. WARNING: Cannot set priority using setpriority(). cdrecord: WARNING: This causes a high risk for buffer underruns. scsidev: '/dev/hdd' devname: '/dev/hdd' scsibus: -2 target: -2 lun: -2 Linux sg driver version: 3.5.27 Using libscg version 'schily-0.8'. cdrecord: Warning: using inofficial libscg transport code version (schily - Red Hat-scsi-linux-sg.c-1.83-RH '@(#)scsi-linux-sg.c 1.83 04/05/20 Copyright 1997 J. Schilling'). Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : '_NEC ' Identifikation : 'DVD_RW ND-1300A ' Revision : '1.0C' Device seems to be: Generic mmc2 DVD-R/DVD-RW. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96R RAW/R96R cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler cdrecord: Permission denied. WARNING: Cannot set priority using setpriority(). cdrecord: WARNING: This causes a high risk for buffer underruns. Speed set to 706 KB/s Starting to write CD/DVD at speed 4.0 in real TAO mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. trackno=0 Turning BURN-Free off cdrecord: Success. write_g1: scsi sendcmd: no error CDB: 2A 00 00 00 00 00 00 00 1F 00 status: 0x4 (CONDITION MET/GOOD) resid: 63488 cmd finished after 40.241s timeout 40s write track data: error after 0 bytes cdrecord: A write error occured. cdrecord: Please properly read the error message above. cdrecord: Success. test unit ready: scsi sendcmd: no error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 02 00 00 00 00 0A 00 00 00 00 04 01 00 80 Sense Key: 0x2 Not Ready, Segment 0 Sense Code: 0x04 Qual 0x01 (logical unit is in process of becoming ready) Fru 0x0 Sense flags: Blk 0 (not valid) operation 0% done cmd finished after 0.000s timeout 40s cdrecord: Success. flush cache: scsi sendcmd: no error CDB: 35 00 00 00 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 02 00 00 00 00 0A 00 00 00 00 04 01 00 80 Sense Key: 0x2 Not Ready, Segment 0 Sense Code: 0x04 Qual 0x01 (logical unit is in process of becoming ready) Fru 0x0 Sense flags: Blk 0 (not valid) operation 0% done cmd finished after 0.000s timeout 120s Trouble flushing the cache cdrecord: Cannot fixate disk.
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
It's still does this. I am 100% sure about FC5. I think I also had this happen in FC6 while I was doing some testing (I am still using FC5, but did some test installs in some scratch partitions). The drive burns DVDs and erases CD-RWs no problem. It won't burn CD RWs or CDRs after a reboot, but if I erase some CD RWs it will usually start working and then continue to work until the next reboot. I think burning a DVD has a chance to fix things as well, but I am not 100% of my memory on this one. It would be really nice if you could fix this, but it probably needs to be done upstream, but I doubt Schilling will even take a bug report from a Fedora system.
Dang, I forgot to clear needs info. While I was at it, I changed it to FC5, since that is the latest version I am 100% sure of the problem in.
The damage this causes in the latest fc5 kernel (I am not sure when this started as I don't burn a lot of CDs at home, mostly DVDs now.) has changed. Now something starts using up lots of memory and the oom killer starts up despite my memory setting of 2 and 50%. Once k3b knows about the cdrecord replacement in F7 I'll be retesting this problem there.
I am still having problems with the cdrkit based tools used by k3b in F7. Now the timeout is longer than it was previously. I don't know how much longer as I have killed off k3b after about 10 minutes or so. This seems to leave the drive locked and requires a reboot to fix. So I haven't tried burning many CDRWs so far. Burning DVDs and erasing CDRWs seems to work fine just as when using the FC5 tools. I tried to report the problem upstream (to the debian-burn list), but my email message to the list wasn't acknowleged (even to say they can't fix it without hardware to test on), so I am not expecting much help there.
I am pretty sure it had the same problem on Fedora 8. I currently am running rawhide on the box, but k3b hasn't been working too well anywhere. So testing it right now might not be that helpful. When things stabilize a bit, I'll see if the problem is still happening in Fedora 9.
I restested it using k3b in rawhide and it is still having problems with cd-rws. Reading cd-rws and erasing cd-rws works, but writing them doesn't. The failed attempts at writing can mess the device up so that it no longer reads cd-rws, but will still read dvd-rws. Rebooting seems to clear this state up. k3b seems to be providing less information than in the past (at least by default). When I tried to burn a small iso image the device light wen on and then off around the time the "Starting SAO writing at x4 speed..." message was displayed. It was off before the "Sending cue sheet" message and it took a couple of minutes to get passed that (which should only pause for a couple of seconds). Then it moved on to the "Starting disc write" message. The access light on the drive was not on for this step, when it should be. Eventually that step times out as well.
Some more info. At the end after the disc write times out, then there is a message from k3b about not having permission to open the device. Also I am not having the memory problems that I was at one point when there were problems.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Created attachment 317872 [details] Output from k3b using wodim. I am going to attach some debugging out obtained running k3b using using wodim to earse and then fail burning a cdrw. The first test case was run as a normal user the rest as root. I also tried disabling burnfree for the later tests. After failing to burn the cdrw I needed to reboot to get the drive to see the media again.
Since k3b is using wodim now, I am moving the component over to cdrkit.
I am using wodim-1.1.8-1.fc10.i386 and k3b-1.0.5-5.fc10.i386.
Created attachment 317873 [details] More k3b/wodim debugging output
Created attachment 317874 [details] More k3b/wodim debugging output
Created attachment 317875 [details] More k3b/wodim debugging output
This bug has been triaged
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I recommend you to upgrade to a recent original version of the software. The version used for the report is extremely old, modified by a third party and known to be buggy. Upgrade to recent original software from: ftp://ftp.berlios.de/pub/cdrecord/alpha/
Jörg, it doesn't help pointing to your CDDL licensed software. The mixed GPL/CDDL licensed tarball still does not work for Fedora.
It is helpful. I have been considering testing his software on the device to see whether or not it works. If it does, then that points to a problem in wodim and the version of cdrecord in Fedora. If not, it suggests that maybe something in the burner has failed.
Harald, the software currently distributed by RedHat is in conflict with GPL and Copyright. You cannot legaly distribute it. Cdrecord is 100% CDDL and the complete cdrtools package has been thoroughly checked by the Sun legal department in Autumn 2008. Sun could not find any legal problem and Sun is distributing recent original software. It seems that if you like to stay legal, you only have the choice o use the orignal software.
I noticed that 2.6.27 has per device scsi command filtering. (Though I haven't found documentation on how to change it other than you are supposed to use sysfs.) This could make testing if the problem with the drive is due to blacklisting of a needed scsi command easier. I never got any answer to my question asking for help on how to do this testing (sent to one of the Fedora lists quite a while back).
I am still seeing this. It looks like k3b is now using wodim, but I am having similar problems. I can burn DVD-RWs, but not CD-RWs. wodim-1.1.9-4.fc11.i586 k3b-1.0.5-8.fc11.i586
Older k3b versions use browisofs for writing DVDs. Note that k3b uses wodim only as a last resort as wodim is known to be buggy. I recommend you to compile a recent cdrtools version from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ http://cdrecord.berlios.de/ and make sure that cdrecord is installed suid root. k3b first looks in /opt/schily/bin for recent original software.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
It was still doing this during the F12 run up. I haven't tested it since going to rawhide/F13.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.