Bug 6745

Summary: kernel hangs when trying to read atip wiith cdrecord
Product: IO/Storage Reporter: Christian Lohmaier (lohmaier)
Component: IDEAssignee: io_ide (io_ide)
Status: REJECTED INSUFFICIENT_DATA    
Severity: normal CC: esigra
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.16.1 Subsystem:
Regression: --- Bisected commit-id:

Description Christian Lohmaier 2006-06-24 13:35:20 UTC
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.
Comment 1 Christian Lohmaier 2006-06-26 06:17:58 UTC
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
Comment 2 Christian Lohmaier 2006-06-26 06:35:25 UTC
I could confirm that it is indeed the changes between version a32 and a33 that
trigger that kernel bug.
Comment 3 Christian Lohmaier 2006-07-02 07:13:07 UTC
some additional info regarding what has changed between the versions of cdrecord:

J
Comment 4 Andre Robatino 2006-08-21 12:57:49 UTC
  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.
Comment 5 Andre Robatino 2006-08-29 18:00:55 UTC
  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.
Comment 6 Christian Lohmaier 2007-07-10 07:25:19 UTC
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...
Comment 7 Bartlomiej Zolnierkiewicz 2008-02-16 10:47:27 UTC
Is this still a problem with recent kernels?