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

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

[Jonas Jelten]

Hi!

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?

Cheers,
Jonas

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

[Benjamin Tissoires]

On Mon, Sep 22, 2014 at 11:01 AM, Jonas Jelten <jelten@in.tum.de> wrote:
> Hi!
>
> 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.

Cheers,
Benjamin

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

[Jonas Jelten]

On 2014-09-22 17:52, Benjamin Tissoires wrote:
> On Mon, Sep 22, 2014 at 11:01 AM, Jonas Jelten <jelten@in.tum.de> wrote:
>> Hi!
>>
>> 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.

Cheers,
Jonas

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

[Jiri Kosina]

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?

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

[Benjamin Tissoires]

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

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

[Jonas Jelten]

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

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

[Jiri Kosina]

On Thu, 25 Sep 2014, Jonas Jelten wrote:

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

Is there any way you could setup serial console or at least netconsole on 
that system?

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

Just compiling for-3.18/wacom branch of

	git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git

should be enough.

I still fail to see how this would be fixing any panic, so either there is 
a very strange race condition somewhere, or this is a different problem 
that still needs to be solved.

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

[Jonas Jelten]

On 2014-09-25 02:24, Jiri Kosina wrote:
> On Thu, 25 Sep 2014, Jonas Jelten wrote:
> 
>> 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.
> 
> Is there any way you could setup serial console or at least netconsole on 
> that system?
> 
>> 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.
> 
> Just compiling for-3.18/wacom branch of
> 
> 	git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
> 
> should be enough.
> 
> I still fail to see how this would be fixing any panic, so either there is 
> a very strange race condition somewhere, or this is a different problem 
> that still needs to be solved.
> 
> Thanks,
> 

Hi!

Now running 3.17.0, I managed to get a backtrace via netconsole:


