I have just verified that bug 226019 is still a problem. With cdrecord from home:/hennichodernich/ on 11.1 I am not able to burn a cd, unless I kill hald-addon-storage. I could reproduce it with all LG devices that I tested. This particular device was 'DVDRAM GSA-U10N '.
This bug is a Linux kernel bug - it needs to be fixed in the Linux kernel. Cdrecord powerless if the Linux kernel reports wrong DMA sizes.
If killing hald helps, then this is a really obscure side effect.
BTW cdrecord does not try to do more than 62 KB of DMA by default. If you have one of the problematic USB chips that use a driver that does not allow to do more than 32 kB DMA, you always may specify ts=32k with cdrecord, cdda2wav or readcd.
Also, cdrecord from that package is installed with suid root. I am quite sure that our security team won't like it.
The solutuion used by cdrecord is no security problem as cdrecord is carefully audited. There are other security problems on suse that result from the fact that the security issue that allowed non-root applications to send SCSI commands have not beed fixed correctly.
Jörg
On Friday 31 July 2009 22:48:58 Joerg Schilling wrote:
I have just verified that bug 226019 is still a problem. With cdrecord from home:/hennichodernich/ on 11.1 I am not able to burn a cd, unless I kill hald-addon-storage. I could reproduce it with all LG devices that I tested. This particular device was 'DVDRAM GSA-U10N '.
This bug is a Linux kernel bug - it needs to be fixed in the Linux kernel. Cdrecord powerless if the Linux kernel reports wrong DMA sizes.
If killing hald helps, then this is a really obscure side effect.
BTW cdrecord does not try to do more than 62 KB of DMA by default. If you have one of the problematic USB chips that use a driver that does not allow to do more than 32 kB DMA, you always may specify ts=32k with cdrecord, cdda2wav or readcd.
The first comment is misleading. You apparently did not read the rest. The real problem is described here:
https://bugzilla.novell.com/show_bug.cgi?id=226019#c9
or in debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413960
Vladimir
Vladimir Nadvornik nadvornik@suse.cz wrote:
BTW cdrecord does not try to do more than 62 KB of DMA by default. If you have one of the problematic USB chips that use a driver that does not allow to do more than 32 kB DMA, you always may specify ts=32k with cdrecord, cdda2wav or readcd.
The first comment is misleading. You apparently did not read the rest. The real problem is described here:
These are two independend bugs:
- One bug is in the Linux kernel in the USB driver. As the USB driver behaves incorrectly for setting up the DMA size, cdrecord may fail because it was given incorrect data from the kernel. This problem is definitely independen from whether hald runs or not.
- Hald on Linux is broken. Hald on Solaris works correctly as it is based on the state engine in the sd driver from the Solaris kernel. This sd driver knows how to correctly evaluate state transitions since 1992.
Hald on Linux incorrectly believes that a not-ready to ready state transition needs to be taken into account. As a result, hald may try to mount a CD that was not yet fully written.
Hald on Linux needs to be fixed in order to bix the hald related problems.
BTW: wodim and the other programs from cdrkit miss-use the device interface and thus cannot deal with non-empty media correctly.
or in debian bug:
This is a problem caused my the hald implementation bug that is Linux specific (see above). This bug is neither related to the USB driver bus nor to https://bugzilla.novell.com/show_bug.cgi?id=226019#c9
Jörg
Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) wrote:
or in debian bug:
This is a problem caused my the hald implementation bug that is Linux specific (see above). This bug is neither related to the USB driver bus nor to https://bugzilla.novell.com/show_bug.cgi?id=226019#c9
Errata:
This is a problem caused by the hald implementation bug that is Linux specific (see above). This bug is neither related to the USB driver bug nor to https://bugzilla.novell.com/show_bug.cgi?id=226019#c9
Jörg
On čt 6. srpna 2009, Joerg Schilling wrote:
Vladimir Nadvornik nadvornik@suse.cz wrote:
BTW cdrecord does not try to do more than 62 KB of DMA by default. If you have one of the problematic USB chips that use a driver that does not allow to do more than 32 kB DMA, you always may specify ts=32k with cdrecord, cdda2wav or readcd.
The first comment is misleading. You apparently did not read the rest. The real problem is described here:
These are two independend bugs:
One bug is in the Linux kernel in the USB driver. As the USB driver behaves incorrectly for setting up the DMA size, cdrecord may fail because it was given incorrect data from the kernel. This problem is definitely independen from whether hald runs or not.
Hald on Linux is broken. Hald on Solaris works correctly as it is based on the state engine in the sd driver from the Solaris kernel. This sd driver knows how to correctly evaluate state transitions since 1992.
Hald on Linux incorrectly believes that a not-ready to ready state transition needs to be taken into account. As a result, hald may try to mount a CD that was not yet fully written.
Hald on Linux needs to be fixed in order to bix the hald related problems.
IMHO it is more generic problem. It can be reproduced without hal. Simple running "cdrecord -toc" from another terminal breaks the burning on any LG burner that I tested. Wodim works fine.
Vladimir
Vladimir Nadvornik nadvornik@suse.cz wrote:
IMHO it is more generic problem. It can be reproduced without hal. Simple running "cdrecord -toc" from another terminal breaks the burning on any LG burner that I tested. Wodim works fine.
Wodim does not work fine. It _may_ (although I am not conviced) in this specific case give less problems than cdrecord. If this is true, this is only a side effect of a wodim bug.
wodim cannot deal with non-empty media, cdrecord can.
Jörg
-
Joerg.Schilling＠fokus.fraunhofer.de -
Vladimir Nadvornik