cdrecord hangs with kernel >= 2.6.10 and cyberdrive cdrw

I suggested in the duplicate bug #16791 that whatever change was made in the last working build of cdrecord be undone as an Ubuntu patch - hopefully that way we can get cdrecord working for those of us with CyberDrive devices. (I also have a CW058D and am happy to test if necessary.) The current recommendation is "get new hardware" which is never an acceptable solution in my book.

  Instead of disabling the check explicitly, the code could (and should) be modified so it doesn't do the check unless it's needed - i.e., CDR_FORCESPEED is not set, -force is not specified, and burnfree is not specified on the command line. As a general rule, hardware shouldn't be relied on to do any more than absolutely necessary, precisely to avoid this kind of problem with nonstandard behavior.

Your problem is most likely caused by a well known linu xkernel bug
that has been accepted a long time ago that for that a 5 line patch
exists for a long time......

Check the net for the Linux USB DMA size bug.

If the kernel tells cdrecord that it is capable of doing big size DMA
but later hangs, cdrecord cannot do much.

As the Linux kernel folks seem to be unwilling to integrat the
5 line fix for the kernel, I added a ts= option to cdrtools long time
ago.

If cdrecord runs without problems in case you use

cdrecord ts=31k .....

you verified that your problem is caused by the Linux kerne.

BTW: Linux-2.6.8.1 introduced an incompatible kernel interface
change that prevents cdrecord from being able to work.

This has been done after the _stable_ relase cdrtools-2.01
has been released and for this readon, it took some time to
add a workaround into cdrtools. Please upgrade to a recent
original cdrtools

http://cdrecord.berlios.de/

if you are using a Linu-2.6 series kernel.

The bug report looks like it has been done against a cdrecord version from 2004.
No real cdrecord output has been attached, do it cannot be even called a confirmed bug.

Please test again with the new original cdrecord package from gutsy/multiverse

If the problem goes away, this was a problem that has been fixed in cdrecord..

If the problem goes away with cdrecord ts=30k, this is a Linux kernel bug as noted before.
If there is no report within some time from a recent cdrecord, I propose to close this bug

Hi,
I'm just bumping into the same problem : when I try to erase a CDRW with the latest cdrecord the machine freezes completely as soon as I need a file system access.
I tried the ts=30k then ts=1k with the same result : I've got to hit the reset button and all pending I/O has been lost (namely dmesg is useless). The I/O subsystem seams to be dead at this point.
My CD writer is an IDE one.
I "cdrecord -v -v -v | tee crdrecord.lst" to try to get at least some usefull informations.
Hope this can help (see attached file).
Let me know if I can do some more tests for you.

Guillaume

Linux Salsa 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux

Your log file does not even contain the start of the blanking command.
If you like to help, please run cdrecord -V blank=fast -v and
later cut/paste the past ~50 lines from ther terminal.

I would guess that your problem may be related to HALD. Could you kill
hald before running the test?

Le 11/01/2008 11:42, Schily écrivait :
> Your log file does not even contain the start of the blanking command.
> If you like to help, please run cdrecord -V blank=fast -v and
> later cut/paste the past ~50 lines from ther terminal.
>
I'd love to provide more lines ;-) The trouble is that I can't since the
machine freezes and is unable to write the file on disk. What I can do
is to take a picture via my camera ... Rather brutal method .
> I would guess that your problem may be related to HALD. Could you kill
> hald before running the test?
>
OK I'll try to do it.
Guillaume

Logging to a USB drive might work. Assuming you have one mounted at /media/disk, try this:
script -f /media/disk/log

As requested by Schily, I stopped the hald process

root@Salsa:~# /etc/init.d/hal stop
 * Stopping Hardware abstraction layer hald [ OK ]

and I did :
cdrecord dev=0,1,0 -V blank=fast -v | tee cdrecordNOhald.lst
(I copied the terminal output too)
then
cdrecord dev=0,1,0 -V blank=fast -v 2> cdrecordNOhaldStderr.lst

both files are in the attachment as a single file

In both cases the command finished successfully (after blocking the window manager for a while).
Everything went smooth afterwards. The disk is indeed erased.

Now what can we do about the hald service ? Doesn't look good to have to stop it to burn disks !
Many thanks for your input anyway.

I cannot help here as this is a HAL bug.

On Solaris, there is no such problem. For this reason, this is a Linux specific
HAL problem. Let me explain the differences between Solaris and Linux:

- On Solaris, it is not hald that tries to find the state changes on the drive/media
   but the sd driver in the kernel. It uses code from 1992 that is known to check only
   for the right state transitions.

