On Fri, 13 Feb 2009, Jiri Slaby wrote: > > You might want to build a kernel with CONFIG_USB_DEBUG enabled. The > > extra debugging information should help find the problem. > > Here comes the resume part (including unplug, replug). I suspect auto-suspend? I don't think autosuspend is the issue, because normally neither keyboards nor mice get autosuspended. In fact the log appears to be perfectly correct; I don't see any errors in it. So the problem must be lower down, such as in the usbhid driver. The best way to track this is to use usbmon. Here's what I'd like you to do: After booting, unplug the mouse/keyboard. Then do "dmesg -c >/dev/null" to clear the kernel log buffer. Start up usbmon, looking at bus 6 (or whichever bus the mouse/keyboard was plugged into). If you don't have any other keyboard to use for this then do it via a network login. Plug in the mouse/keyboard. Press a key to verify that the keyboard is working, but otherwise don't use either device. Go through a suspend/resume cycle (again using the network link if you don't have another keyboard). Type another key to verify that the keyboard isn't working. Unplug the keyboard/mouse and plug them back in. Type a third key to verify that now the keyboard is working again. Stop the usbmon trace and post the resulting file along with the dmesg log. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
