On 2014-09-24 21:27, Benjamin Tissoires wrote: > On Wed, Sep 24, 2014 at 4:34 AM, Jiri Kosina <jkosina@xxxxxxx> 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@xxxxxxxxxx> >>>>> 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 -- 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
