Vladimir Nadvornik 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:

https://bugzilla.novell.com/show_bug.cgi?id=226019#c9

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:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413960

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 -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On čt 6. srpna 2009, Joerg Schilling wrote:

Vladimir Nadvornik 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:

https://bugzilla.novell.com/show_bug.cgi?id=226019#c9

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org