[ 1077.286152] PM: Syncing filesystems ... done.
[ 1077.286888] PM: Preparing system for mem sleep
[ 1077.503113] Freezing user space processes ... (elapsed 0.001 seconds)
done.
[ 1077.504368] Freezing remaining freezable tasks ... (elapsed 0.000
seconds) done.
[ 1077.505359] PM: Entering mem sleep
[ 1077.705575] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 1077.705695] sd 0:0:0:0: [sda] Stopping disk
[ 1077.806294] e1000e: EEE TX LPI TIMER: 00000011
[ 1093.625038] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[ 1100.434376] usb 2-1.5: **** DPM device timeout ****
[ 1100.435410]  ffff8801fc20f9d8 0000000000000002 ffff8801fc20ffd8
ffff8801fc210000
[ 1100.436468]  0000000000014240 ffffffff81a1a440 ffff8801fc210000
ffffffffa0043022
[ 1100.437521]  ffff880100000000 ffff8801fc20f928 ffff8801fc20f998
0000000000000000
[ 1100.438521] Call Trace:
[ 1100.439512]  [<ffffffff81541b0f>] ? _raw_spin_unlock_irqrestore+0x20/0x33
[ 1100.440516]  [<ffffffffa006836b>] ? ehci_urb_enqueue+0x119/0xbf8
[ehci_hcd]
[ 1100.441522]  [<ffffffff81319d1c>] ? debug_smp_processor_id+0x17/0x19
[ 1100.442590]  [<ffffffff8109384f>] ? wake_up_nohz_cpu+0x28/0x8f
[ 1100.443601]  [<ffffffff8153e941>] schedule+0x6e/0x70
[ 1100.444611]  [<ffffffff81541077>] schedule_timeout+0x15a/0x1c2
[ 1100.445616]  [<ffffffff810bd1cf>] ? ftrace_raw_event_tick_stop+0xa8/0xa8
[ 1100.446627]  [<ffffffff8153f2cc>] wait_for_common+0x111/0x151
[ 1100.447643]  [<ffffffff81096e3f>] ? wake_up_process+0x37/0x37
[ 1100.448658]  [<ffffffff8153f33e>] wait_for_completion_timeout+0x13/0x15
[ 1100.449682]  [<ffffffffa002ed55>] usb_start_wait_urb+0x84/0xce [usbcore]
[ 1100.450708]  [<ffffffffa002ee67>] usb_control_msg+0xc8/0xff [usbcore]
[ 1100.451728]  [<ffffffffa00bee1b>] usbhid_raw_request+0x137/0x154 [usbhid]
[ 1100.452746]  [<ffffffffa0116e2a>]
wacom_set_report.constprop.17+0x53/0x73 [wacom]
[ 1100.453775]  [<ffffffffa0117495>] wacom_query_tablet_data+0x8f/0x23a
[wacom]
[ 1100.454796]  [<ffffffffa0117676>] wacom_resume+0x36/0x4f [wacom]
[ 1100.455876]  [<ffffffffa011769d>] wacom_reset_resume+0xe/0x10 [wacom]
[ 1100.456888]  [<ffffffffa00bfbc8>] hid_reset_resume+0x4c/0x58 [usbhid]
[ 1100.457902]  [<ffffffffa00317f1>]
usb_resume_interface.isra.6+0x71/0xc6 [usbcore]
[ 1100.458921]  [<ffffffffa0031aaa>] usb_resume_both+0xd6/0x106 [usbcore]
[ 1100.459937]  [<ffffffffa00251b8>] ? usb_dev_thaw+0x15/0x15 [usbcore]
[ 1100.460956]  [<ffffffffa0032100>] usb_resume+0x1b/0x64 [usbcore]
[ 1100.461973]  [<ffffffffa00251b8>] ? usb_dev_thaw+0x15/0x15 [usbcore]
[ 1100.462983]  [<ffffffffa00251cb>] usb_dev_resume+0x13/0x15 [usbcore]
[ 1100.463983]  [<ffffffff813dd62e>] dpm_run_callback+0x48/0x106
[ 1100.464976]  [<ffffffff813de058>] device_resume+0x16b/0x1a6
[ 1100.465971]  [<ffffffff813dd4e7>] ? __suspend_report_result+0x25/0x25
[ 1100.466962]  [<ffffffff813de0b0>] async_resume+0x1d/0x43
[ 1100.467946]  [<ffffffff8108ea22>] async_run_entry_fn+0x5f/0x115
[ 1100.468923]  [<ffffffff81088480>] process_one_work+0x1bf/0x35d
[ 1100.469903]  [<ffffffff81088eee>] worker_thread+0x28e/0x382
[ 1100.470872]  [<ffffffff81088c60>] ? rescuer_thread+0x226/0x226
[ 1100.471834]  [<ffffffff8108ca2c>] kthread+0xd2/0xda
[ 1100.472793]  [<ffffffff8108c95a>] ? kthread_create_on_node+0x16f/0x16f
[ 1100.473757]  [<ffffffff815423bc>] ret_from_fork+0x7c/0xb0
[ 1100.474725]  [<ffffffff8108c95a>] ? kthread_create_on_node+0x16f/0x16f
[ 1100.475697] Kernel panic - not syncing: usb 2-1.5: unrecoverable failure
[ 1100.475697]
[ 1100.477626] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G  R
3.17.0-JJ+ #71
[ 1100.478608] Hardware name: LENOVO 4296CTO/4296CTO, BIOS 8DET67WW
(1.37 ) 12/05/2012
[ 1100.479596]  0000000000000000 ffff88021e283e00 ffffffff8153c8c8
ffffffff8183ab5c
[ 1100.480673]  ffff88021e283e78 ffffffff8153954d ffffffff00000018
ffff88021e283e88
[ 1100.481686]  ffff88021e283e28 ffff88021e27ffc0 ffffffffa003b4a5
ffff8800d45ec810
[ 1100.482684] Call Trace:
[ 1100.483655]  <IRQ>  [<ffffffff8153c8c8>] dump_stack+0x4e/0x7a
[ 1100.484639]  [<ffffffff8153954d>] panic+0xcb/0x1f4
[ 1100.485622]  [<ffffffff813dd4e7>] ? __suspend_report_result+0x25/0x25
[ 1100.486597]  [<ffffffff813dd539>] dpm_watchdog_handler+0x52/0x52
[ 1100.487567]  [<ffffffff810bd225>] call_timer_fn+0x46/0x124
[ 1100.488529]  [<ffffffff813dd4e7>] ? __suspend_report_result+0x25/0x25
[ 1100.489496]  [<ffffffff810bda8b>] run_timer_softirq+0x215/0x280
[ 1100.490457]  [<ffffffff810c8b25>] ? clockevents_program_event+0x9d/0xb9
[ 1100.491423]  [<ffffffff81078bae>] __do_softirq+0xf4/0x27d
[ 1100.492389]  [<ffffffff81078ee6>] irq_exit+0x43/0x89
[ 1100.493353]  [<ffffffff815452fe>] smp_apic_timer_interrupt+0x44/0x50
[ 1100.494318]  [<ffffffff8154348d>] apic_timer_interrupt+0x6d/0x80
[ 1100.495287]  <EOI>  [<ffffffff81449730>] ? cpuidle_enter_state+0x8b/0x16b
[ 1100.496264]  [<ffffffff814498b9>] cpuidle_enter+0x17/0x19
[ 1100.497236]  [<ffffffff810a51d6>] cpu_startup_entry+0x1b6/0x2f0
[ 1100.498212]  [<ffffffff81035f4d>] start_secondary+0x1ad/0x1b2
[ 1100.499205] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation
range: 0xffffffff80000000-0xffffffff9fffffff)
[ 1100.500254] drm_kms_helper: panic occurred, switching back to text
console

This looks like the kernel is failing to bring up the wacom usb device
after the suspend.
Probably this is something for linux-kernel@?


Cheers,
Jonas