Most recent kernel where this bug did not occur: 2.6.16.1 (yes, the same version - it works with my dvd-burner, but not with my cd-burner), the 2.4 series worked with both, but there I have been using ide-scsi) Distribution: Mandriva 9.0 based Hardware Environment: cdrom: Cyberdrive CW058D - master on 2nd IDE dvd: Pioneer 106D slave on prim. IDE MB: elitegroup k7sem with sis chipset (SIS 5513) Software Environment: cdrtools 2.01.01a10 Problem Description: When trying to use cdrecord with the cdburner, the kernel hangs (not completely, only for cd-burning) and the system has to be rebooted. Even retrieving the atip-information of a disc fails. It fails only with the cd-recorder, not with the DVD-Burner. But when I tried with the cdrecorder, burning with the dvd-burner won't work either until the machine is rebooted. Steps to reproduce: I simply try to use "cdrecord dev=ATAPI:1,0,0 -atip" as root. # cdrecord dev=ATAPI:1,0,0 -atip Cdrecord-ProDVD-Clone 2.01.01a09 (i686-pc-linux-gnu) Copyright (C) 1995-2006 J�rg Schilling cdrecord: Warning: Running on Linux-2.6.16.1 cdrecord: There are unsettled issues with Linux-2.5 and newer. cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris. scsidev: 'ATAPI:1,0,0' devname: 'ATAPI' scsibus: 1 target: 0 lun: 0 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'. Device type : Removable CD-ROM Version : 0 Response Format: 1 Vendor_info : 'CyberDrv' Identifikation : 'CW058D CD-R/RW ' Revision : '160D' Device seems to be: Generic mmc CD-RW. 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 ----here it hangs and never returns--- If I run cdrecord with -V (i.e. scsi verbose), it reads: [...] Executing 'mode select g1' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 55 10 00 00 00 00 00 00 3C 00 cmd finished after 0.002s timeout 40s Executing 'get_configuration' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 46 02 00 37 00 00 00 00 10 00 cmd finished after 0.000s timeout 40s Executing 'read buffer' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 3C 00 00 00 00 00 00 00 04 00 cmd finished after 0.000s timeout 40s Executing 'read buffer' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 3C 00 00 00 00 00 00 FC 00 00 So the kernel doesn't timeout/return for some reason. You can find the full log here: http://muenchen-surf.de/lohmaier/cdrecord_atip_log If that information is not enough to handle the process, please tell me what else you need. Thank you.
additional information: My problem seems to be pretty much the same as in bug 3741 it is about hangs with a similar drive (same manufacturer, different model, namely a CW078D, mine is a CW058D) Alan Chandler tried to track this problem and found out that apparently the drives sends some additional interrrupts when queried (see bug 3741 comment 6 http://bugzilla.kernel.org/show_bug.cgi?id=3741#c6) bug 3741 also links to a debian bug http://bugs.debian.org/265747 where Garrett McLean tracked down the exact version of cdrecord that (in combination with newer kernels) exhibit the problem 2.01a32 it still works for him, versions 2.01a33 and newer exhibit the problem. I'll check with these versions whether I can confirm that the difference is between these two versions. Hopefully this will allow J
I could confirm that it is indeed the changes between version a32 and a33 that trigger that kernel bug.
some additional info regarding what has changed between the versions of cdrecord: J
I have a Cyberdrive CW038D that is also affected with respect to writing (haven't tried reading atip yet). J. Schilling's remark indicates that he's assuming that the info the drive advertises is in fact correct. The Cyberdrive drives have a reputation for being non-standards-compliant - for example, see https://launchpad.net/distros/ubuntu/+source/cdrtools/+bug/28210 so one thing I tried to possibly make mine less brain-dead was a firmware upgrade. The drive was manufactured 9/2005 with firmware version 120C. There is a version 124C available on the web (but not from Cyberdrive's site) but it refused to upgrade the drive. There are official firmware upgrades on Cyberdrive's site: ftp://www.cyberdrive.com.tw/Firmware/ so anyone with one of these might try the upgrade to see what happens. There is little hope of Cyberdrive fixing any problems now - note that the site is still affected by Y2K more than 6 years later, as it's displaying dates like "07/05/102"! If it turns out that the drive is providing false info, I hope J. Schilling will consider having cdrecord treat these as special cases.
I tried downgrading to the version of cdrecord that came with FC2 in May 2004, namely cdrecord-2.01-0.a27.3. This is the newest released version from Fedora that doesn't freeze when writing. I wrote a 100+ MB ISO consisting of a compressed tarball to a CD-RW. Although the write appeared to complete without errors, upon doing a toc of the tarball it turned out to be corrupted partway through. This is something I do often and have never had problems, so it's almost certainly due to a problem with cdrecord (or its interaction with a kernel bug). This means that the bug probably manifested earlier. It would be nice if someone who understands the problem better could write a small demo program that would trigger the freezing problem, without having to have one of these drives. The kernel bug would be a lot more likely to be fixed then.
ftp://ftp.berlios.de/pub/cdrecord/alpha/AN-2.01.01a23 contains: - Trying to implement a workaround for a Linux USB DMA size problem by implementing support for a new ioctl proposal from Alan Stern <stern@rowland.harvard.edu> UPDATE: It seems that the final fix in the Linux kernel will take some time and will be incompatible to the current patch. For this reason, I decided to make the intermediate patch available at: ftp://ftp.berlios.de/pub/cdrecord/alpha/Linux-USB-DMA-Size.patch ### I didn't try the patch yet, but maybe this could be a workaround that makes cdrecord (& the drive) work with current kernels again...
Is this still a problem with recent kernels?