Bug 26909 - USB printer.c read and poll bugs (and patch)
USB printer.c read and poll bugs (and patch)
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
http://www.geocrawler.com/lists/3/Sou...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-09 21:33 EST by David Paschal
Modified: 2007-04-18 12:31 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-13 18:58:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Paschal 2001-02-09 21:33:25 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.2.18-dsp1 i686)


The biggest problem was that after I successfully read an MLC/1284.4 packet
     on a 7/1/3 interface, every subsequent read would return garbage (but
in the
     exact amount requested).  The problem was that when
     usb_submit_urb(&usblp->readurb) was called in usblp_read(), it failed
to zero
     out usblp->readcount the way it did in usblp_open().

     The second problem was that selecting for a read never triggered when
data
     had been received, because the check for usblp->bidir in usblp_poll()
was
     inverted.

I submitted a patch against 2.2.18 to the linux-usb-devel mailing list
(http://www.geocrawler.com/lists/3/SourceForge/2571/0/5123030/).  Looking
at drivers/usb/printer.c in 2.4.x in Fisher, the read bug is partially
fixed, and the poll bug is not fixed.  Hopefully somebody on
linux-usb-devel will ensure that these fixes get incorporated into 2.2.19
and 2.4.2, but I'm submitting this bug report against Fisher so it will get
tracked.

Reproducible: Always
Steps to Reproduce:
Problem #1 (read):

Connect USB HP OfficeJet G series, K series, or LaserJet 3200.
fd=open("/dev/usb/lp0",O_RDWR);
write(fd,"\0\0\0\8\1\0\0\x20",8); // Send 1284.4 Init packet.
read(fd,buffer,6); // Receive 1284.4 header.
read(fd,buffer+6,3); // Receive data portion of 1284.4 InitReply.
Everything works fine so far.

read(fd,buffer,6); // Receive next 1284.4 header.
This and every subsequent read() returns garbage data in the exact amount
requested, because the readcount variable is not zeroed out when submitting
another readurb.

Problem #2 (poll/select):

fd_set rset;
FD_ZERO(&rset);
FD_SET(fd,&rset);
select(fd+1,&rset,0,0,0);
Never returns even when bulk IN data is available, due to an inverted test
for bidirectionality in usblp_poll().
Comment 1 Glen Foster 2001-02-12 18:14:04 EST
We (Red Hat) should really try to resolve this before next release.
Comment 2 Arjan van de Ven 2001-02-14 15:45:26 EST
Thanks for the report. Patch is applied and will be included in the
next kernelbuild in Rawhide.

Note You need to log in before you can comment on or make changes to this bug.