Red Hat Bugzilla – Bug 102069
HP LaserJet 1300 gets fatal error when cups is restarted
Last modified: 2007-11-30 17:06:57 EST
Description of problem: Taroon beta 1 up2date as of Aug 9, 2003 I can configure the printer (an HP LaserJet 1300, connected via USB) and can print successfully. After printing, however, the light on the printer keeps blinking, indicating that it is still awaiting transmission of data. (Checking/unchecking the "End of transmission" option fails to change this behavior. With Red Hat Linux 7.3 and LPRng, checking this option did in fact cause the blinking transmission light to end after a job was printed. Documentation seems to suggest that this option is meaningless with cups, which now that it is the only printing option, means that this option should probably not be present). After printing a job, and after some period of time (a few minutes), the printer decides that the transmission has completed--it then stops blinking the data transmission light and appears to return to normal. This is where the main problem begins. At this point, after the data transmission light on the printer stops blinking, if cups is restarted, then the printer gets a fatal error (all lights on the printer go on, indicating this error). The printer must be physically powered off and on again to reset this. When this happens dmesg prints out the following message: usb_control/bulk_msg: timeout Note that if cups is restarted after the job is printed but while the data transmission light on the printer is still blinking, this fatal error does not occur. When printing with LPRng under Red Hat Linux 7.3 I never got a fatal error on the printer. I've noticed that the fatal error also occurs under Red Hat Linux 9 with cups. Version-Release number of selected component (if applicable): cups-1.1.17-13.3.4 How reproducible: 100%
I change the printer connection from USB to parallel. This appears to resolve the fatal error on the printer issue (although the data transmission light continues to blink after the job is done, as before). My guess is that the problem is specific to USB-connected printers.
Could it be a kernel issue?
I too have this problem. Since install RH9 (from rh8) may laserjet 1300 crashes on boot. The only way to get it working is to power cycle it. It also seems to crash randomly around once per day as well. I get the following boot log messages (via dmesg): hub.c: new USB device 00:10.0-1, assigned address 2 usb.c: USB device 2 (vend/prod 0x3f0/0x1017) is not claimed by any active driver . hub.c: new USB device 00:10.0-2, assigned address 3 usb.c: USB device 3 (vend/prod 0x46d/0x8b2) is not claimed by any active driver. usb.c: registered new driver usblp printer.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 1 proto 2 vid 0x03F0 pid 0x1017 printer.c: v0.11: USB Printer Device Class driver usb-uhci.c: ENXIO 80000380, flags 0, urb c3dd7f40, burb c3dd79c0 usbdevfs: USBDEVFS_CONTROL failed dev 3 rqt 128 rq 6 len 9 ret -6 usb-uhci.c: ENXIO 80000380, flags 0, urb c3dd7f40, burb c3dd79c0 usbdevfs: USBDEVFS_CONTROL failed dev 3 rqt 128 rq 6 len 18 ret -6 usb-uhci.c: ENXIO 80000380, flags 0, urb c3dd7f40, burb c3dd79c0 usbdevfs: USBDEVFS_CONTROL failed dev 3 rqt 128 rq 6 len 18 ret -6 usb-uhci.c: ENXIO 80000380, flags 0, urb c3dd7f40, burb c3dd79c0 usbdevfs: USBDEVFS_CONTROL failed dev 3 rqt 128 rq 6 len 18 ret -6 usb-uhci.c: ENXIO 80000380, flags 0, urb c3dd7f40, burb c3dd79c0 usbdevfs: USBDEVFS_CONTROL failed dev 3 rqt 128 rq 6 len 18 ret -6 usb-uhci.c: ENXIO 80000380, flags 0, urb c3dd7f40, burb c3dd79c0 usbdevfs: USBDEVFS_CONTROL failed dev 3 rqt 128 rq 6 len 18 ret -6 AND... if I leave the printer long enough (a very long time) it prints a page detailing some error (but I can't remember now what it says - sorry). I have configured my printer as a lj1200 (since there is no lj1300 driver), this doesn't appear to be the problem (it is just a postscript problem), it appears to me that it is in the USB layer not in CUPS. If you get a work around please drop a line to no_spam at ntlworld dot com. Thanks SA ps I have noticed some errors in the file /usr/share/hwdata/usb.ids which give rise to the following errors ritalin:76 /sbin/lsusb Unknown line at line 58 Unknown line at line 2296 ... these are mainly simple formating errors - an updated file would be handy.
If the printer is left for long enough after a crash (and I mean along time > hour) it produces a single page with the line: Unsupported Personality: UNKNOWN and then resets itself.
I have updated hpoj and printer.c according to hpoj.sf.net/download/linux-usb-printer/ but this does not make any difference - the printer still crashes at boot and I still get the above messages and "usb_control/bulk_msg timeout". Is there any activity on this report?
SA: this bugreport is against the RHEL beta release and is viewed and prioritized im that context.
I backported the new 2.6 printer to Fedora, it's available for testing in people.redhat.com:/zaitcev/tmp/*-2.4.22-1.2121.2.1.nptl* However, it was done for other bug, with oopses. I have no idea if it fixes this one. Worth trying nonetheless. Fedora kernels are roughly compatible with RHL9, might only need a little help with rpm -i --force.
Sorry for not updating this earlier. RHEL 3 (final bits) don't seem to have this issue. I'm not sure about RHL 9, I no longer use it.
The 1300 in particular is known to be problematic. Several people reported difficulties with hpoj and 1300 under generic kernels, including the 2.6. I'm sure we'll hear about it yet, but let us close this for now. Allstair will need to open new ones.
This is still current with kernel 2.4.20-28.9 SA
Created attachment 98636 [details] Aaron Lehman mail w/ patch
I what Aaron says is right, it's no wonder I was unable to do anything about it for so long. I'll consider adding the quirk it his approach is confirmed.
This problem is still current with the fedora 2 kernel and packages: uname -a Linux ritalin 2.6.6-1.427.8kstacks-LJ #3 Thu Jul 15 13:09:32 BST 2004 i686 athlon i386 GNU/Linux Basically 2/3 times the printer crashes on boot up and also has a 1 in 40 ish chance per hour of crashing. This has been true for all stock kernels I have used since RH 8.0. SA
Closing for Chris. SA, file a new bug against 2.6 if you have a problem.