On Fri, 8 Nov 2002, Johannes Erdfelt wrote: > But the hub is what is disconnecting the port. What hub are you using?
Hm, IMHO the hub doesn't disconnect (how would it?) it merely reports the device gets disconnected. Sure, it's minor nitpicking, but IMHO important for understanding the problem. The point is the difference between a device being plugged (i.e. appears physically attached to the port) and the port _detecting_ the plugged device and thus reporting a connection. Basically, device detection happens due to some resistor in the device which pulls one of the data lines to a certain voltage level. This voltage is derived from the bus power. Particularly when a buspowered device gets attached the hub's downstream port has to drive considerable power to the device while the electrical contacts are still bouncing (and the device is probably just charging some large capacitors). Therefore it's completely _expected behavior_ for the downstream port to see the pullup resistor applyied and disappearing several times. Depending when we ask the hub for the port state we'll see it either connected or not. The whole point of the debounce delay is to ensure there was some interval without any transient connection state change. That's why it would be important to know whether the debounce-failure is due to some error when reading the portstatus or if we are really leaving there after 400ms without transient connection change but finally seeing no connection there. And if a further increase of the delay helps. Martin ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
