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.
Hi, could you attach the panic log?
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)?
Created attachment 140811 [details]
Crash log on 3.15.0-031500rc1-generic
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.
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.
Created attachment 141041 [details]
Created attachment 141051 [details]
Photo of the crash output
Created attachment 141061 [details]
another photo of crash output
I took these phots previously, but didn't know anything about what they show. I don't know whether they're useful.
Ok. Could you unload i2c-hid module and then try hibernation again?
From the log, it's caused by i2c-hid driver and so reassign.
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
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).
Could you have a look this kernel panic which is caused by I2C hid resume callback?
Any word on this? I'd love to get a resolution, or just a hint of what to try or do....
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.
Created attachment 143641 [details]
Patch to test
This patch tries to check for NULL ihid->cmdbuf, that I'm suspecting is the case here.
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....
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').
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!