On Mon, 2005-11-21 at 17:20 -0500, Alan Stern wrote:
> On Mon, 21 Nov 2005, Steve Bangert wrote:
> 
> > > daa3b200 5540696 S Bi:006:02 -115 8192 <
> > > d357fb00 5540774 S Ci:006:00 s a1 01 0000 0000 0001 1 <
> > > daa3b200 5541970 C Bi:006:02 0 0
> > > d357fb00 5541975 C Ci:006:00 0 1 = 18
> > > 
> > > That shows the driver trying to read status data from the printer and
> > > getting back 0 bytes, and it also shows a control message of the same sort
> > > as in your system log:
> > > 
> > > drivers/usb/class/usblp.c: usblp_control_msg: rq: 0x01 dir: 1 recip: 1 
> > > value: 0 idx: 0 len: 0x1 result: 1
> > > 
> > > This is another status request, and the status value was 0x18.  If I'm
> > > reading the source code correctly, that means the printer was out of
> > > paper. It should have shown up in the system log as an "out of paper"
> > > message.  Are you sure nothing like that appeared in the log at the time
> > > you started the write?  Assuming the printer wasn't really out of paper,
> > 
> > Nope, never seen an out of paper message in the system log and there's
> > plenty of paper in the printer, i think your on the right track though,
> > good work.
> 
> Whoops, my mistake.  I did misread the source code.  0x18 indicates no 
> errors, not out of paper.
> 
> > > maybe this indicates there's something wrong with its paper-level sensor.
> > > 
> > > Have you tried attaching the printer to a different computer or using a 
> > > different operating system?
> > 
> > yes, works fine in XP
> > This may be hopelessly naive but is it possible to "comment out" the out
> > of paper code in usblp.c as a test and see if that helps?
> 
> Yes, but it won't help.  First because the situation isn't arising, and 
> second because the driver won't pay attention to an "out of paper" status 
> unless the printer starts rejecting data.
> 
> The log showed no errors, no reason for the printer not to work.  However
> it's possible that not all your data was sent to the printer.  The log
> only shows what did get sent; if more data was waiting we wouldn't be
> aware of it.
> 
> Can you get into a similar situation, where the printer doesn't operate,
> and send it a very short file (no more than 32 bytes, just a single line
> of text)?  Try sending the file twice in a row, and record the usbmon log
> the whole time.

I made two text files, one file had 8 one's in it and the other has 16
one's in it, i sent those files to the printer device node one after the
other while recording a usbmon trace, the printer _didn't_ print a
single character, and nothing was printed to the system log, here's the
usbmon trace:

ddb97300 1765765675 S Bi:003:02 -115 8192 <
ddb97800 1765766313 S Bo:003:01 -115 9 = 31313131 31313131 0a
ddb97300 1765767176 C Bi:003:02 0 0
ddb97800 1765767181 C Bo:003:01 0 9 >
ddb97300 1787606680 S Bi:003:02 -115 8192 <
ddb97800 1787607293 S Bo:003:01 -115 17 = 31313131 31313131 31313131
31313131 0a
ddb97300 1787608643 C Bi:003:02 0 0
ddb97800 1787608648 C Bo:003:01 0 17 >
 
> 
> Also, it would help a little bit if you unplug all the other USB devices 
> on your system, or as many as possible.  Their data gets intermingled with 
> the printer data in the log.
Done.
> 
> Alan Stern
> 
Steve



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to