On Sun, 16 Jan 2005, Pete Zaitcev wrote: > On Sun, 16 Jan 2005 12:46:01 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> > wrote: > > > I have no objection to increasing the default port-reset delays. > > I do not understand what you mean by "increasing". The current code > has no post-reset delays whatsoever (on the first pass). This is > why the 10ms one which I added helps.
See below. > Why the second pass does not work with the stick is another story. > By trying to fetch the descriptor so soon we confuse the stick and > then it drops to full-speed, where a similarly unfavourable but different > sequence of events takes place (just in case you're curious). > > > Isn't this pretty much the same as what you get if you set the > > old_scheme_first module parameter? > > Yes, old scheme works. However, backoff into the old scheme does not, > and setting a module parameter is not practical for Fedora users. Also, > we build with CONFIG_USB=y. I would rather have the new scheme working > with all devices and maybe disposing of the old scheme altogether. On Sun, 16 Jan 2005, David Brownell wrote: > For what it's worth, I like the idea of avoiding all that complicated > strange-read/extra-reset logic (to figure out ep0 maxpacketsize) except > when it's absolutely necessry: only for full speed devices. > > The reason that stuff gets complicated is primarily because of hardware > that misbehaves when faced with those strange read scenarios; and the > extra reset is to recover from the misbehavior. But high speed (and low > speed) devices don't need that strange read; ep0 for those speeds only > has one value. Every device I've seen (or heard of) having those problems > is running at full speed. I tend to agree with Pete, although I would hold off on disposing of the old scheme until we're quite sure about the new one. David favors keeping the old scheme for use with low- and high-speed devices, in which case retaining it as a backup for full-speed devices wouldn't be much effort. (The only devices I can find reports of in the archives which _needed_ the new scheme were running at full speed, so this approach makes sense.) I also would like to see the backoff to the old scheme working, however it may be that when these high-speed devices change their speed they require a port-power cycle before going back to high speed. If we eliminate the new scheme for high-speed devices this becomes a moot point. For now let's not worry about it. On Sun, 16 Jan 2005, Pete Zaitcev wrote: > > I have no objection to increasing the default port-reset delays. And > > refactoring the code to split out the portion of hub_port_init that > > determines ep0maxpacket is a good idea, so long as the functionality > > doesn't change. Would you like me to write a patch against the current > > tree to do those things? > > I was going to do all the work of re-diffing against the BK head and > re-merging as long as you approve, however, the functionality does not > stay the same on purpose. My idea was that fetching the descriptor before > setting the address makes no sense for high-speed devices, and so I threw > that away. > > You indicated before that Windows does both it and the second port reset. > Is it actually the case? Yes. If you're interested you can view a sample USB trace that Andries Brouwer is kindly hosting for me at http://www.win.tue.nl/~aeb/linux/usb/traces/winxp/bbb-06.log You'll have to decode the packet dumps yourself, but its not hard to see the wLength value of the first Setup packet (last two bytes) and the port reset that follows the reply. The trace doesn't include the speed of the connection unfortunately, but you can deduce it by decoding the maxpacket values for the two bulk endpoints in the Get Configuration reply data (512 bytes => high speed). > > The descriptor fetch doesn't occur immediately after the port reset; > > there's a delay in between (see hub_port_wait_reset). What happens if you > > increase HUB_SHORT_RESET_TIME and HUB_ROOT_RESET_TIME each by 10 ms > > instead of adding the extra msleep? > > This is an important point which I did not see or answer, due to some > confusion locally. I'm sorry. > > Yes, we wait for the reset between setting the reset state (port feature), > and clearing it, thus enabling the device for normal operations. However, > there is no delay of any sort after clear_port_feature() call. In no way > changing parameters alters this situation. You're right and I was wrong about this. My preference goes towards adding the delay directly in hub_port_reset, in the case 0: part of the switch(status) statement. That way there's no question about it applying after _every_ reset. On Sun, 16 Jan 2005, Steve Calfee wrote: > Hi Alan, I am finally getting my Linux compatible hardware USB analyzer > finished. I have posted two traces on my web site which may help (go to > the very end of the page for samples). What's the URL? > The shorter, easier to understand one is win98SE enumerating a VERY SLOW > ZOOM ACM modem. The longer one is winXP enumerating the same modem. I > did not filter out the huge number of NAKs issued by the device so you > saw a pure view of the process. Every SOF is shown in the displays. The > SETUP commands are not decoded in these traces) Bus reset on both is > more then 10ms and less than 20ms of SEO. You can count the number of > frames after detection by counting the number of SOFs after device > detection (The start of the trace win98=138 frames winXP=28 frames). You > can count the number of ms after reset by counting the SOF after the SEO > reset device 0 and got ready to set an address (win98=44 frames winXP=17 > frames). Based on these figures, it sounds like a 20 ms delay might be good. According to sections 7.1.7.5 of the USB 2.0 spec, devices must be able to accept a Set Address request 10 ms (Trstrcy) after the reset signal is ended, so using 20 ms should provide a little extra breathing space. To sum up: Pete, please feel free to update your patch against the current tree. I'll review it, but unless something totally unexpected comes up I expect to approve it. And as long as you're removing the new scheme processing for high-speed devices, you could consider removing it for low-speed devices also. Alan Stern ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
