Skip to contentSkip to conversation

nonzero write bulk status received: -62

DISCUSSION David Newall 2 participants 2 messages Apr 5, 2011

lore
Share & tools
lore
#0 lore raw

I'm getting the above error on a recent installation, when printing to a USB connected printer, and only the first half of the page is printed. Searching Google, I found that this is surprisingly common (I was surprised), both using usb parallel converters as well as usb-connected printers, and the only suggestion seems to be to change CUPS's device URI to parallel:/dev/usb/lpN - it's currently usb://OKI%20MICROLINE%20something. (Even though it seems somewhat bizarre, I am trying the suggestion, but haven't heard the results yet.)

From UTSLing I see that error 62 is ETIME, but finding the timer involved requires getting arms-deep into the USB code. I found no discussion on this, and wonder if I just missed it, or if there really is some issue that worth looking at. Something about extended output and ETIME makes me think it is worth looking at.

I'd appreciate pointers, either to discussions and solutions that I missed, or to places in the code where I might start looking.

Thanks.

#1 lore raw
Quoted 11 lines · David Newall

I'm getting the above error on a recent installation, when printing to a USB connected printer, and only the first half of the page is printed. Searching Google, I found that this is surprisingly common (I was surprised), both using usb parallel converters as well as usb-connected printers, and the only suggestion seems to be to change CUPS's device URI to parallel:/dev/usb/lpN - it's currently usb://OKI%20MICROLINE%20something. (Even though it seems somewhat bizarre, I am trying the suggestion, but haven't heard the results yet.)

From UTSLing I see that error 62 is ETIME, but finding the timer
involved requires getting arms-deep into the USB code.

It isn't a software timer; it is a hardware requirement. ETIME means the printer failed to acknowledge to a packet sent by the computer within the required 3-microsecond limit (or whatever the actual value is -- something like that).

Quoted 7 lines

I found no
discussion on this, and wonder if I just missed it, or if there really is some issue that worth looking at. Something about extended output and ETIME makes me think it is worth looking at.

I'd appreciate pointers, either to discussions and solutions that I missed, or to places in the code where I might start looking.

You could capture a usbmon trace. See the instructions in the kernel source file Documentation/usb/usbmon.txt.

Alan Stern