Bugzilla – Bug 226019
[k3b] CD burning via /dev/sg does not work with some burners
Last modified: 2010-01-05 15:36:58 UTC
wodim (and cdrecord) fail to burn on external USB burner via /dev/sg0 The problem is following: - wodim reads the bufer size with SG_GET_RESERVED_SIZE, it returns 32K - wodim tries to set the buffer size to 128K via SG_SET_RESERVED_SIZE. - following SG_GET_RESERVED_SIZE returns 128K - the scsi commands that needs 128K buffer (write_g1) fails with ENOMEM, it seems that the real buffer size is still 32K This seems to be the same problem: http://marc.theaimsgroup.com/?l=linux-kernel&m=116233257826906&w=2 Burning via /dev/sr0 on the same device works without problems, SG_GET_RESERVED_SIZE returns 32K even after the try to set it to 128K. Using /dev/sr0 is probably not the correct fix, because wodim and k3b uses /dev/sg0 by default.
Created attachment 108313 [details] hwinfo --all
/dev/sg seems to be broken even more. Option ts=32k can be used as a workaround for the original problem, however it fails later. See the attached logs. The only difference is the used device, /dev/sg0 vs. /dev/sr0.
Created attachment 108484 [details] log_fail
Created attachment 108485 [details] log_ok
Created attachment 108486 [details] diff of the logs
The problem in comment #2 is caused by hal check for changed media. I am not sure if it is a generic problem or just a bug in LG firmware. Anyway, when I kill the hal process that monitors the device, burning starts to work. Both hal and wodim uses O_EXCL lock, but it does not help because the lock is not shared between sg and sr. IMHO the clean fix is to make the lock shared. Is it possible? Bug 223165 is probably related.
I wouldn't know. Reassigning to the HAL folks.
/dev/sg0 and /dev/sr0 is the same device accessed via different kernel drivers, if I understand it correctly. Therefore if wodim opens /dev/sg0 with O_EXCL, it does not prevent HAL access the device via /dev/sr0. The checks in HAL interrupts the recording process, at least with LG recorders. If wodim is called with /dev/sr0, it stops HAL query the device and everything works OK. However k3b calls wodim with dev=0,0,0 which is translated to /dev/sg0. possible fixes: 1) make the O_EXCL shared between the devices in kernel (IMHO correct fix) 2) open both devices with O_EXCL in HAL before running the checks (IMHO the easiest fix) 3) use /dev/sr0 instead of dev=0,0,0 in k3b (partial fix) 4) translate dev=0,0,0 to /dev/sr0 in wodim (ugly hack)
Hm, care to show what you mean by the fix 1) above? Why isn't this an issue with the upstream kernel.org releases?
IMO case 2 (fix in HAL) is not the best idea, because HAL does not care about the second device. IMO this would be only a workaround. I reassign this to the kernel guys. The first proposal in the list would be IMO the better solution.
Greg: I have no idea how to fix it in kernel, but the current kernel behavior is quite surprising and requires special hacks in userspace. Upstream kernel has the same problem. However it appears only in combination with HAL and LG drives.
Uhm, you're supposed to use /dev/sr0 if you want to access it as a SCSI CD/DVD drive, not /dev/sg0. The semantics are different, and they are different devices! Note that /dev/sg0 refers to the first generic SCSI device; which might as well be the first physical disk /dev/sda or another SCSI device. And if you're accessing /dev/sr0 or /dev/sda, you're not supposed to access the corresponding generic device. This isn't a kernel bug, but seems to be a mistake in how hal handles things. Reassigning to hal maintainer. And yes, k3b should use /dev/sr0 and not /dev/sg0.
but as you can read in comment #9 HAL open as you suppose, if I understand correct, /dev/sr0. So this looks like a problem in k3b and not HAL. Because of this it looks to me like a problem in k3b ... reassing to KDE.
I wonder how k3b got in the play. Vladimir - is this limited to k3b?
My k3b uses /dev/sr0 btw - but that is for my internal DVD-RW
k3b on 10.2 calls wodim (via cdrecord symlink) with dev=0,0,0 by default. wodim maps it to /dev/sg0. I agree /dev/sr0 should be used everywhere. However, specifying device with dev=0,0,0 which is mapped to /dev/sg0 is the way how cdrecord always worked and it probably won't be easy to drop it from all scripts and frontends, especially when the original cdrecord from Joerg Schilling prints a warning about using the device directly. IMHO we should make /dev/sg0 work too, for compatibility.
that is also what is returned from cdrecord -scanbus, no? And it's also what is in all my personal cdrecord scripts. So either wodim needs to fix this or the kernel
Sorry, if you want the device to be accessed like a CD drive, you must use /dev/sr0. And accessing the SCSI generic device concurrently with the block device as well is a user-space error. This simply isn't a kernel bug.
cdrecord -scanbus and dev=X,X,X is supposed to work with SCSI generic, there is nothing to fix. The only way to change it is to call wodim(cdrecord) with dev=/dev/sr0. Lars, do you mean that kernel does not support CD burning via /dev/sg ? Since when?
Well, /dev/sg will mostly work as well. The keypoint is that user-space must not access the sg and the sd/sr device concurrently, as it appears to be doing here.
OK, so my proposal is: 1. use dev=/dev/sr in k3b (and other frontends and scripts) as a correct long-term solution. 2. open both devices with O_EXCL in HAL - for compatibility with unfixed 3rd-party frontends and scripts, it can be also released as an update for 10.2. Reasons why it should be fixed in HAL: - users don't expect that HAL accesses the device, it's hard to debug the failures - in theory it could break other programs too, for example firmware updaters
I don't see why HAL should open both devices. HAL only know about sr0 and only touch this device file. How should HAL know that it maybe should open any sgX and sgX device with O_EXCL. If this is really needed the kernel should share the O_EXCL between the both device files if one get locked. The point is: this can also happen if there is no HAL if two application/programms open the both devices independently. And if the user expect that HAL provide hardwareinformation and if a media get inserted or the eject button get pressed the user can also expect that HAL need to access the device for this.
*** Bug 223165 has been marked as a duplicate of this bug. ***
*** Bug 208995 has been marked as a duplicate of this bug. ***
It could become much more serious with libata for IDE in 10.3, increasing severity.
for 10.3 this should not be an issue at all as the bug is already fixed for 10.3.
K3b 1.0 uses the block device instead the generic device on kernel >= 2.6. Thus, this problem should not occur anymore. The reason, Joerg Schilling recommends using the generic devices is probably his preference of the Solaris system. He still claims it is a linux kernel bug and that both variants should work equally. I personally lack the deep kernel knowledge to comment on this and am happy that the block device works properly.
The same bug in debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413960
Since 1.1.4 wodim maps dev=X,X,X to /dev/sr where possible.
Note that O_EXCL is absolutely no solution as it would prevent the usability of cdrtools. If you use O_EXCL and if the Linux problem from the multiple /dev/ entries did not exist, O_EXCL would prevent you from being able to access non-maiden media in most cases (see the related bug reports on wodim....). As you cannot use O_EXCL and as hald has an implementation bug on Linux, it interrupts the write process, making hald a hostile program with regards to CD/DVD/BD writing. It seems that hald would need to be replaced by something that is developed in cooperation with the people who have the needed skill in the optical media area (e.g. me). Please see Bug 552451 for a summary of the problems and a proposal on how to fix the related problems.