Bug#929685:

2022-08-18 Thread Дмитрий Нестеркин
Debian 11.4 with all updates

# apt-get install openjdk-11-jdk-headless
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 openjdk-11-jre-headless : Depends: ca-certificates-java (>= 20190405~) but
it is not installable
   Depends: java-common (>= 0.28) but it is not
installable
E: Unable to correct problems, you have held broken packages.

# cat /etc/debian_version
11.4

-- 
Best regards,
Dmitriy Nesterkin


Bug#789260: libburn4: Incompatibility with Plextor PX-608CU burner

2015-06-25 Thread Дмитрий Нестеркин
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

2015-06-25 Thread Дмитрий Нестеркин
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

2015-06-25 Thread Дмитрий Нестеркин
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

2015-06-25 Thread Дмитрий Нестеркин
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

2015-06-23 Thread Дмитрий Нестеркин
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

2015-06-23 Thread Дмитрий Нестеркин
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

2015-06-23 Thread Дмитрий Нестеркин
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

2015-06-22 Thread Дмитрий Нестеркин
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

2015-06-22 Thread Дмитрий Нестеркин
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

2015-06-22 Thread Дмитрий Нестеркин
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

2015-06-19 Thread Дмитрий Нестеркин
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

2015-06-19 Thread Дмитрий Нестеркин
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.