On Thursday November 10, [EMAIL PROTECTED] wrote: > On Thu, 10 Nov 2005, Neil Brown wrote: > > > It cannot be a page-feed thing, as the file is one page, and the page > > doesn't come out until after the 'dd' completes. > > Then do you have any idea what the 20-second delay could be? Does the > printer have to warm up?
There seems to be this random 0, 100, or 200 millisec delay added to each 64byte packet. An 8K block has 128 64byte packets, so this could mean an 8K block has between 0 and 25600 millisec delay - which is up to 25 seconds. That's my current guess. > > If you have NO_FSBR set, that's correct. If you don't have NO_FSBR set, > the controller resends the packet more or less continually until it > receives an ACK. Ok, that's starting to make sense... Among the holes still in my understanding is how the 2 bit error count in the TD header relates to this. Does a NACK not decrement this counter, or does the HCD driver reset it regularly? > > > If what, what would be the easiest way to instrument the kernel to > > confirm that a packet really was going every msec? > > This information is not available to the kernel. You would need to get a > USB protocol analyzer, a hardware device that monitors the signals on the > USB cable. and I don't suppose USB protocol analyzers are particularly cheap....:-) I'm fairly certain the printer is doing something very silly, but I'm still hopeful that there is some way to change how linux talks to it to get it to avoid at least most of the silliness. This hope is based on the fact that 2.4 drives the printer about 5 times as fast as 2.6, and Windows doesn't seem to have problems at all (though my testing there is quite limited). I noticed during my explorations of /sys/kernel/debug/uhci/* that there a bunch of queued 'input' requests which repeatedly received a 'NAK' as the printer has nothing to say. I assume that with FSBR and a constant stream of output packets, the printer will be seeing an steady stream of Input requests, which it NAKs, and Output Requests which is *should* ACK. My current theory (which I'll try to test this evening) is that the Input requests are confusing the printer. When it gets one, it goes into some sort of reset mode for 100ms during which every request is NAKed. When it comes out of this mode, if the next request is Input, it goes to sleep again. If the next request is Output, it handles it, but then gets an Input and dies again. I'm not sure that this completely explains the symptoms, but it comes close. The extra speed in 2.4 could be caused by the HCD setting up a depth-first series of TDs that is 5 deep. Is that at all possible? If this is true, or even close, then getting rid of the Input requests should fix that.... I just had a quick look at usblp, and there seems to be QUIRK handling for precisely this case. I just set USBLP_QUIRK_BIDIR (like lots of other HP printers need!!) and the problem goes away (?). I'll let you know how it goes. Thanks again NeilBrown ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
