Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, Session error : Во время записи на диск произошла ошибка The curse of i18n. Which of my messages might this be ? (Translators, please judge wisely which message might be for the experts and developers and not for the users.) BraseroLibburn SCSI command 2Ah yielded host problem: 0x7 SG_ERR_DID_ERROR Luckily this was not translated. Regrettably we still have the same cause of failure perceived by libburn: Linux SG_IO indicates error. I've tried to install 1.3.4 and 1.3.8 but the problem is still there I would be astonished if it would vanish. (But one never knows ...) The decisive difference between the Linux distros must be somewhere else. We outruled kernel configuration, version (?), and libburn version. There remains systemd, udev, et.al. And there remains the desktop suite. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, i forgot to mention libburn-1.X.Y/cdrskin/README which explains production of statically linked cdrskin, and especially shell command cdrskin/cdrskin -version which states the version of libburn in use. E.g.: cdrskin 1.3.2 : limited cdrecord compatibility wrapper for libburn Cdrecord 2.01-Emulation Copyright (C) 2006-2013, see libburnia-project.org System adapter: internal GNU/Linux SG_IO adapter sg-linux libburn interface : 1.3.2 libburn in use: 1.3.2 cdrskin version : 1.3.2 Version timestamp : 2013.08.07.093001 Build timestamp : -none-given- Further, there is a system adapter which uses libcdio = 0.83 instead of directly using ioctl(SG_IO). (You need package libcdio-dev for the header files at compile time.) make clean ./configure --enable-libcdio make cdrskin/compile_cdrskin.sh cdrskin/cdrskin -version should then report something like System adapter: sg-libcdio h83 with libcdio 0.83 x86_64-pc-linux-gnu Same higher levels, different transport level. Worth a try. libcdio itself uses ioctl(SG_IO), of course. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
I can't compile any versio of libburn with libcdio: dmitry@D-NESTERKIN:~/libburn-1.3.4$ sudo cdrskin/compile_cdrskin.sh Version timestamp : 2013.12.12.093001 Build timestamp : 2015.06.25.130010 compiling program cdrskin/cdrskin.c cdrskin/cdrfifo.c -O2 -DCdrskin_libburn_1_3_4 libburn/cleanup.o libburn/sg.o: In function `sg_grab': /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:567: undefined reference to `cdio_get_arg' /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:569: undefined reference to `cdio_destroy' /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:556: undefined reference to `cdio_open_am' libburn/sg.o: In function `sg_close_drive': /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:217: undefined reference to `cdio_destroy' libburn/sg.o: In function `sg_issue_command': /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:674: undefined reference to `mmc_run_cmd' /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:678: undefined reference to `mmc_last_cmd_sense' libburn/sg.o: In function `sg_give_next_adr_raw': /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:232: undefined reference to `cdio_get_devices' /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:245: undefined reference to `cdio_free_device_list' libburn/sg.o: In function `sg_id_string': /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:351: undefined reference to `cdio_version_string' libburn/sg.o: In function `sg_initialize': /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:368: undefined reference to `cdio_loglevel_default' /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:372: undefined reference to `libcdio_version_num' libburn/sg.o: In function `sg_obtain_scsi_adr': /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:744: undefined reference to `cdio_open' /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:750: undefined reference to `cdio_get_arg' /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:756: undefined reference to `cdio_destroy' collect2: error: ld returned 1 exit status +++ FATAL : Compilation of cdrskin failed dmitry@D-NESTERKIN:~/libburn-1.3.4$ sudo dpkg -l |grep libcdio ii libcdio-cdda1 0.83-4.2 amd64library to read and control digital audio CDs ii libcdio-dev 0.83-4.2 amd64library to read and control CD-ROM (development files) ii libcdio-paranoia1 0.83-4.2 amd64library to read digital audio CDs with error correction ii libcdio13 0.83-4.2 amd64library to read and control CD-ROM dmitry@D-NESTERKIN:~/libburn-1.3.4$ Default compilation parameters give me these errors while burning: https://www.dropbox.com/sh/0dbmyd53bx36s7z/AABT5pJnSsvjzuWZwEirJJSba?dl=0 2015-06-25 15:40 GMT+03:00 Thomas Schmitt scdbac...@gmx.net: Hi, Session error : Во время записи на диск произошла ошибка The curse of i18n. Which of my messages might this be ? (Translators, please judge wisely which message might be for the experts and developers and not for the users.) BraseroLibburn SCSI command 2Ah yielded host problem: 0x7 SG_ERR_DID_ERROR Luckily this was not translated. Regrettably we still have the same cause of failure perceived by libburn: Linux SG_IO indicates error. I've tried to install 1.3.4 and 1.3.8 but the problem is still there I would be astonished if it would vanish. (But one never knows ...) The decisive difference between the Linux distros must be somewhere else. We outruled kernel configuration, version (?), and libburn version. There remains systemd, udev, et.al. And there remains the desktop suite. Have a nice day :) Thomas -- С уважением, Нестеркин Дмитрий
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, So I've downloaded and compiled 1.3.4 versions of libburn, libisoburn and libisofs. After that I've tried brasero again and it failed, but with different error. What error messages exactly ? It would be no surprise if it fails at different block address or with different error messages, as long as the messages indicate the same failure of ioctl(SG_IO). (See below about commits 5180 + 5187.) Even a single success would be not enough. It must work multiple times in a row, in order to be significant. Seems to me that libburn/libisoburn is the main cause of problems. It is nearest to the problem, at least, because it sits between Brasero and the kernel's ioctl(SG_IO). If you can point me to a version that reliably succeeds and one that reliably fails, then there is hope to find the decisive difference. libburn-1.3.2 was released Aug 7 2013 libburn-1.3.4 on Dec 12 2013 Current is http://files.libburnia-project.org/releases/libburn-1.4.0.tar.gz It should work flawlessly with applications which expect older versions since about 0.4.0. All older release tarballs can be found at: http://libburnia-project.org/wiki/OutdatedLibburnReleases libburn has two levels, where differences may have occured: - The system adapter libburn/sg-linux.c which handles all Linux-specific aspects. Among them SG_IO for transport of SCSI/MMC commands and replies. Its history can be inspected via http://libburnia-project.org/log/libburn/trunk/libburn/sg-linux.c No good suspect to see there: Commits 5180 + 5187 promise better error messages in 1.3.4 in comparison to 1.3.2. Commits 5218, 5225, 5335 are supposed to be unrelated to SCSI transport. Commit 5368 was used to diagnose problems with SATA on an ARM board. (USB worked flawlessly on the same machine, SATA produced hick-ups and echoed command relies. Sometimes it worked for a single burn run. Mostly not. The user finally settled with USB.) - The higher functions of libburn could change the wear pattern of controller and drive by causing SCSI commands beeing sent in different sequences. http://libburnia-project.org/log/libburn/trunk/libburn It seems futile to inspect all changsets between 5132 (when 1.3.2 was freshly out and development step 1.3.3 started) and 5426 (after which current release 1.4.0 went out). One would rather have to compare SCSI logs of versions in order to detect decisive differences. In libburn-1.X.Y directory (after ./configre make, to get libburn compiled and cdrskin/compile_cdrskin.sh to get a staticaly linked cdrskin, which needs no make install): cdrskin/cdrskin -V dev=/dev/sr0 blank=as_needed -eject image.iso \ 21 | tee -i /tmp/cdrskin-1.X.Y.log A successful run will produce a WRITE(10) message for every 32 KB. So the log files might become quite large. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, your thought about power seems to be correct because users with disabled USB power management are not affected. This bug report let's me learn things which i never wanted to know. X-) Can you point me to a comprehensive description of the problem ? (The Ubuntu bug report is somewhat scattered.) I am now reading https://www.kernel.org/doc/Documentation/usb/power-management.txt On my system, all files /sys/bus/usb/devices/*/power/wakeup are either missing or contain the word disabled. The ones of the BD drives are missing. /sys/bus/usb/devices/*/power/control has auto for the A-B.C and missing file for A-B.C:1.0. Does this look safe ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, Summary: - Sorry for confusion about libcdio. - The drive is a bit strange with its replies. - There is a bus-or-power problem reported in the run of 1.3.2 which causes comand repetition and error 5 21 02 ILLEGAL REQUEST. - The runs of 1.3.4 and 1.3.8 ended by the 0x7 SG_ERR_DID_ERROR indication from the kernel. - All runs were of write type DVD-R DAO. One could try type DVD-R Incremental. - At the end of this mail is a proposal for an experimental code change in libburn in case of the error of the 1.3.2 run. === dmitry@D-NESTERKIN:~/libburn-1.3.4$ sudo cdrskin/compile_cdrskin.sh compiling program cdrskin/cdrskin.c cdrskin/cdrfifo.c -O2 -DCdrskin_libburn_1_3_4 libburn/cleanup.o ... /home/dmitry/libburn-1.3.4/libburn/sg-libcdio.c:567: undefined reference to `cdio_get_arg' I now see in the script cdrskin/compile_cdrskin.c that libcdio is linked only if you run it with option -use_libcdio cdrskin/compile_cdrskin.sh -use_libcdio sudo should not be necessary if you unpack the tarball as normal user. Strange thing. I tested with cdrskin-1.3.2.pl01.tar.gz and it worked after i installed package libcdio-dev on my quite young system. Probably i ran cdrskin/cdrskin already after make. That's some autotools magic which might work or not. cdrskin/cdrskin is a shell script after make. My dpkg -l reports the same Debian libcdio packages as yours: ii libcdio-cdda1 0.83-4.2amd64 library to read and control digital audio CDs ii libcdio-dev 0.83-4.2amd64 library to read and control CD-ROM (development files) ii libcdio-paranoia1 0.83-4.2amd64 library to read digital audio CDs with error correction ii libcdio13 0.83-4.2amd64 library to read and control CD-ROM === Your dropbox files: cdrskin-1.3.2.log : -- START/STOP UNIT 1b 00 00 00 03 00 +++ sense data = 70 00 05 00 00 00 00 0E 00 00 00 00 24 00 00 00 00 00 +++ key=5 asc=24h ascq=00h -- 5 24 00 means INVALID FIELD IN CDB. (CDB is the SCSI command.) I guess the drive has no tray motor and dislikes the command to pull in the tray. After only 6.531 seconds of the burn run, WRITE(10) gets an error reply, which causes libburn to re-try: -- WRITE(10) 2a 00 00 00 03 10 00 00 10 00 +++ sense data = 70 00 02 00 00 00 00 0E 00 00 00 00 04 08 00 00 00 00 +++ key=2 asc=04h ascq=08h 1286 us [ 6531319 ] -- 2 04 08 is LOGICAL UNIT NOT READY, LONG WRITE IN PROGRESS. This means that one should retry later in the hope that the drive gets ready. But normally a drive just waits with the reply until it is ready to take the next chunk of data (usually 32 KB). All byte codes are shown in hex notation. The bytes 2 to 5 00 00 03 10 of WRITE(10) are the block address in big endian. I.e. 768 in decimal. Well, after nearly 50 seconds it goes on: -- WRITE(10) 2a 00 00 00 03 10 00 00 10 00 1685 us [ 54599719 ] WRITE(10) 2a 00 00 00 03 20 00 00 10 00 +++ sense data = 70 00 02 00 00 00 00 0E 00 00 00 00 04 08 00 00 00 00 +++ key=2 asc=04h ascq=08h 1320 us [ 54601087 ] ... WRITE(10) 2a 00 00 00 03 20 00 00 10 00 1771 us [ 54610346 ] WRITE(10) 2a 00 00 00 03 30 00 00 10 00 +++ sense data = 70 00 02 00 00 00 00 0E 00 00 00 00 04 08 00 00 00 00 +++ key=2 asc=04h ascq=08h 1207 us [ 54611606 ] -- This is strange drive behavior but still plausible for a DVD-R in DAO mode. But then comes an error reply which i have never seen before: -- WRITE(10) 2a 00 00 00 04 00 00 00 10 00 2298537 us [ 57069348 ] WRITE(10) 2a 00 00 00 04 10 00 00 10 00 +++ sense data = 70 00 06 00 00 00 00 0E 00 00 00 00 29 00 00 00 00 00 +++ key=6 asc=29h ascq=00h 774800 us [ 57844400 ] -- MMC-5 lists it as 6 29 00 POWER ON, RESET, OR BUS DEVICE RESET OCCURRED. libburn perceives the error class 6 Drive Event as worth a retry. This leads to -- WRITE(10) 2a 00 00 00 04 10 00 00 10 00 +++ sense data = 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00 00 00 +++ key=5 asc=21h ascq=02h 5247 us [ 57849725 ] cdrskin: FATAL : SCSI error on write(1040,16): [5 21 02] Illegal request. Invalid address for write. -- Possibly the drive wants a write to the
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi! Can't find such piece of code in version 1.3.2. However: /* The waiting time before eventually retrying a failed SCSI command. Before each retry wait Libburn_sg_linux_retry_incR longer than with the previous one. */ #define Libburn_sg_linux_retry_usleeP 10 #define Libburn_sg_linux_retry_incR 10 2015-06-25 19:02 GMT+03:00 Thomas Schmitt scdbac...@gmx.net: Hi, libburn might be contributing to high power consumption by firing a lot of retried WRITE(10) commands to the yet-not-ready drive. In the old days of CD burning, it was essential not to let the drive buffer run empty. But with DVD you could try to slow down the retries: In libburn/sg-linux.c there is a code piece break; /* if ! done : loop for retry */; } which could be changed to break; /* if ! done : loop for retry */; usleep(1); } Waiting 10 microseconds at DVD speed 16 would mean to delay about 220 KB, which should be much less than the drive buffer size. So there is a chance to catch up. (Nevertheless the execution times of initial WRITE(10) commands indicate a maximum transfer speed of about 16000 KB/s = 12x DVD.) Have a nice day :) Thomas -- С уважением, Нестеркин Дмитрий
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, libburn might be contributing to high power consumption by firing a lot of retried WRITE(10) commands to the yet-not-ready drive. In the old days of CD burning, it was essential not to let the drive buffer run empty. But with DVD you could try to slow down the retries: In libburn/sg-linux.c there is a code piece break; /* if ! done : loop for retry */; } which could be changed to break; /* if ! done : loop for retry */; usleep(1); } Waiting 10 microseconds at DVD speed 16 would mean to delay about 220 KB, which should be much less than the drive buffer size. So there is a chance to catch up. (Nevertheless the execution times of initial WRITE(10) commands indicate a maximum transfer speed of about 16000 KB/s = 12x DVD.) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, The bug is in xHCI support. So it WAS a bus/device reset indeed. After disabling USB 3.0 in BIOS I was able to successfully burn DVD using cdrskin. Oh yes. So end most of my merry bug hunts. :)) (Please sign the Thomas-is-not-to-blame warrant and file it to the applicable authorities.) Now how do i identify whether my BD burners are at USB 3.0 ? The USB boxes are off when booting. I enforce reproducible device addresses by switching them on one by one later. Then i get messages like: [ 9048.631388] usb 1-1.1: new high-speed USB device number 7 using ehci-pci [ 9083.417859] usb 1-1.2: new high-speed USB device number 8 using ehci-pci [10155.914226] usb 1-1.3: new high-speed USB device number 9 using ehci-pci But i also isuccessfully copied about 350 GB from a USB disk: [16375.104439] usb 3-1: new high-speed USB device number 2 using xhci_hcd It seems there is a hardware component involved, which i am glad to not have bought with my new machine. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Google says that different devices fail after different time or volume of data. Reliable kernels seem to be 3.12.32, 3.17.4-3.17.6. Maybe 4.0.1 and 4.0.5. I'm going to test them all. And yes, your thought about power seems to be correct because users with disabled USB power management are not affected. 25.06.2015 21:19 пользователь Thomas Schmitt scdbac...@gmx.net написал: Hi, The bug is in xHCI support. So it WAS a bus/device reset indeed. After disabling USB 3.0 in BIOS I was able to successfully burn DVD using cdrskin. Oh yes. So end most of my merry bug hunts. :)) (Please sign the Thomas-is-not-to-blame warrant and file it to the applicable authorities.) Now how do i identify whether my BD burners are at USB 3.0 ? The USB boxes are off when booting. I enforce reproducible device addresses by switching them on one by one later. Then i get messages like: [ 9048.631388] usb 1-1.1: new high-speed USB device number 7 using ehci-pci [ 9083.417859] usb 1-1.2: new high-speed USB device number 8 using ehci-pci [10155.914226] usb 1-1.3: new high-speed USB device number 9 using ehci-pci But i also isuccessfully copied about 350 GB from a USB disk: [16375.104439] usb 3-1: new high-speed USB device number 2 using xhci_hcd It seems there is a hardware component involved, which i am glad to not have bought with my new machine. Have a nice day :) Thomas
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, Can't find such piece of code in version 1.3.2. Urm ... yes. The comment appeared in 1.3.4. In 1.3.2 it is done = scsi_eval_cmd_outcome(d, c, fp, s.sbp, s.sb_len_wr, start_time, s.timeout, i, 0); if (d-cancel) done = 1; } which would become done = scsi_eval_cmd_outcome(d, c, fp, s.sbp, s.sb_len_wr, start_time, s.timeout, i, 0); if (d-cancel) done = 1; usleep(1); } #define Libburn_sg_linux_retry_usleeP 10 #define Libburn_sg_linux_retry_incR 10 This seems to be a remnant of older code. Thrown out with commit 3483, but already disabled by 3368. Now it is in libburn/spc.c function scsi_eval_cmd_outcome(). The macros are in libburn/spc.h /* The waiting time before eventually retrying a failed SCSI command. Before each retry wait Libburn_scsi_retry_incR longer than with the previous one. At most wait for Libburn_scsi_retry_umaX microseconds. */ #define Libburn_scsi_write_retry_usleeP 0 #define Libburn_scsi_write_retry_incR2000 #define Libburn_scsi_write_retry_umaX 25000 The equivalent to my code change proposal would have been #define Libburn_scsi_write_retry_usleeP 1 #define Libburn_scsi_write_retry_incR 0 #define Libburn_scsi_write_retry_umaX ...whatever... It seems already to work in e.g. 1.3.8. The differences of the timestamps [ 2880923 ] [ 2884447 ] [ 2890019 ] [ 2899397 ] minus the execution times 5778 , 1410, 1475 yield non-SCSI-execution timegaps of 36, 2114, 4097 microseconds. I.e. the repetition spent most time at a waiting time of 25000 microseconds. So i change my proposal to setting in libburn/spc.c : #define Libburn_scsi_write_retry_usleeP 1 #define Libburn_scsi_write_retry_incR5000 #define Libburn_scsi_write_retry_umaX 10 This reduces the workload during the first 50 seconds to 25 percent of the current one. At 16 x DVD speed it risks that the driver buffer runs empty. Let's see. During the following time it will reduce the number of unsuccessful retries substantially. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi! Some more info. I've tried to compile kernel using config from Linux Mint. Compilation of the kernel source that comes with distro failed because of some missing files. However, I was able to compile kernel 3.18 using config from Mint. Sadly, the problem was still there. After that I've tried to inspect versions of brasero and libs used in different distros. It seems that Mint uses brasero 3.10.0 and Debian Uses brasero 3.11.4. I've decided not to revert back just now (something else may break). However, Mint uses libburn4 version 1.3.4 instead of 1.3.2 in Debian. So I've downloaded and compiled 1.3.4 versions of libburn, libisoburn and libisofs. After that I've tried brasero again and it failed, but with different error. Seems to me that libburn/libisoburn is the main cause of problems. 2015-06-23 19:01 GMT+03:00 Дмитрий Нестеркин undelb...@gmail.com: Hello. Well, bad news. No kernel version I've tested worked. I've tried: 3.18.16, 3.19.8, 4.0.6. All kernels were compiled with .config file currently present in my system (default one that comes with distro). All kernel tests ended with [5 21 02] Illegal request. Invalid address for write Debian Live DVD does not work either. Kernel modules you requested: dmitry@D-NESTERKIN:~$ sudo lsmod |grep usb [sudo] password for dmitry: usbhid 44460 0 btusb 29721 0 bluetooth 374429 1 btusb hid 102264 2 hid_generic,usbhid usb_storage56215 0 scsi_mod 191405 5 sg,usb_storage,libata,sd_mod,sr_mod usbcore 195340 7 btusb,uvcvideo,usb_storage,ehci_hcd,ehci_pci,usbhid,xhci_hcd usb_common 12440 1 usbcore dmitry@D-NESTERKIN:~$ dmitry@D-NESTERKIN:~$ sudo lsmod |grep scsi scsi_mod 191405 5 sg,usb_storage,libata,sd_mod,sr_mod dmitry@D-NESTERKIN:~$ dmitry@D-NESTERKIN:~$ sudo lsmod |grep ata libata177457 2 ahci,libahci scsi_mod 191405 5 sg,usb_storage,libata,sd_mod,sr_mod dmitry@D-NESTERKIN:~$ I've also tried to install firmware-linux-free and firmware-linux-nonfree packages with no luck. 2015-06-23 10:23 GMT+03:00 Дмитрий Нестеркин undelb...@gmail.com: One more: when I first booted with new kernel, some resets were logged: Jun 23 10:09:34 D-NESTERKIN kernel: [2.468462] usb 1-3.3: new high-speed USB device number 4 using xhci_hcd Jun 23 10:09:34 D-NESTERKIN kernel: [2.559042] usb 1-3.3: New USB device found, idVendor=093b, idProduct=0023 Jun 23 10:09:34 D-NESTERKIN kernel: [2.559047] usb 1-3.3: New USB device strings: Mfr=85, Product=57, SerialNumber=44 Jun 23 10:09:34 D-NESTERKIN kernel: [2.559050] usb 1-3.3: Product: PLEXTOR USB Storage Adapter Jun 23 10:09:34 D-NESTERKIN kernel: [2.559053] usb 1-3.3: Manufacturer: PLEXTOR Jun 23 10:09:34 D-NESTERKIN kernel: [2.559055] usb 1-3.3: SerialNumber: ABC10CA1F554 Jun 23 10:09:34 D-NESTERKIN kernel: [5.422571] usb 1-3.3: reset high-speed USB device number 4 using xhci_hcd Jun 23 10:09:34 D-NESTERKIN kernel: [6.491309] usb 1-3.3: reset high-speed USB device number 4 using xhci_hcd Jun 23 10:09:34 D-NESTERKIN kernel: [7.559969] usb 1-3.3: reset high-speed USB device number 4 using xhci_hcd Jun 23 10:09:34 D-NESTERKIN kernel: [8.628865] usb 1-3.3: reset high-speed USB device number 4 using xhci_hcd 2015-06-23 10:21 GMT+03:00 Дмитрий Нестеркин undelb...@gmail.com: Kernel 3.18.16 gives me exactly the same error. At the moment, I need to do some work stuff, but I'll be doing more experiments ASAP. 2015-06-23 0:42 GMT+03:00 Дмитрий Нестеркин undelb...@gmail.com: I've downloaded 3.18.16 longterm kernel and plan to compile it on my system. Linux Mint (which is OK) uses kernel 3.13 and fedora 22 uses kernel 4.0 (also ok). In fact there is a lot of UAS/USB bugs reported for kernel 3.16 (and some for 3.15 and 3.17). Controllers you mentioned are USB 3.0. My drive is definitely USB 2.0. However, if it looks like a duck, swim like a duck and quacks like a duck... I'll definitely need to try new kernel. 2015-06-22 21:34 GMT+03:00 Thomas Schmitt scdbac...@gmx.net: Hi, I have found some interesting discussion about UAS bugs in kernel 3.16: https://lists.debian.org/debian-kernel/2014/07/msg00318.html UAS ... google ... wikipedia ... Well, it would be the natural way to perform SG_IO with a USB device. Burn programs issue SCSI commands and UAS is designed for transporting them. Wikipedia has: Version 3.18-rc4 of the Linux kernel disables buggy UAS implementation in xHCI host controllers Etron EJ168, ASMedia ASM1042,[19] and VIA VL80x.[20] But i understand that UAS is quite a new protocol. Is your drive's USB controller young enough ? (Actually i assume the drive is SATA or IDE and the box has a USB-SATA or USB-IDE bridge bridge.) An here comes the output from my kern.log: Jun 22 15:12:02 D-NESTERKIN kernel: [1.508233] usb 3-2:
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hello. Well, bad news. No kernel version I've tested worked. I've tried: 3.18.16, 3.19.8, 4.0.6. All kernels were compiled with .config file currently present in my system (default one that comes with distro). All kernel tests ended with [5 21 02] Illegal request. Invalid address for write Debian Live DVD does not work either. Kernel modules you requested: dmitry@D-NESTERKIN:~$ sudo lsmod |grep usb [sudo] password for dmitry: usbhid 44460 0 btusb 29721 0 bluetooth 374429 1 btusb hid 102264 2 hid_generic,usbhid usb_storage56215 0 scsi_mod 191405 5 sg,usb_storage,libata,sd_mod,sr_mod usbcore 195340 7 btusb,uvcvideo,usb_storage,ehci_hcd,ehci_pci,usbhid,xhci_hcd usb_common 12440 1 usbcore dmitry@D-NESTERKIN:~$ dmitry@D-NESTERKIN:~$ sudo lsmod |grep scsi scsi_mod 191405 5 sg,usb_storage,libata,sd_mod,sr_mod dmitry@D-NESTERKIN:~$ dmitry@D-NESTERKIN:~$ sudo lsmod |grep ata libata177457 2 ahci,libahci scsi_mod 191405 5 sg,usb_storage,libata,sd_mod,sr_mod dmitry@D-NESTERKIN:~$ I've also tried to install firmware-linux-free and firmware-linux-nonfree packages with no luck. 2015-06-23 10:23 GMT+03:00 Дмитрий Нестеркин undelb...@gmail.com: One more: when I first booted with new kernel, some resets were logged: Jun 23 10:09:34 D-NESTERKIN kernel: [2.468462] usb 1-3.3: new high-speed USB device number 4 using xhci_hcd Jun 23 10:09:34 D-NESTERKIN kernel: [2.559042] usb 1-3.3: New USB device found, idVendor=093b, idProduct=0023 Jun 23 10:09:34 D-NESTERKIN kernel: [2.559047] usb 1-3.3: New USB device strings: Mfr=85, Product=57, SerialNumber=44 Jun 23 10:09:34 D-NESTERKIN kernel: [2.559050] usb 1-3.3: Product: PLEXTOR USB Storage Adapter Jun 23 10:09:34 D-NESTERKIN kernel: [2.559053] usb 1-3.3: Manufacturer: PLEXTOR Jun 23 10:09:34 D-NESTERKIN kernel: [2.559055] usb 1-3.3: SerialNumber: ABC10CA1F554 Jun 23 10:09:34 D-NESTERKIN kernel: [5.422571] usb 1-3.3: reset high-speed USB device number 4 using xhci_hcd Jun 23 10:09:34 D-NESTERKIN kernel: [6.491309] usb 1-3.3: reset high-speed USB device number 4 using xhci_hcd Jun 23 10:09:34 D-NESTERKIN kernel: [7.559969] usb 1-3.3: reset high-speed USB device number 4 using xhci_hcd Jun 23 10:09:34 D-NESTERKIN kernel: [8.628865] usb 1-3.3: reset high-speed USB device number 4 using xhci_hcd 2015-06-23 10:21 GMT+03:00 Дмитрий Нестеркин undelb...@gmail.com: Kernel 3.18.16 gives me exactly the same error. At the moment, I need to do some work stuff, but I'll be doing more experiments ASAP. 2015-06-23 0:42 GMT+03:00 Дмитрий Нестеркин undelb...@gmail.com: I've downloaded 3.18.16 longterm kernel and plan to compile it on my system. Linux Mint (which is OK) uses kernel 3.13 and fedora 22 uses kernel 4.0 (also ok). In fact there is a lot of UAS/USB bugs reported for kernel 3.16 (and some for 3.15 and 3.17). Controllers you mentioned are USB 3.0. My drive is definitely USB 2.0. However, if it looks like a duck, swim like a duck and quacks like a duck... I'll definitely need to try new kernel. 2015-06-22 21:34 GMT+03:00 Thomas Schmitt scdbac...@gmx.net: Hi, I have found some interesting discussion about UAS bugs in kernel 3.16: https://lists.debian.org/debian-kernel/2014/07/msg00318.html UAS ... google ... wikipedia ... Well, it would be the natural way to perform SG_IO with a USB device. Burn programs issue SCSI commands and UAS is designed for transporting them. Wikipedia has: Version 3.18-rc4 of the Linux kernel disables buggy UAS implementation in xHCI host controllers Etron EJ168, ASMedia ASM1042,[19] and VIA VL80x.[20] But i understand that UAS is quite a new protocol. Is your drive's USB controller young enough ? (Actually i assume the drive is SATA or IDE and the box has a USB-SATA or USB-IDE bridge bridge.) An here comes the output from my kern.log: Jun 22 15:12:02 D-NESTERKIN kernel: [1.508233] usb 3-2: Product: PLEXTOR USB Storage Adapter They really give few clue about age and version of the drive-side USB controller. I googled for PLEXTOR USB Storage Adapter UAS and found nearly nothing. Descriptions of UAS refer to hard disks and SSDs, rather than optical drives. But - as stated - i expect it to depend on the USB-SATA or USB-IDE controller of the drive box. In any case, recent changes in USB are obvious suspects. Now i'm curious whether the working and non-working Linuxes show a pattern with kernel revisions. Have a nice day :) Thomas -- С уважением, Нестеркин Дмитрий -- С уважением, Нестеркин Дмитрий -- С уважением, Нестеркин Дмитрий -- Best regards, Dmitry Nesterkin
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Kernel 3.18.16 gives me exactly the same error. At the moment, I need to do some work stuff, but I'll be doing more experiments ASAP. 2015-06-23 0:42 GMT+03:00 Дмитрий Нестеркин undelb...@gmail.com: I've downloaded 3.18.16 longterm kernel and plan to compile it on my system. Linux Mint (which is OK) uses kernel 3.13 and fedora 22 uses kernel 4.0 (also ok). In fact there is a lot of UAS/USB bugs reported for kernel 3.16 (and some for 3.15 and 3.17). Controllers you mentioned are USB 3.0. My drive is definitely USB 2.0. However, if it looks like a duck, swim like a duck and quacks like a duck... I'll definitely need to try new kernel. 2015-06-22 21:34 GMT+03:00 Thomas Schmitt scdbac...@gmx.net: Hi, I have found some interesting discussion about UAS bugs in kernel 3.16: https://lists.debian.org/debian-kernel/2014/07/msg00318.html UAS ... google ... wikipedia ... Well, it would be the natural way to perform SG_IO with a USB device. Burn programs issue SCSI commands and UAS is designed for transporting them. Wikipedia has: Version 3.18-rc4 of the Linux kernel disables buggy UAS implementation in xHCI host controllers Etron EJ168, ASMedia ASM1042,[19] and VIA VL80x.[20] But i understand that UAS is quite a new protocol. Is your drive's USB controller young enough ? (Actually i assume the drive is SATA or IDE and the box has a USB-SATA or USB-IDE bridge bridge.) An here comes the output from my kern.log: Jun 22 15:12:02 D-NESTERKIN kernel: [1.508233] usb 3-2: Product: PLEXTOR USB Storage Adapter They really give few clue about age and version of the drive-side USB controller. I googled for PLEXTOR USB Storage Adapter UAS and found nearly nothing. Descriptions of UAS refer to hard disks and SSDs, rather than optical drives. But - as stated - i expect it to depend on the USB-SATA or USB-IDE controller of the drive box. In any case, recent changes in USB are obvious suspects. Now i'm curious whether the working and non-working Linuxes show a pattern with kernel revisions. Have a nice day :) Thomas -- С уважением, Нестеркин Дмитрий -- С уважением, Нестеркин Дмитрий
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
One more: when I first booted with new kernel, some resets were logged: Jun 23 10:09:34 D-NESTERKIN kernel: [2.468462] usb 1-3.3: new high-speed USB device number 4 using xhci_hcd Jun 23 10:09:34 D-NESTERKIN kernel: [2.559042] usb 1-3.3: New USB device found, idVendor=093b, idProduct=0023 Jun 23 10:09:34 D-NESTERKIN kernel: [2.559047] usb 1-3.3: New USB device strings: Mfr=85, Product=57, SerialNumber=44 Jun 23 10:09:34 D-NESTERKIN kernel: [2.559050] usb 1-3.3: Product: PLEXTOR USB Storage Adapter Jun 23 10:09:34 D-NESTERKIN kernel: [2.559053] usb 1-3.3: Manufacturer: PLEXTOR Jun 23 10:09:34 D-NESTERKIN kernel: [2.559055] usb 1-3.3: SerialNumber: ABC10CA1F554 Jun 23 10:09:34 D-NESTERKIN kernel: [5.422571] usb 1-3.3: reset high-speed USB device number 4 using xhci_hcd Jun 23 10:09:34 D-NESTERKIN kernel: [6.491309] usb 1-3.3: reset high-speed USB device number 4 using xhci_hcd Jun 23 10:09:34 D-NESTERKIN kernel: [7.559969] usb 1-3.3: reset high-speed USB device number 4 using xhci_hcd Jun 23 10:09:34 D-NESTERKIN kernel: [8.628865] usb 1-3.3: reset high-speed USB device number 4 using xhci_hcd 2015-06-23 10:21 GMT+03:00 Дмитрий Нестеркин undelb...@gmail.com: Kernel 3.18.16 gives me exactly the same error. At the moment, I need to do some work stuff, but I'll be doing more experiments ASAP. 2015-06-23 0:42 GMT+03:00 Дмитрий Нестеркин undelb...@gmail.com: I've downloaded 3.18.16 longterm kernel and plan to compile it on my system. Linux Mint (which is OK) uses kernel 3.13 and fedora 22 uses kernel 4.0 (also ok). In fact there is a lot of UAS/USB bugs reported for kernel 3.16 (and some for 3.15 and 3.17). Controllers you mentioned are USB 3.0. My drive is definitely USB 2.0. However, if it looks like a duck, swim like a duck and quacks like a duck... I'll definitely need to try new kernel. 2015-06-22 21:34 GMT+03:00 Thomas Schmitt scdbac...@gmx.net: Hi, I have found some interesting discussion about UAS bugs in kernel 3.16: https://lists.debian.org/debian-kernel/2014/07/msg00318.html UAS ... google ... wikipedia ... Well, it would be the natural way to perform SG_IO with a USB device. Burn programs issue SCSI commands and UAS is designed for transporting them. Wikipedia has: Version 3.18-rc4 of the Linux kernel disables buggy UAS implementation in xHCI host controllers Etron EJ168, ASMedia ASM1042,[19] and VIA VL80x.[20] But i understand that UAS is quite a new protocol. Is your drive's USB controller young enough ? (Actually i assume the drive is SATA or IDE and the box has a USB-SATA or USB-IDE bridge bridge.) An here comes the output from my kern.log: Jun 22 15:12:02 D-NESTERKIN kernel: [1.508233] usb 3-2: Product: PLEXTOR USB Storage Adapter They really give few clue about age and version of the drive-side USB controller. I googled for PLEXTOR USB Storage Adapter UAS and found nearly nothing. Descriptions of UAS refer to hard disks and SSDs, rather than optical drives. But - as stated - i expect it to depend on the USB-SATA or USB-IDE controller of the drive box. In any case, recent changes in USB are obvious suspects. Now i'm curious whether the working and non-working Linuxes show a pattern with kernel revisions. Have a nice day :) Thomas -- С уважением, Нестеркин Дмитрий -- С уважением, Нестеркин Дмитрий -- С уважением, Нестеркин Дмитрий
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, I suppose it would be also helpful to compare not only kernel versions, but also libs versions involved. Kernel modules for USB, (S)ATA, SCSI, maybe. Userland libraries should hardly be involved, unless they impose workload on USB. Last time i tried to understand SG_IO, i ended up at the entrance of the i/o elevator. Dunno where the request leaves that thing and hits the hardware controller driver. At some point of my current endeavor i will have to find out why the new kernel shows such a miserable performance with two concurrent DVD burns. I already read rumors that it performs SG_IO synchronously in a single queue for all devices. But i had thought that 2 times 4x DVD speed would be no problem for a contemporary system. My olde 2.6 on weaker hardware did it without problems. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, I've found working distros! Interesting observation. I assume it is matter of the kernel version or of the wear pattern at the USB hardware. Did you try a Debain Live CD ? Maybe it's not the kernel but some Desktop feature which causes problems by overly busy USB activities. So it's definitely a Debian issue that need to be resolved. But whom to ask for help ? Even if you find a developer who is interested, there will remain the problem of reproducability. I am running three BD drives at USB of Debian 8.1. ... 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux No problems to see there. (I wish i could say that about the system setup, already.) The system is one week old. But i already made base backups via these drives and daily updates. About 400 GB went through the wire forth and back (when being checkread). But if you find a pattern in kernel versions or Live Desktops then there might be the opportunity to get your individual system salvaged. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
2015-06-22 19:58 GMT+03:00 Thomas Schmitt scdbac...@gmx.net: Did you try a Debain Live CD ? Hmm... no. But I'll try it and get back with results. I suppose it would be also helpful to compare not only kernel versions, but also libs versions involved. Can you please tell me which libs versions I should compare? -- Best regards, Dmitry Nesterkin
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
I've downloaded 3.18.16 longterm kernel and plan to compile it on my system. Linux Mint (which is OK) uses kernel 3.13 and fedora 22 uses kernel 4.0 (also ok). In fact there is a lot of UAS/USB bugs reported for kernel 3.16 (and some for 3.15 and 3.17). Controllers you mentioned are USB 3.0. My drive is definitely USB 2.0. However, if it looks like a duck, swim like a duck and quacks like a duck... I'll definitely need to try new kernel. 2015-06-22 21:34 GMT+03:00 Thomas Schmitt scdbac...@gmx.net: Hi, I have found some interesting discussion about UAS bugs in kernel 3.16: https://lists.debian.org/debian-kernel/2014/07/msg00318.html UAS ... google ... wikipedia ... Well, it would be the natural way to perform SG_IO with a USB device. Burn programs issue SCSI commands and UAS is designed for transporting them. Wikipedia has: Version 3.18-rc4 of the Linux kernel disables buggy UAS implementation in xHCI host controllers Etron EJ168, ASMedia ASM1042,[19] and VIA VL80x.[20] But i understand that UAS is quite a new protocol. Is your drive's USB controller young enough ? (Actually i assume the drive is SATA or IDE and the box has a USB-SATA or USB-IDE bridge bridge.) An here comes the output from my kern.log: Jun 22 15:12:02 D-NESTERKIN kernel: [1.508233] usb 3-2: Product: PLEXTOR USB Storage Adapter They really give few clue about age and version of the drive-side USB controller. I googled for PLEXTOR USB Storage Adapter UAS and found nearly nothing. Descriptions of UAS refer to hard disks and SSDs, rather than optical drives. But - as stated - i expect it to depend on the USB-SATA or USB-IDE controller of the drive box. In any case, recent changes in USB are obvious suspects. Now i'm curious whether the working and non-working Linuxes show a pattern with kernel revisions. Have a nice day :) Thomas -- С уважением, Нестеркин Дмитрий
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Thanks, I'll get the info ASAP. In the meantime, I have found some interesting discussion about UAS bugs in kernel 3.16: https://lists.debian.org/debian-kernel/2014/07/msg00318.html https://bbs.archlinux.org/viewtopic.php?id=183190 And another one in kernel 3.17: https://bbs.archlinux.org/viewtopic.php?id=189324 An here comes the output from my kern.log: Jun 22 15:12:02 D-NESTERKIN kernel: [1.377470] usb 3-2: new high-speed USB device number 2 using xhci_hcd Jun 22 15:12:02 D-NESTERKIN kernel: [1.508224] usb 3-2: New USB device found, idVendor=093b, idProduct=0023 Jun 22 15:12:02 D-NESTERKIN kernel: [1.508230] usb 3-2: New USB device strings: Mfr=85, Product=57, SerialNumber=44 Jun 22 15:12:02 D-NESTERKIN kernel: [1.508233] usb 3-2: Product: PLEXTOR USB Storage Adapter Jun 22 15:12:02 D-NESTERKIN kernel: [1.508235] usb 3-2: Manufacturer: PLEXTOR Jun 22 15:12:02 D-NESTERKIN kernel: [1.508238] usb 3-2: SerialNumber: ABC10CA1F554 Jun 22 15:12:02 D-NESTERKIN kernel: [1.510924] usb-storage 3-2:1.0: USB Mass Storage device detected Jun 22 15:12:02 D-NESTERKIN kernel: [1.58] scsi6 : usb-storage 3-2:1.0 Jun 22 15:12:02 D-NESTERKIN kernel: [1.511270] usbcore: registered new interface driver usb-storage Looks somewhat similar for me. 2015-06-22 20:37 GMT+03:00 Thomas Schmitt scdbac...@gmx.net: Hi, I suppose it would be also helpful to compare not only kernel versions, but also libs versions involved. Kernel modules for USB, (S)ATA, SCSI, maybe. Userland libraries should hardly be involved, unless they impose workload on USB. Last time i tried to understand SG_IO, i ended up at the entrance of the i/o elevator. Dunno where the request leaves that thing and hits the hardware controller driver. At some point of my current endeavor i will have to find out why the new kernel shows such a miserable performance with two concurrent DVD burns. I already read rumors that it performs SG_IO synchronously in a single queue for all devices. But i had thought that 2 times 4x DVD speed would be no problem for a contemporary system. My olde 2.6 on weaker hardware did it without problems. Have a nice day :) Thomas -- С уважением, Нестеркин Дмитрий
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, I have found some interesting discussion about UAS bugs in kernel 3.16: https://lists.debian.org/debian-kernel/2014/07/msg00318.html UAS ... google ... wikipedia ... Well, it would be the natural way to perform SG_IO with a USB device. Burn programs issue SCSI commands and UAS is designed for transporting them. Wikipedia has: Version 3.18-rc4 of the Linux kernel disables buggy UAS implementation in xHCI host controllers Etron EJ168, ASMedia ASM1042,[19] and VIA VL80x.[20] But i understand that UAS is quite a new protocol. Is your drive's USB controller young enough ? (Actually i assume the drive is SATA or IDE and the box has a USB-SATA or USB-IDE bridge bridge.) An here comes the output from my kern.log: Jun 22 15:12:02 D-NESTERKIN kernel: [ 1.508233] usb 3-2: Product: PLEXTOR USB Storage Adapter They really give few clue about age and version of the drive-side USB controller. I googled for PLEXTOR USB Storage Adapter UAS and found nearly nothing. Descriptions of UAS refer to hard disks and SSDs, rather than optical drives. But - as stated - i expect it to depend on the USB-SATA or USB-IDE controller of the drive box. In any case, recent changes in USB are obvious suspects. Now i'm curious whether the working and non-working Linuxes show a pattern with kernel revisions. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, https://forums.opensuse.org/showthread.php/437135-Cannot-Burn-to-DVD-R-Disc-with-Plextor-PX-716SA This describes timeouts during the burn process. Not what you experience. I riddle about faio_wait_on_buffer in the report about cdrskin. Neither libburn nor cdrskin have it or use it as system call. I cannot find it in linux-source-3.16, but rather among the software of Joerg Schilling (cdrecord et.al.). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=246647 This is an aborted SCSI command with an error code probably fabricated by the kernel. But the follow-up https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=246647#25 looks more similar to your problem. I'm thinking of recompiling the kernel to tweak it for my case. can you suggest any options that i can try to enable/disale? Regrettably no. Therefore my advise to ask kernel developers if you can find some and get them interested. Burn programs are userland tools and rely on flawless execution of ioctl(SG_IO). I can only thing about legacy scsi support. Ewww ... that's really old. And i am not aware that it ever applied to USB connected drives. I used it a decade ago for IDE connected drives. /dev/sg rather than /dev/sr. Finally it is supposed to use the same low level drivers as the /dev/sr driver. I'd expect that the problem sits at the low level. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hello. Here comes what I was able to find over the Internet. Burning issue with another Plextor drive and openSUSE 11.2: https://forums.opensuse.org/showthread.php/437135-Cannot-Burn-to-DVD-R-Disc-with-Plextor-PX-716SA Very old kernel bug related to burning: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=246647 There are some other posts reporting issues with Plextor drives under Linux, however most of them are unanswered. I'm thinking of recompiling the kernel to tweak it for my case. can you suggest any options that i can try to enable/disale? I can only thing about legacy scsi support. Have a nice weekend 2015-06-19 19:45 GMT+03:00 Thomas Schmitt scdbac...@gmx.net: Hi, growisofs was able to write the largest volume of data. Brasero, k3b and xfburn all failed after just some seconds. But K3b used growisofs for burning. To my personal experience with nearly failing hardware it is quite futile to search for patterns in the instability. (And i spent some time with diagnosing such situations.) However, k3b has successfully simulated the burning. This needs less electrical power than real burning. Plextor uses 2 USB cables (one for power) Do you have a dedicated power supply for it ? Something like on http://www.notebookreview.com/assets/30825.jpg If so, try whether it works better then. I have also found in Google that something similar users experienced in openSUSE 11.2 it was fixed after update to 11.3. Can you remember some URL ? Would be interesting to read if it affected DVD burning. - Whatever, as long as the system call ioctl(...,SG_IO,...) returns with indication for SG_ERR_DID_ERROR, i can hardly do anything for you. If other burn software yields significantly different results then it might be due to small differences in write parameters. E.g. whether DVD-R is written as DAO or as Incremental, or whether on DVD+R a track was reserved before writing. During data transfer both programs use WRITE(10) but might have a different rythm with inquiring the buffer fill. But on the next error prone drive, the situation can be just the other way: libburn succeeds and growisofs fails. We'd need some time to find out which difference between growisofs and libburn would cause the different performance. And only your computer system can tell. The only hint i can give now is to post a bug for the kernel, saying the component host_status of sg_io_hdr_t as defined in /usr/include/scsi/sg.h has the value of 7 after ioctl(SG_IO). (Specs: http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/x291.html) Have a nice day :) Thomas -- С уважением, Нестеркин Дмитрий
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, i'm the developer of libburn which is quite orphaned in Debian, i fear. Problem can be reproduced via: Brasero, k3b, xfburn, growisofs At least growisofs does not use libburn. K3b hardly (if so, then via cdrskin replacing cdrecord/wodim). Brasero might use it, depending of compilation and configuration. xfburn surely uses libburn. So the problem is reported to the right package, although i currently doubt that it's the package's fault. SCSI error on write(3376,16): [5 21 02] Illegal request. Invalid address for write. This message looks like from libburn. It is forwarded from the drive, which is unhappy with the block write address 3376. Incompatibility with Plextor PX-608CU burner I never saw evidence that a particular DVD burner model is incompatible. There were CD drives with particular needs, back in the last century. But nowadays they all obey the command set and rules of SCSI. (Specified in the volumes SPC-3, SBC-2, and MMC-5.) Google PX-608CU tells me that it was around already in the year 2007. How old is yours ? Now let's see what is going on. BraseroLibburn dvd/bd Profile= 11h , obs= 32768 , obs_pad= 1 Brasero used libburn on a DVD-R. BraseroLibburn DVD pre-track 01 : get_nwa(0), ret= 1 , d-nwa= 0 It was blank. Write start address was 0. BraseroLibburn SCSI command 2Ah indicates host or driver error: host_status= 7h , driver_status= 0h Ouch. Linux reports a problem with transporting SCSI commands to the drive or with receiving replies. I'm not a kernel hacker so i don't have more than the SG_IO interface description: http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/x291.html SG_ERR_DID_ERROR [0x07] Internal error detected in the host adapter. This may not be fatal (and the command may have succeeded). The aic7xxx and sym53c8xx adapter drivers sometimes report this for data underruns or overruns. The mentioned hardware is antique. I'd say no USB, IDE or SATA controller is supposed to cause this error for fun. BraseroLibburn SCSI error condition on command 2Ah WRITE(10): [5 21 02] Illegal request. Invalid address for write. The failed SCSI command was indeed a write. BraseroLibburn Libburn reported an error SCSI error on write(2080,16): [5 21 02] Illegal request. Invalid address for write. So this time it happened at address 2080. sudo growisofs -speed=4 -dvd-compat -Z /dev/sr0=/media/dmitry/Partition_2/ISO_Images/Soft/myiso.iso ... 562397184/2906822656 (19.3%) @1.9x, remaining 15:50 RBU 100.0% UBU 53.1% :-( unable to WRITE@LBA=430b0h: Input/output error This time it happened much later. about 550 MB were written. Since growisofs does not report an SCSI error code triple of (SK, ASC, ASCQ), i assume that it got a transport driver error, like libburn did. The problem is not hardware-related, Well, it is reported by the kernel, which accuses the controller to have indicated an error condition. The reported SCSI error is most probably only a consequence of the communications problem between kernel and drive. DVD-R and DVD+R need to be written strictly sequentially. If transport drops a WRITE command of 16 blocks, then the next one will appear to the drive as having an address 16 blocks too high. This would cause it to throw the error [5 21 02] seen with libburn. (libburn does not go on with the drive after SG_ERR_DID_ERROR. So for this theory, the dropping of WRITE must have happened silently and the transport error only came afterwards.) I will have a look whether libburn can be changed to repeat the SCSI command when transport indicates failure. Repeating might be the trick how MS-Windows gets over the hardware connection problem. But the Linux description says: the command may have succeeded Repeating a successful WRITE command would cause error [5 21 02], too. I cannot promise a test version soon. On the first hand, transport should be flawless. As you can see, neither growisofs nor libburn are currently willing to tolerate SG_ERR_DID_ERROR. Samsung external DVD-burner works OK under Debian. Do you plug it into the same USB port as the Plextor ? If so, then the Plextor has at least some share in the problem. Have anice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Package: libburn4 Version: 1.3.2-1.1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libburn4 depends on: ii libc6 2.19-18 libburn4 recommends no packages. libburn4 suggests no packages. -- no debconf information When trying to burn *.iso to dvd-r/dvd+r via Plextor PX-608CU optical drive, the following error hhappens: SCSI error on write(3376,16): [5 21 02] Illegal request. Invalid address for write. Problem can be reproduced via: Brasero, k3b, xfburn, growisofs Log files: Brasero-session.log Checking session consistency (brasero_burn_check_session_consistency brasero-burn.c:1739) BraseroBurnURI called brasero_job_get_action BraseroBurnURI called brasero_job_get_action BraseroBurnURI called brasero_job_set_output_size_for_current_track BraseroBurnURI stopping BraseroBurnURI called brasero_job_get_action BraseroBurnURI called brasero_job_get_session_output_size BraseroBurnURI output set (IMAGE) image = /tmp/brasero_tmp_SSYU0X.bin toc = none BraseroBurnURI called brasero_job_get_session_output_size BraseroBurnURI called brasero_job_get_action BraseroBurnURI called brasero_job_get_current_track BraseroBurnURI no burn:// URI found BraseroBurnURI stopping BraseroLocalTrack called brasero_job_get_action BraseroLocalTrack called brasero_job_get_action BraseroLocalTrack called brasero_job_set_output_size_for_current_track BraseroLocalTrack stopping BraseroLocalTrack called brasero_job_get_action BraseroLocalTrack called brasero_job_get_session_output_size BraseroLocalTrack output set (IMAGE) image = /tmp/brasero_tmp_KOXU0X.bin toc = none BraseroLocalTrack called brasero_job_get_session_output_size BraseroLocalTrack called brasero_job_get_action BraseroLocalTrack called brasero_job_get_current_track BraseroLocalTrack no remote URIs BraseroLocalTrack stopping BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_flags BraseroChecksumImage Dummy operation, skipping BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_flags BraseroChecksumImage Dummy operation, skipping BraseroLibburn called brasero_job_get_action BraseroLibburn called brasero_job_get_action BraseroLibburn unsupported operation BraseroLibburn deactivating BraseroLibburn called brasero_job_get_action BraseroLibburn called brasero_job_get_action BraseroLibburn called brasero_job_get_device BraseroLibburn Drive (/dev/sr0) init result = 1 BraseroLibburn called brasero_job_get_flags BraseroLibburn called brasero_job_get_media BraseroLibburn called brasero_job_get_fd_in BraseroLibburn called brasero_job_get_tracks BraseroLibburn Setting multi 0 BraseroLibburn Setting burnproof 0 BraseroLibburn Setting dummy 1 BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action BraseroLibburn burn_drive_convert_fs_adr( /dev/sr0 ) BraseroLibburn Writing BraseroLibburn called brasero_job_set_dangerous BraseroLibburn called brasero_job_set_current_action BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action BraseroLibburn burn_drive_is_enumerable_adr( /dev/sr0 ) is true BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action BraseroLibburn Async START UNIT succeeded after 0.1 seconds BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action BraseroLibburn mmc_set_streaming: end_lba=2298495 , r=11080 , w=11080 BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action BraseroLibburn Allocating buffer via mmap() BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action BraseroLibburn dvd/bd Profile= 11h , obs= 32768 , obs_pad= 1 BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action BraseroLibburn DVD pre-track 01 : get_nwa(0), ret= 1 , d-nwa= 0 BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action BraseroLibburn called brasero_job_get_session_output_size
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Yes, my drive is from year 2007. It works perfectly fine under Windows, so I'm not going to replace it soon. growisofs was able to write the largest volume of data. Brasero, k3b and xfburn all failed after just some seconds. However, k3b has successfully simulated the burning. xfburn and brasero failed simulation in just few seconds. I do not remember if I plugged Plextor and Samsung drives in the same port, because Plextor uses 2 USB cables (one for power) and Samsung uses just one, but it was definitely one side of the laptop and the same usb controller. I have also found in Google that something similar users experienced in openSUSE 11.2 it was fixed after update to 11.3. However, it was few years ago with kernel 2.6.31/2.6.34. 2015-06-19 15:03 GMT+03:00 Thomas Schmitt scdbac...@gmx.net: Hi, i'm the developer of libburn which is quite orphaned in Debian, i fear. Problem can be reproduced via: Brasero, k3b, xfburn, growisofs At least growisofs does not use libburn. K3b hardly (if so, then via cdrskin replacing cdrecord/wodim). Brasero might use it, depending of compilation and configuration. xfburn surely uses libburn. So the problem is reported to the right package, although i currently doubt that it's the package's fault. SCSI error on write(3376,16): [5 21 02] Illegal request. Invalid address for write. This message looks like from libburn. It is forwarded from the drive, which is unhappy with the block write address 3376. Incompatibility with Plextor PX-608CU burner I never saw evidence that a particular DVD burner model is incompatible. There were CD drives with particular needs, back in the last century. But nowadays they all obey the command set and rules of SCSI. (Specified in the volumes SPC-3, SBC-2, and MMC-5.) Google PX-608CU tells me that it was around already in the year 2007. How old is yours ? Now let's see what is going on. BraseroLibburn dvd/bd Profile= 11h , obs= 32768 , obs_pad= 1 Brasero used libburn on a DVD-R. BraseroLibburn DVD pre-track 01 : get_nwa(0), ret= 1 , d-nwa= 0 It was blank. Write start address was 0. BraseroLibburn SCSI command 2Ah indicates host or driver error: host_status= 7h , driver_status= 0h Ouch. Linux reports a problem with transporting SCSI commands to the drive or with receiving replies. I'm not a kernel hacker so i don't have more than the SG_IO interface description: http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/x291.html SG_ERR_DID_ERROR [0x07] Internal error detected in the host adapter. This may not be fatal (and the command may have succeeded). The aic7xxx and sym53c8xx adapter drivers sometimes report this for data underruns or overruns. The mentioned hardware is antique. I'd say no USB, IDE or SATA controller is supposed to cause this error for fun. BraseroLibburn SCSI error condition on command 2Ah WRITE(10): [5 21 02] Illegal request. Invalid address for write. The failed SCSI command was indeed a write. BraseroLibburn Libburn reported an error SCSI error on write(2080,16): [5 21 02] Illegal request. Invalid address for write. So this time it happened at address 2080. sudo growisofs -speed=4 -dvd-compat -Z /dev/sr0=/media/dmitry/Partition_2/ISO_Images/Soft/myiso.iso ... 562397184/2906822656 (19.3%) @1.9x, remaining 15:50 RBU 100.0% UBU 53.1% :-( unable to WRITE@LBA=430b0h: Input/output error This time it happened much later. about 550 MB were written. Since growisofs does not report an SCSI error code triple of (SK, ASC, ASCQ), i assume that it got a transport driver error, like libburn did. The problem is not hardware-related, Well, it is reported by the kernel, which accuses the controller to have indicated an error condition. The reported SCSI error is most probably only a consequence of the communications problem between kernel and drive. DVD-R and DVD+R need to be written strictly sequentially. If transport drops a WRITE command of 16 blocks, then the next one will appear to the drive as having an address 16 blocks too high. This would cause it to throw the error [5 21 02] seen with libburn. (libburn does not go on with the drive after SG_ERR_DID_ERROR. So for this theory, the dropping of WRITE must have happened silently and the transport error only came afterwards.) I will have a look whether libburn can be changed to repeat the SCSI command when transport indicates failure. Repeating might be the trick how MS-Windows gets over the hardware connection problem. But the Linux description says: the command may have succeeded Repeating a successful WRITE command would cause error [5 21 02], too. I cannot promise a test version soon. On the first hand, transport should be flawless. As you can see, neither growisofs nor libburn are currently willing to tolerate SG_ERR_DID_ERROR.
Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner
Hi, growisofs was able to write the largest volume of data. Brasero, k3b and xfburn all failed after just some seconds. But K3b used growisofs for burning. To my personal experience with nearly failing hardware it is quite futile to search for patterns in the instability. (And i spent some time with diagnosing such situations.) However, k3b has successfully simulated the burning. This needs less electrical power than real burning. Plextor uses 2 USB cables (one for power) Do you have a dedicated power supply for it ? Something like on http://www.notebookreview.com/assets/30825.jpg If so, try whether it works better then. I have also found in Google that something similar users experienced in openSUSE 11.2 it was fixed after update to 11.3. Can you remember some URL ? Would be interesting to read if it affected DVD burning. - Whatever, as long as the system call ioctl(...,SG_IO,...) returns with indication for SG_ERR_DID_ERROR, i can hardly do anything for you. If other burn software yields significantly different results then it might be due to small differences in write parameters. E.g. whether DVD-R is written as DAO or as Incremental, or whether on DVD+R a track was reserved before writing. During data transfer both programs use WRITE(10) but might have a different rythm with inquiring the buffer fill. But on the next error prone drive, the situation can be just the other way: libburn succeeds and growisofs fails. We'd need some time to find out which difference between growisofs and libburn would cause the different performance. And only your computer system can tell. The only hint i can give now is to post a bug for the kernel, saying the component host_status of sg_io_hdr_t as defined in /usr/include/scsi/sg.h has the value of 7 after ioctl(SG_IO). (Specs: http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/x291.html) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
