Comment 39 for bug 997040

Adding tasks for kernel and libusb 1.0.x ...

To the developers and packagers of kernel and libusb, the CUPS printing backend (source code attached) accesses printers with libusb 1.0.x. To be able to access in all situations, it detaches the kernel module from the printer right after libusb_open() (function open_device() in attached source file) and re-attaches it right before libusb_close() (function close_device() in attached file). Only after detaching the module it switches to the needed configuration (if needed), clkaims the interface, and selects the alt setting (function open_device()). Then it reqyests the device ID to check whether the desired printer is selected and after that does the I/O, taking into account if the interface's protocol is 1 or if there is no read endpoint that no read thread is started. After that the interface is released, the configuration is restored if it was switched in the beginning and the usblp module re-attached.

Printers are assigned to the print queues by their make/model/serial number in CUPS and to select the correct USB device the function find_device() in the attached file walks through all devices and searches for interfaces of class 7 and subclass 1 and requests the device ID from this one. It stops if the ID matches and send the job to this device.

If the usblp module is not loaded (blacklisted) all works fine. The detaching and re-attaching does not happen but all the rest is done as described. In this situation one can send arbitrarily many print jobs and they all get perfectly printed.

The problem comes when the usblp module is present. Only the walk through the devices to find the correct printer still works, so the method described above works perfectly if one opens the devices only for requesting the device ID. But if one does real I/O (sending a job) this works several times and then suddenly the I/O is not accepted any more. Right after reading the device ID, when starting to send data to (and request data from) the device, the device does not react and the I/O functions of libusb report a timeout. This is independent of whether one does bi-directional I/O (sending the job data and also reading what comes back from the printer) or uni-directional I/O (only sending data, no back channel).

You can see the timeout messages in the last two attached error_log files in the last job in each file. The timeout is always exactly 1 minute after trying to write data to or read data from the device.

Please ask the original poster of the bug for more information if needed.

bug 995111 is most probably the same problem, please also contact the poster of that bug.