[k3b] [Bug 137436] Adding support for cdrskin as an alternative to cdrecord/wodim

[Thomas Schmitt]

https://bugs.kde.org/show_bug.cgi?id=137436

--- Comment #72 from Thomas Schmitt <scdbackup at gmx.net> ---
Hi,

> It is better to use Clang ThreadSanitizer to detect pthread related issue

I currently see no indication that the problem with CDEmu is related to
pthreads. The logs report of refusal to perform RESERVE TRACK and of
connection problems between Linux kernel and CDEmu.
The problem indiations stem from the reply of the kernel to ioctl(SG_IO)
which it transmits in fields of the sg_io_hdr_t (as defined in file
/usr/include/scsi/sg.h), or as errno (as defined in /usr/include/errno.h
and its includelings) if the ioctl() call itself returns -1.

A real DVD burner that is not damaged accepts RESERVE TRACK.
If its cabling and the involved bus controllers are ok, it does not bail out
in the middle of burning.

The refusal of CDEmu on RESERVE TRACK probably stems from
 
https://sourceforge.net/p/cdemu/code/ci/master/tree/cdemu-daemon/src/device-commands.c
function command_reserve_track in line 2199.
One would have to find possible reasons for the two refusals with
  cdemu_device_write_sense(self, ILLEGAL_REQUEST, COMMAND_SEQUENCE_ERROR);
in order to learn how to avoid them.

About the reply of sg_io_hdr_t.host_status == 1 and the errno == 19
i cannot say much. That's deeper inside the kernel's device driver
architecture than i ever had to climb down.

As said, i cannot exclude the possibility that some of libburn's activities
cause these problems with CDEmu. But i have no such experiences with my
own drives and got no such reports from other users of real drives.


Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are the assignee for the bug.