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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 25 Apr 2013 00:07:48 +0200
From:	Sedat Dilek <sedat.dilek@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Linux PM List <linux-pm@...ts.linux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, linux-usb@...r.kernel.org
Subject: Re: linux-next: Tree for Apr 24 [ PM: Device 1-1.2 failed to resume
 async: error -32 ]

On Wed, Apr 24, 2013 at 11:25 PM, Sedat Dilek <sedat.dilek@...il.com> wrote:
> On Wed, Apr 24, 2013 at 11:17 PM, Alan Stern <stern@...land.harvard.edu> 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...
>

[ Get VendorID/ProductID of affected USB-device ]

# dmesg | grep 1-1.2 | egrep -i 'vendor|product'
[    1.372891] usb 1-1.2: New USB device found, idVendor=046d,
idProduct=c00e <--- ProductID!
[    1.372899] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[    1.372905] usb 1-1.2: Product: USB-PS/2 Optical Mouse

[ Check for corresponding USB-bus ]

# grep -B2 046d /sys/kernel/debug/usb/devices
T:  Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  3 Spd=1.5  MxCh= 0
<--- USB-bus #01
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=046d ProdID=c00e Rev=11.10

[ Run logging on USB-bus #1 ]

# cat /sys/kernel/debug/usb/usbmon/1u > /tmp/usbmon-1u.txt <--- USB-bus #01

[ Do suspend plus resume ]

...

[ Check /tmp/usbmon-1u.txt file ]

...

File attached!

- Sedat -

> - 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
>>

View attachment "usbmon-1u.txt" of type "text/plain" (221153 bytes)