Re: HID: wacom: regression - system freezes when resuming from S3 suspend

[Jonas Jelten <jelten@in.tum.de>]

On 2014-09-24 21:27, Benjamin Tissoires wrote:
> On Wed, Sep 24, 2014 at 4:34 AM, Jiri Kosina <jkosina@suse.cz> wrote:
>> On Wed, 24 Sep 2014, Jonas Jelten wrote:
>>
>>>>> I encountered that my system freezes when resuming my Lenovo X220t with
>>>>> integrated Wacom ISDv4 tablet from S3 suspend.
>>>>>
>>>>> Currently running 3.17.0-rc6, I started to bisect and found that this
>>>>> commit causes the issue:
>>>>>
>>>>> commit 29b4739134c73a2873adec93346f09bb76d6a794
>>>>> Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>>>>> Date:   Thu Jul 24 12:52:23 2014 -0700
>>>>>
>>>>>     Input: wacom - switch from an USB driver to a HID driver
>>>>>
>>>>>
>>>>> Running 3.17.0-rc6, right after boot, this shows up in the log:
>>>>>
>>>>> [   25.843484] wacom 0003:056A:00E6.0001: usb_submit_urb(ctrl) failed: -1
>>>>> [   25.843531] wacom 0003:056A:00E6.0001: timeout initializing reports
>>>>> [   25.843886] wacom 0003:056A:00E6.0001: hidraw0: USB HID v1.11 Device
>>>>> [Tablet ISD-V4] on usb-0000:00:1d.0-1.5/input0
>>>>> [   25.846036] input: Wacom ISDv4 E6 Finger as
>>>>> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.1/0003:056A:00E6.0002/input/input18
>>>>>
>>>>> When suspending, the screen goes off and about 8 seconds later, the
>>>>> machine actually suspends.
>>>>>
>>>>> Right after the (instant) resume, I can see the frame buffer I had when
>>>>> suspending (X screen) for about 10 seconds. During that time, no sysrq
>>>>> works. After this short period, the tty1-framebuffer appears, with
>>>>> messed up linebreaks (no carriage returns occur any more), and the
>>>>> capslock-led starts blinking. Sysrq keys still don't work. The system is
>>>>> completely frozen.
>>>>>
>>>>> Running the kernel from the bisected first good commit, the suspend is
>>>>> faster (under 1 second) and the resume does not crash.
>>>>>
>>>>> I just saw the "HID: wacom: fix timeout on probe for some wacoms" mail,
>>>>> which probably has to do something with my problem.
>>>>>
>>>>> Any ideas?
>>>>
>>>> Yes, this commit will fix your problem. It has just been delayed for
>>>> 3.17.1 as mentioned by Jiri today.
>>>
>>> Are you sure it's a good idea to let the kernel crash into 3.17.0 and
>>> fix it later in stable? I suspect many X220t users could be affected.
>>
>> Okay, my initial understanding was that this is just about the 10s delay.
>> How exactly does it crash on resume, and do we have any idea why it
>> crashes, and why "HID: wacom: fix timeout on probe for some wacoms" fixes
>> it?
>>
> 
> I am not sure (I can not see how actually) that there is a kernel oops
> on resume (what you intend by "crash").
> However, if the system disable/enable the USB ports both on suspend &
> resume (this is where I do not understand), the hid core layer will
> try to get the current report states from the device. The device does
> not answer, so this adds the delay on both suspend and resume, which
> can be quite annoying.
> 
> It's just a ugly lock with a 5-8 sec timeouts, not an actual crash.
> 
> Cheers,
> Benjamin
> 

I have no idea about the reasons yet, however my kernel indeed panics 10
seconds after resume from S3. During the 10 seconds, the on-suspend X
screen is visible, but frozen (no mouse/keyboard input) and no sysrqs
are possible. After the 10s passed, I see old tty1 framebuffer parts
from the init system log, the kernel seems to have paniced as the
capslock led starts blinking, but I can't see any backtrace.

I could not test whether "HID: wacom: fix timeout on probe for some
wacoms" fixes the panic, as it does not apply for 3.17-rc6.

Cheers,
Jonas