Bug 203248 - cdrecord hangs on write with Cyberdrive CD-RW drive
cdrecord hangs on write with Cyberdrive CD-RW drive
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-19 15:25 EDT by Andre Robatino
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-23 13:04:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andre Robatino 2006-08-19 15:25:21 EDT
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
Comment 1 Andre Robatino 2006-08-20 10:35:21 EDT
  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).
Comment 2 Andre Robatino 2006-08-20 13:55:12 EDT
  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.
Comment 3 Andre Robatino 2006-08-21 10:50:20 EDT
  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.
Comment 4 Andre Robatino 2006-09-18 00:52:46 EDT
  I changed the title since based on bug reports elsewhere, this also affects
the CW058D, CW078D, and CW088D - everything Cyberdrive makes, basically.
Comment 5 Andre Robatino 2006-09-29 12:47:54 EDT
  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.
Comment 6 Dave Jones 2006-10-16 17:44:58 EDT
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.
Comment 7 Andre Robatino 2006-11-05 13:01:14 EST
  Bug still exists in FC6 with kernel-2.6.18-1.2798.fc6 and cdrecord-2.01-10.
Comment 8 Andre Robatino 2007-07-21 03:32:59 EDT
  Unfortunately, this drive is not installed in either of my two boxes anymore,
so I can no longer test for the bug.

Note You need to log in before you can comment on or make changes to this bug.