- On Solaris, there are not many drivers in the kernel that are able to access the same
   piece of hardware.

I am trying to inform people about the background for the hald related problems since it
exists on Linux. You will only see a fix if the hald people fix their problems together with
the Linux kernel folks.

BTW: we should move this but to hald.....

Moving to hal as the problem has been verified to be caused
by the existence of hald.

Note: This is Linux specific hald bug as it does not happen on Solaris.

I have had the same problem. Pretty good reproducable. I was able to burn after installing original cdrtools and (!) killing hald before burning. No I found a workaround, that seems to be acceptable for me:I added in {{/etc/rc.local}} the line {{hal-disable-polling --device /dev/scd1}} (7dev(sd1 is my cd burner). I burned and deleted some cds and it worked perfectly.

Thank you to all of you who posted information here-very useful!

It took me all night searching the net to find how to get my Cyberdrive CW038D working under Debian.

All I had to do in the end was add "CDR_NODMATEST=true" (without quotes) to /etc/environment.
I also disabled autofs by putting a # in front of any lines related to the CD drive in /etc/auto.* ... but I'm not sure if that made any difference to fixing the problem.
I didn't have to kill /usr/sbin/hald to make it work.

I was then able to use K3b to burn the iso image successfully.

My system is as follows:
Debian GNU/Linux 4.0 "Etch"
Kernel version 2.6.18-6-686
Cyberdrive CW038D
K3b version 0.12.17 (Using KDE 3.5.5)
Wodim (Debian fork of cdrecord) version 1.1.2-1

I also found the following pages useful/informative:
http://lists.alioth.debian.org/pipermail/debburn-devel/2007-August/000449.html
http://www.mailarchives.org/list/debian-kernel/msg/2007/01749
http://www.mailarchives.org/list/debian-kernel/msg/2007/01777
http://lwn.net/Articles/198171/

Reportedly fixed with kernel >= 2.6.24, i. e. hardy and up. Please yell if you still have problems.

Can't blank recordable DVD+

Kubuntu 9.10 64bit
Linux version 2.6.28-12-generic (buildd@crested) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #43-Ubuntu SMP Fri May 1 19:31:32 UTC 2009

# cdrecord -v dev=/dev/sr0 -blank=fast
TOC Type: 1 = CD-ROM
scsidev: '/dev/sr0'
devname: '/dev/sr0'
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Wodim version: 1.1.9
SCSI buffer size: 64512
Device type : Removable CD-ROM
Version : 5
Response Format: 2
Capabilities :
Vendor_info : 'MATSHITA'
Identification : 'DVD-RAM UJ-852S '
Revision : '1.10'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Current: 0x001B (DVD+R)
Profile: 0x0012 (DVD-RAM)
Profile: 0x002B (DVD+R/DL)
Profile: 0x001B (DVD+R) (current)
Profile: 0x001A (DVD+RW)
Profile: 0x0015 (DVD-R/DL sequential recording)
Profile: 0x0013 (DVD-RW restricted overwrite)
Profile: 0x0014 (DVD-RW sequential recording)
Profile: 0x0011 (DVD-R sequential recording)
Profile: 0x0010 (DVD-ROM) (current)
Profile: 0x000A (CD-RW)
Profile: 0x0009 (CD-R)
Profile: 0x0008 (CD-ROM)
Profile: 0x0002 (Removable disk)
Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd).
Driver flags : SWABAUDIO BURNFREE
Supported modes: PACKET SAO
Drive buf size : 1572864 = 1536 KB
Beginning DMA speed test. Set CDR_NODMATEST environment variable if device
communication breaks or freezes immediately after that.
Current Secsize: 2048
HINT: use dvd+rw-mediainfo from dvd+rw-tools for information extraction.
Speed set to 11080 KB/s
Starting to write CD/DVD at speed 8.0 in real BLANK mode for single session.
Last chance to quit, starting real write in 0 seconds. Operation starts.
Performing OPC...
Blanking PMA, TOC, pregap
Errno: 5 (Input/output error), blank unit scsi sendcmd: no error
CDB: A1 01 00 00 00 00 00 00 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 04 00 00 00 30 05 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x30 Qual 0x05 (cannot write medium - incompatible format) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.002s timeout 9600s
wodim: Cannot blank disk, aborting.
wodim: Some drives do not support all blank types.
wodim: Try again with wodim blank=all.
#

# wodim blank=all
Device was not specified. Trying to find an appropriate drive...
Detected CD-R drive: /dev/cdrw
Using /dev/cdrom of unknown capabilities
Device type : Removabl...

Jan, it seems you have a different issue than what was originally reported here. Please open a new bug report. Thanks.