2011-04-05 08:21:20

by David Newall

[permalink] [raw]
Subject: nonzero write bulk status received: -62

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.


2011-04-05 14:13:00

by Alan Stern

[permalink] [raw]
Subject: Re: nonzero write bulk status received: -62

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