On Tue, 2006-01-03 at 12:32 -0800, Alan Stern wrote: > On Tue, 27 Dec 2005, Steve Calfee wrote: > > > From the Kitty USB Analyzer: > > frame # 810 f=12001 sync 30772 SOF(xa5) frame 810 crc5 0x5 f=0 > > > > frame # 811 f=12002 sync 30780 SOF(xa5) frame 811 crc5 0x1a f=0 > > > > frame # 812 f=12002 sync 30788 SOF(xa5) frame 812 crc5 0x15 f=0 > > > > frame # 813 f=12002 sync 30796 SOF(xa5) frame 813 crc5 0xa f=0 > > BUS timeout 100ms SE0 30804 > > BUS timeout 100ms SE0 30806 > > BUS timeout 100ms SE0 30808 > > BUS timeout 100ms SE0 30810 > > BUS timeout 100ms SE0 30812 > > BUS timeout 100ms SE0 30814 > > > > And so on forever.... > > > > These results are from my "WinXP Home" laptop of a full speed USB flash > > drive. I pushed the "safely remove hardware" button, while tracing the bus. > > The button appears in that tray on the bottom by the clock. > > > > SE0 is when both D+ and D- are low which in differential signalling means > > single ended zero. So on my root hub ohci port, Windows is putting the > > device in reset. My volt/Ohm meter says there is still +5, which I guess is > > so a removal and reattach would be detected? > > > > When the eject button is pressed (from Windows exploder), it does something > > different! It appears windows just quits talking to the device. (I presume > > it flushes any unwritten data first, but I havent caught that, because > > windows treats USB flash a a removable device and doesn't cache unwritten > > sectors.) > > > > This means that the eject command, while connected to the ohci root hub, > > the > > SOFs keep going out on the lines to the flash device, but windows stops > > talking to it. > > > > HTH - Regards Steve > > I tried a similar experiment using Windows 2000 and a USB flash storage > device attached through an external hub. When I pressed the "safely > remove hardware" button, Windows sent two TEST UNIT READY commands to the > storage device and then sent ClearPortFeature(PORT_ENABLE) to the hub. >
Yes, I would expect that. > No reset or any further commands were sent to the hub. So even though I > wasn't monitoring the cable segment between the hub and the device, we can > deduce that there wasn't a reset signal (SE0) present. > Well, what is the difference between reset and a disabled port? In the USB 2.0 spec section 11.5 there is a state chart for hubs. It defines disabled as "Disabled: Port Cannot propagate any traffic. All ports are HiZ". So when the port is disabled, the device must go into suspend within <2ms if there is no signalling. So it must be removing its 1.5K pullup resistor while suspended. The host's/port's pulldown 15K resistors then pull the bus to SE0, even if it is not actively driven. The Kitty USB Analyzer just samples the bus, and reads its D+,D- values. It is not possible to determine if low on both lines is actively driven or passively pulled down by the 15K resistors. So it senses SE0 which is the same signal state as reset. > I haven't tried doing the same experiment with the device attached > directly to the computer, but it would be surprising to see a port reset > under these circumstances. When the reset completed the port would then > be enabled, with the device at address 0 -- something you don't want to > have happen for any length of time. Windows would then have to disable > the port in any case... so why bother with the reset? > I think I (in my earlier post) and maybe you have confused reset with SE0. The difference is reset is DRIVEN by the port. In order to detect a future connect, the bus needs to sit in the passive SE0 state waiting for a device to pullup its "FULL/LOW speed" indicator line. > I also haven't tried using the eject button. Very strange that it should > not do the same thing as the "safely remove hardware" button. If you > press eject and then unplug the device, does Windows give you a warning > about unsafe device removal? No, but then it doesn't warn or scold if you just pull out the device either. "WinXP Home" is what I am testing with. Maybe eject has to leave the device unsuspended so some external mechanical media eject mechanism can still be run. Who knows? Regards, Steve ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&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
