Remark: For this bug there is a patch already in -mm and -grekh trees. This bug report works as a reminder. Most recent kernel where this bug did *NOT* occur: unknown Distribution: gentoo with gentoo-sources / vanilla kernel Hardware Environment: x86 (Athlon XP 2400+), NEC USB Card (1033:0035), Kyocera Mita FS 820 Software Environment: gentoo linux (i686), udev 103, cups 1.2.6 / 1.2.7 Problem Description: since cups 1.2, cups requests the printer ID before adding a printer and before each print job. The Kyocera FS 820 seems to have a problem with ID requests - it does not answer the request unless there has been communication just before (e.g. plugging in) Symptoms: strace output: /usr/libexec/cups/backend # strace -e raw=ioctl /usr/libexec/cups/backend/usb [...] open("/dev/usb/lp0", O_RDWR|O_EXCL|O_LARGEFILE) = 3 ioctl(0x3, 0x84005001, 0xbfc397b1) = -1 (errno 5) close(3) = 0 [...] usbmon log: de8fbac0 2123539163 S Bi:003:02 -115 8192 < ddba3860 2123539196 S Ci:003:00 s a1 00 0000 0000 03ff 1023 < ddba3860 2128538251 C Ci:003:00 -104 0 de8fbac0 2128539243 C Bi:003:02 -2 0 links: lkml: http://lkml.org/lkml/2006/12/22/62 lkml: http://lkml.org/lkml/2006/12/28/163 private homepage: http://www.zut.de/kyocerafs820.html possibly related: http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg39521.html patch that fixes mentined behaviour: To get the printer working, it can be added to the list of "quirky printers" in usblp.c: --- a/drivers/usb/class/usblp.c +++ b/drivers/usb/class/usblp.c @@ -217,6 +217,7 @@ static const struct quirk_printer_struct quirk_printers[] = {
Hmm, I didn't realise this patch was already merged. To me it seems like the wrong approach, since the USB read *does* succeed a lot of the time. Instead we should at least identify the problem before accepting a workaround...
Any updates on this problem? Thanks.
Fix made it into mainline, works at least for me, heard no other comments about it.