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