Control: tags -1 + patch upstream
Hi again,
Am Donnerstag, den 09.07.2015, 16:53 +0200 schrieb Fabian Greffrath:
> Thus, I assume that the following patch might work, but i am not sure
> yet, because, you know, it only happens "sometimes". ;)
now I have proof that it works!
My printing was hanging again today, with the "usb" process eating up
100% CPU. It's process ID was 24901 and so I attached GDB to it. Look
what happened:
$ sudo gdb /usr/lib/cups/backend-available/usb --pid 24901
[...]
(gdb) bt
#0 0x00007f7884939c17 in ioctl () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f78850ad4d1 in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#2 0x00007f78850a7950 in libusb_claim_interface () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#3 0x00007f78854e0ee8 in open_device (printer=0x7f78856e51c0 <printer>, verbose=1)
at usb-libusb.c:1515
#4 find_device (cb=0x7f78854e0900 <print_cb>, data=0x7f7885e3c630) at usb-libusb.c:942
#5 0x00007f78854e1a98 in print_device (uri=0x7f7885e3c630 "usb://Kyocera/FS-1120D?serial=Q5Y1358476",
hostname=<optimized out>, resource=<optimized out>, options=<optimized out>, print_fd=0, copies=1,
argc=6, argv=0x7ffd7b31d838) at usb-libusb.c:220
#6 0x00007f78854df603 in main (argc=6, argv=0x7ffd7b31d838) at usb.c:248
(gdb) frame 3
#3 0x00007f78854e0ee8 in open_device (printer=0x7f78856e51c0 <printer>, verbose=1)
at usb-libusb.c:1515
1515 usb-libusb.c: Datei oder Verzeichnis nicht gefunden.
So, it was hanging in line 1515 of usb-libusb.c, just as I suspected.
(gdb) p printer
$1 = (usb_printer_t *) 0x7f78856e51c0 <printer>
(gdb) p *printer
$2 = {device = 0x7f7885e3fde0, conf = 0, origconf = 0, iface = 0, altset = 0, write_endp = 0,
read_endp = 1, protocol = 2, usblp_attached = 0, reset_after_job = 0, quirks = 0,
handle = 0x7f7885e43f00}
This was just a test to see if the struct was still intact, all looked good.
(gdb) p libusb_detach_kernel_driver(printer->handle, printer->iface)libusb_claim_interface
$3 = 0
(gdb) c
Continuing.
And indeed, it broke the loop and printing continued! So, it makes
sense to check if the error code of libusb_claim_interface() is indeed
LIBUSB_ERROR_BUSY and add another call to libusb_detach_kernel_driver()
if it is. I have no idea, though, why it is possible that the device is
reported busy at this stage, as it is already checked earlier in the
code and clearly *shouldn't* be at this point, but apparently it is
possible and calling libusb_detach_kernel_driver() again is a means to
fix this.
Could you please take this upstream?
Thank you very much!
Cheers,
Fabian
Attachment:
signature.asc
Description: This is a digitally signed message part