On Mon, 25 Jun 2007, Jiri Kosina wrote: > On Mon, 25 Jun 2007, Oliver Neukum wrote: > > > > 1.1, the device is still handled by uhci_hcd. > > That indicates that something's wrong in uhci's root hub code. > > Just for completness, below is what dev_dbg gives. > > This is the case which is OK - I turn the autosuspend on, let the keyboard > suspend, wait for more than 2 seconds, hit a few keys, everything works:
... > this is the failing case (i.e. hitting the keys without waiting two > seconds after the keyboard is suspended): ... > i.e. when the HUB is also suspended and then woken up, everything looks > OK, but if it is only the device, without root hub going to suspend, it > doesn't work. These logs look correct. The difference might have something to do with the timing of the USB messages relative to the keystrokes. Or maybe the keyboard itself has some weird 2-second timer. > Alan, could this possibly be some race in uhci hub suspend handling (i.e. > when the keyboard tries to resume while the root hub is trying to go to > suspend, or something like that). I don't think so. These transitions are protected by mutexes. In case of a race like you suggest, either the keyboard would win and would resume, thereby preventing the root hub from suspending (which is what actually did occur in your second log), or else the root hub would win and would suspend, then immediately resume because of the wakeup request from the keyboard. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
