On Fri, 11 Nov 2005, Neil Brown wrote: > 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.
Hmmm, could be. > > 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? The error counter is not related. NAK doesn't decrement it and the driver doesn't reset it. > > > 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 have a relatively inexpensive analyzer that you could borrow if it turns out to be necessary. > 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. >From my meager knowledge of how usblp works, this is more likely to be a single input request that is made up of many individual packets. Not a bunch of input requests. In the debugging file each request shows up as a QH whereas each packet shows up as a TD. > 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. Call them packets, not requests. A request, or URB, corresponds to multiple packets. (Even that's not quite right. The technical term is "transaction", but "packet" is close engouh.) > 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. That's quite possible. > 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? I don't know how the usb-uhci driver works. It's very different from uhci-hcd. > 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. Good luck, Alan Stern ------------------------------------------------------- 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
