As reported and investigated by Tuomas Jäntti downstream at
https://bugs.gentoo.org/show_bug.cgi?id=251237, I will summarize here:
A change introduced somewhere between 2.6.21 and 2.6.24 resulted in
breakage when using usblp with a Canon BJC-3000. After printing one
page, the next job will hang indefinitely. Running "lsusb" resumes printing.
Old usblp.c code used to have a timeout in usblp_write(), and when that
timeout was hit, usblp_check_status() was called, causing a
GET_PORT_STATUS class request on the control pipe. You can see this in
this usbmon log:
https://bugs.gentoo.org/attachment.cgi?id=176041&action=view
c1700b40 2047655126 S Bo:003:01 -115 8192 = 1b5b4b02 00000f1b 28610100
011b2862 0100011b 28710100 011b2864 04000168
d3897d40 2067642143 S Ci:003:00 s a1 01 0000 0000 0001 1 <
d3897d40 2067643995 C Ci:003:00 0 1 = 18
c1700b40 2067702966 C Bo:003:01 0 8192 >
Note the 20 second (5000 jiffies @ 250hz) delay between the first and
second lines that I pasted, and how that the bulk transfers start moving
again once that control request completes. (The 20 second printing delay
was noticeable, but at least printing happened after a pause).
In other words, this printer relies on constant prodding on the control
pipe, otherwise bulk transfers stop completing. "lsusb" is enough, as is
the USB printer class GET_PORT_STATUS above. Logs sniffed from Windows
vista show that windows is polling on the control pipe every second as
well. https://bugs.gentoo.org/attachment.cgi?id=177145&action=view
Sometime after 2.6.20, Linux's "GET_PORT_STATUS on bulk timeout"
behaviour went away (the code is now more selective as to when it
performs that status check), resulting in printing halting unless the
control pipe is prodded through another means (e.g. lsusb).
Any ideas on how and where we can work around the misbehaviour of this
printer? One idea I have is to add a new quirk type in usblp.c, which
will cause a GET_PORT_STATUS request to be sent off every second
(asynchronously, where the callback uses queue_delayed_work() to
schedule the next prod). This cycle will run starting from usblp_open()
until usblp_close() is called.
Any thoughts?
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
