Bug 78801 - Suspend causes a kernel panic
Summary: Suspend causes a kernel panic
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_input-devices
Depends on:
Reported: 2014-06-24 01:30 UTC by Caleb Hyde
Modified: 2015-02-19 07:50 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.15.0-031500rc1-generic
Tree: Mainline
Regression: Yes

Crash log on 3.15.0-031500rc1-generic (571.01 KB, text/x-apport)
2014-06-24 01:49 UTC, Caleb Hyde
00touchpad (148 bytes, application/octet-stream)
2014-06-27 03:23 UTC, Caleb Hyde
Photo of the crash output (1.42 MB, image/jpeg)
2014-06-27 03:24 UTC, Caleb Hyde
another photo of crash output (1.04 MB, image/jpeg)
2014-06-27 03:24 UTC, Caleb Hyde
Patch to test (502 bytes, patch)
2014-07-21 12:21 UTC, Mika Westerberg
Details | Diff

Description Caleb Hyde 2014-06-24 01:30:27 UTC
I'm trying to narrow down a regression on Ubuntu wherein suspend causes a kernel panic. This is on a Samsung Ativ Book 9 2014, i.e. model np940x5j-k02us.

Based on the builds here:

I've narrowed it to between Trusty kernel 3.14.8 and kernel 3.15.0 (v3.14.8-utopic versus v3.15-rc1-trusty).

I was trying to isolate this further, maybe bisect, and based on this document:

tried searching `git tag`, but tags stop at -9.29:

My motivation is this: prior to kernel 3.14, *suspend* works, but the *trackpad* does not. Somewhere around Utopic 3.15 rc7, the trackpad begins working again, but prior to that, suspend causes a kernel panic (blinking caps lock light).

Given that the trackpad seems to get resolved in Utopic, I'm fine ignoring that separate issue, if I can help resolve the suspend kernel panic issue. I'm comfortable with git and have already built the trusty kernel, so now I'd like to help isolate this regression.
Comment 1 Lan Tianyu 2014-06-24 01:35:04 UTC
Hi, could you attach the panic log?
Comment 2 Caleb Hyde 2014-06-24 01:38:53 UTC
Yes. I had started down the path to report this at launchpad.net, but then apport told me to report as mainline. I haven't read all the documentation here. Can you briefly explain what files you want (or send me the link)?
Comment 3 Caleb Hyde 2014-06-24 01:49:53 UTC
Created attachment 140811 [details]
Crash log on 3.15.0-031500rc1-generic
Comment 4 Lan Tianyu 2014-06-27 02:39:00 UTC
Could you see some kernel panic log on the screen when the issue happens?
If not, please add "no_console_suspend" kernel param and try again.

I see some logs like this.
 Running hook /etc/pm/sleep.d/00touchpad suspend suspend:
 Unable to connect to X server
 /etc/pm/sleep.d/00touchpad suspend suspend: Returned exit code 1.

 Fri Jun 20 18:53:16 CDT 2014: Inhibit found, will not perform suspend

Could you attach /etc/pm/sleep.d/00touchpad file? Please rename it and try again.
Comment 5 Caleb Hyde 2014-06-27 03:23:07 UTC
Yes, attaching that now. I added it myself, to see whether it resolved the issue, but no luck. The kernel panic occured before I created the file, too.
Comment 6 Caleb Hyde 2014-06-27 03:23:37 UTC
Created attachment 141041 [details]
Comment 7 Caleb Hyde 2014-06-27 03:24:06 UTC
Created attachment 141051 [details]
Photo of the crash output
Comment 8 Caleb Hyde 2014-06-27 03:24:24 UTC
Created attachment 141061 [details]
another photo of crash output
Comment 9 Caleb Hyde 2014-06-27 03:25:53 UTC
I took these phots previously, but didn't know anything about what they show. I don't know whether they're useful.
Comment 10 Lan Tianyu 2014-06-27 03:37:21 UTC
Ok. Could you unload i2c-hid module and then try hibernation again?
Comment 11 Lan Tianyu 2014-06-27 03:52:43 UTC
From the log, it's caused by i2c-hid driver and so reassign.
Comment 12 Caleb Hyde 2014-06-27 04:11:22 UTC
Ok, yes, removing i2c_hid allows for suspend to work.

Just to be clear (since I'm not too knowledgable about this matter), this is what I did:

    sudo rmmod i2c_hid
    sudo pm-suspend

And that works (suspend, then resume).

Currently, I'm using 3.15.0-031500rc1-generic on 14.04:
$ uname -a
Linux CSH-AT9 3.15.0-031500rc1-generic #201404131835 SMP Sun Apr 13 22:36:23 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/os-release 
VERSION="14.04, Trusty Tahr"
PRETTY_NAME="Ubuntu 14.04 LTS"

It is probably worth mentioning: when I don't unload i2c_hid, and attempt suspend, it does not fail until I click the trackpad. When I click the trackpad, the caps-lock light starts quickly flashing (what I believe indicates the kernel panic).
Comment 13 Lan Tianyu 2014-06-27 05:22:12 UTC
Cc: Mika.

Hi Mika:
      Could you have a look this kernel panic which is caused by I2C hid resume callback?
Comment 14 Caleb Hyde 2014-07-12 00:30:30 UTC
Any word on this? I'd love to get a resolution, or just a hint of what to try or do....
Comment 15 Mika Westerberg 2014-07-21 12:19:10 UTC
Sorry for the delay, I've been on vacation.

Caleb, are you able to build your own kernel and try with that? I would like you to test a patch which I'll attach to the bug, if possible.
Comment 16 Mika Westerberg 2014-07-21 12:21:16 UTC
Created attachment 143641 [details]
Patch to test

This patch tries to check for NULL ihid->cmdbuf, that I'm suspecting is the case here.
Comment 17 Caleb Hyde 2014-07-28 01:52:11 UTC
Hello again. Sorry for my delay this time -- work and all.

I regret to say that I cannot reproduce the kernel panic at this point. Previously, the kernel deb's that I used were the dailies from the PPA:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-rc1-trusty/ (and rc8, etc.)

In preparation to apply the patch you provided, I compiled the kernel from source (git://kernel.ubuntu.com/ubuntu/ubuntu-utopic.git), but after reboot, could not induce the panic -- suspend worked without issue.

So then I tried including the Ubuntu configurations (https://wiki.ubuntu.com/KernelTeam/GitKernelBuild#Using_Ubuntu_Kernel_Configuration), but still suspend worked ok (though I got a different sort of hang: frozen screen, no input, not while suspending).

I was in fact able to apply your patch, and even re-compiled with that. But since I cannot reproduce the panic _prior_ to applying the patch, it seems moot.

I'd be happy to try whatever else you would suggest, but I'm not clear on what is different between the pre-compiled daily that I had used (3.15.0-031500rc1-generic) and the locally-compiled kernel I have here now (3.15.0-rc1-custom).

Maybe I should just start working papercuts....
Comment 18 Mika Westerberg 2014-07-28 09:26:19 UTC
I have no idea what the delta between those two kernel binaries is. It would be good if you can try with the mainline kernel (from Linus' tree), so that we can rule out any ubuntu specific patches.

You can use your existing .config with the mainline kernel (just copy the .config to the mainline kernel tree and run 'make oldconfig').
Comment 19 Caleb Hyde 2014-08-12 10:33:30 UTC
Hi, I'm not sure why I didn't see the latest reply. I don't think I got an email notification. I'll try the mainline kernel and let you know. Thanks!

Note You need to log in before you can comment on or make changes to this bug.