On Wed, 19 May 2004, David Brownell wrote: > Alan Stern wrote: > > > > I don't understand your point here. Imagine this: hub A reports a new > > connection on one of its ports. Khubd sees this and goes through > > debouncing etc. While this is happening hub A is unplugged. Since > > debouncing failed, khubd wants to disable the port. But it can't, since > > hub A won't reply to the CLEAR_FEATURE messages. Since khubd has been > > preoccupied with all this debouncing stuff it doesn't yet know that hub A > > has been unplugged. Even if it's multithreaded it still might not learn > > for a large fraction of a second, not until hub A's parent's status > > interrupt message arrives. In the meantime, how do we know to avoid > > logging a premature KERN_ALERT message? > > That's the scenario I mentioned: state represented by > stack context in khubd. In this case, context that knows > it's going to be first debouncing etc.
There are other cases where khubd's stack context isn't involved. Disconnecting a hub while another thread is trying to reset one of its ports, for example, like you mention below. > That "large fraction of a second" falls into the category > of "retries lasting more than 1/4 sec", right? It should. > (Where 1/4 second is the canonical hub poll interval. It > might be necessary to add a bit of slop there, but it > shouldn't be too much more.) Actually it falls into the category of "retries lasting _less_ than 1/4 sec". If the retries last only a few msec, then when they're over the next status message probably hasn't arrived yet. If the retries last longer than 1/4 sec and they run in a separate thread from khubd then there isn't a problem. > > They don't all imply disconnect. C_PORT_RESET and C_PORT_SUSPEND don't, > > for example. So that idea doesn't work. > > C_PORT_SUSPEND == remote wakeup ... as I pointed out, when a > port is suspended, that precludes all "normal" hub operations > downstream. Sure, but it doesn't mean you can mark the device as NOTATTACHED! > C_PORT_RESET happens in two cases. When enumerating, there > is no device connected -- so as I said, no disconnect. In > the usb_reset_device() case, you'd likely need to move to at > least a partial state machine model. I'm thinking the only way to make this work is to delay sending that ALERT message for a second or so, to avoid false alarms. Maybe that counts as a partial state machine. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
