Hi,
out of a sudden (ok, I had updated the notebook from Debian stable to Debian
testing) my usb-Parport adapter stopped working and still does not send data to
the printer, even on other stable installations, even using another adapter,
even using a different printer.
During the research I found that CUPS is not to blame, usblp gets the data via
the usb backend and then nothing really useful happens.
I'm of course interested in finding a solution for the problem but while
looking into the sources I found some time I doubt whether they are the way
they should be.
The kernel is 2.6.17.6 and was so before the upgrade, so this is a "should not
happen" for me.
The adapter is identified by lsusb as follows:
| Bus 001 Device 005: ID 067b:2305 Prolific Technology, Inc. PL2305 Parallel
Port
A sample usbmon output, the command for that was a
"cat print.data >/dev/usb/lp0":
| c366dd40 3767889620 S Bi:005:02 -115 8192 <
| c3a567a0 3767897983 S Bo:005:01 -115 4096 = 1b451b26 6c36441b 266b3132
481b266c 304f1b26 6c323641 1b266c37 30501b26
| c366d260 3787895733 S Ci:005:00 s a1 01 0000 0000 0001 1 <
| c366d260 3787896664 C Ci:005:00 0 1 = 18
| c366dda0 3807896961 S Ci:005:00 s a1 01 0000 0000 0001 1 <
| c366dda0 3807898424 C Ci:005:00 0 1 = 18
The last two lines repeat every twenty seconds corresponding to
USBLP_WRITE_TIMEOUT (see below on timeout times). With DEBUG enabled these
control packets are also in the kernel log file:
| kernel: drivers/usb/class/usblp.c: usblp_control_msg: rq: 0x01 dir: 1 recip:
1 value: 0 idx: 0 len: 0x1 result: 1
This means the adapter isn't entirely dead but somehow it could not deal with
the bulk transfer. All further enquiries e.g. using CUPS's
/usr/lib/cups/backend-available/usb return errors like in
| open("/dev/usb/lp0", O_RDWR|O_EXCL) = 3
| ioctl(3, SNDCTL_DSP_SYNC, 0xbff088b0) = -1 EIO (Input/output error)
To reset the adapter I need to unplug it on the usb side.
Adding the device to the quirk_printers table didn't help. I've also reduced
USBLP_BUF_SIZE to 1024 and even 512 but no avail.
Now finally I'm out of ideas what to do next. Any suggestions?
Looking into the kernel sources: The first thing that confuses me the
write timeout handling in usblp_write l.642
| if (!usblp->wcomplete) {
| barrier();
(...)
| timeout = USBLP_WRITE_TIMEOUT;
|
| rv = wait_event_interruptible_timeout(usblp->wait,
usblp->wcomplete || !usblp->present , timeout);
| if (rv < 0)
| return writecount ? writecount : -EINTR;
| }
which means: If the already submitted urb is not yet processed, wait for the
timeout, and unless the operation was interrupted, proceed as if the operation
is completed. In other words, in my situation the main loop is never left. Is
this by intention?
Personally I'd insert a check against timeout, something like:
| if (rv == 0) {
| err("usblp%d: timeout writing to printer",
usblp->minor);
| return -EFAULT;
| }
to put an end to that. Perhaps with some other actions like device reset.
Regarding the TIMEOUT value:
The timeout definition is obviously in milliseconds:
| #define USBLP_WRITE_TIMEOUT (5000) /* 5 seconds */
while the usage of wait_event_interruptible_timeout at l.652
| timeout = USBLP_WRITE_TIMEOUT;
| rv = wait_event_interruptible_timeout( (...) , timeout);
is jiffies according to include/linux/wait.h. This causes different timeout
values depending on HZ which is probably not intended.
Easy Solution:
+ timeout = USBLP_WRITE_TIMEOUT * HZ/1000;
Christoph
(off-list Cc: welcome)
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
