Re: linux-next: Tree for Apr 24 [ PM: Device 1-1.2 failed to resumeasync: error -32 ]

[Alan Stern]

On Wed, 24 Apr 2013, Sedat Dilek wrote:

> > [ CC linux-pm and linux-usb (ehci) folks ]
> >
> > This happens with my external USB mouse after suspend/resume.
> >
> > Excerpt (full dmesg and kernel-config attached):
> >
> > $ dmesg | egrep -i 'usb|async' | grep 1-1.2
> > [    1.258602] usb 1-1.2: new low-speed USB device number 3 using ehci-pci
> > [    1.368649] usb 1-1.2: New USB device found, idVendor=046d, idProduct=c00e
> > [    1.368661] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=0
> > [    1.368668] usb 1-1.2: Product: USB-PS/2 Optical Mouse
> > [    1.368672] usb 1-1.2: Manufacturer: Logitech
> > [    1.957999] input: Logitech USB-PS/2 Optical Mouse as
> > /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input4
> > [   62.353997] usb 1-1.2: reset low-speed USB device number 3 using ehci-pci
> > [   62.636893] PM: Device 1-1.2 failed to resume async: error -32
> > [   64.243543] usb 1-1.2: USB disconnect, device number 3
> > [   64.380328] usb 1-1.2: new low-speed USB device number 5 using ehci-pci
> > [   64.477612] usb 1-1.2: New USB device found, idVendor=046d, idProduct=c00e
> > [   64.477618] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=0
> > [   64.477621] usb 1-1.2: Product: USB-PS/2 Optical Mouse
> > [   64.477623] usb 1-1.2: Manufacturer: Logitech
> > [   64.481934] input: Logitech USB-PS/2 Optical Mouse as
> > /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input11
> >

Did this work differently under earlier kernels?

> Thos 3 lines IIRC are important (one line missing above):
> 
> [   62.353997] usb 1-1.2: reset low-speed USB device number 3 using ehci-pci
> [   62.636877] dpm_run_callback(): usb_dev_resume+0x0/0x20 returns -32
> [   62.636893] PM: Device 1-1.2 failed to resume async: error -32
> 
> - Sedat -
> 
> > Any help/hints/infos welcome :-)!

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.

On the other hand, what difference does it really make if a mouse has
to be reenumerated?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/