https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #72 from Thomas Schmitt <scdbac...@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 watching all bug changes.
