nonzero write bulk status received: -62

nonzero write bulk status received: -62

[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.  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.

Re: nonzero write bulk status received: -62

[Alan Stern]

On Tue, 5 Apr 2011, David Newall wrote:

> 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).

>  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