On Wed, Apr 24, 2013 at 11:17 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 24 Apr 2013, Sedat Dilek wrote: > >> > Did this work differently under earlier kernels? >> > >> >> Unfortunately, s/r did not work for several Linux-Next releases as >> there is missing tglx's patch pendinging in tip.git/timers/core. > > Have you tried testing under 3.8? Or earlier releases? > >> > This indicates that the optical mouse didn't survive the suspend/resume >> > sequence and had to be reenumerated. Without more information, there's >> > no way to tell specifically what went wrong during the initial reset at >> > timestamp 62.353997. >> > >> > If you want to pursue this farther, you could enable CONFIG_USB_DEBUG. >> > You could also collect a usbmon trace for bus 1 showing what happens >> > during the suspend and resume. >> > >> >> Hmm, I can try to enable CONFIG_USB_DEBUG and build a new kernel. >> >> Can you give me more hints how to do a usbmon-trace? > > See Documentation/usb/usbmon.txt. > Grrr, that docs do not mention which kernel-configs have to be set! CONFIG_USB_DEBUG=y is not enough. # modprobe -v usbmon FATAL: Module usbmon not found. # CONFIG_USB_MON is not set <--- Grrr!!! Doing a -4 build... - Sedat - >> > On the other hand, what difference does it really make if a mouse has >> > to be reenumerated? >> > >> >> As a non-USB-expert it's hard to interprete such "bogus" lines in your logs. >> I am curious enough to ask which is fair :-). >> AFAICS in your eyes this is "harmless"? > > If the device continues to work normally after the resume and none of > your programs are affected, then it is harmless. > > Alan Stern >
