Created attachment 103101 [details]
DMESG, LSMOD and acpi dump of me device
Already from 3.8.X tree my laptop gets randmon kernel panics when I run the system without acpi=noirq parameter. It is hard to get panics log because it happens complete random and often when the PC is running X server. Device
- Intel Core i3 330M
- Nvidia Geforce 330M
- 6GB RAM
The last panic with I can report was on 3.8 kernel, I have run on X server multiple glxgears and switched to console, the after few minutes I have a oops. I attached a screen image of it. The logs are from 3.9 kernel (but after few min when I was away the kernel crashes too).
https://dl.dropboxusercontent.com/u/1664131/IMG_20130427_174954.jpg screen photo of the kernel panics, to big for an attachment
From the panic, it looks kernel crashed in ec interrupt handler.
Could you use addr2line to locate which line cause this panic?
eg, add2line -a ffffffff812d4797 -e vmlinux
BTW, is this bug a regression?
*** Bug 59641 has been marked as a duplicate of this bug. ***
Sorry for the late replay, but I had some exams in last days. Well I don't already have the 3.8 kernel (moved to 3.9) but I will try to crash the 3.9 kernel today and run the add2line. I think this bug is a regression because on 3.7 kernel (or 3.6 I don't remember) the kernel runs stable without acpi=noirq. Well I will add a new kernel crash and the add2line in few hours.
Ok. Thanks for test. Just check the change log of driver/acpi/ec.c between v3.7 and v3.9. There is no obvious commit related with such issue.
Here is a new crash log https://dl.dropboxusercontent.com/u/1664131/IMG_20130618_133650.jpg unfortunely the Call Trace is much longer so it overlapped the begin of the log, is the any chance to scroll the log up or log it to a file? It is hard to catch when the output is generated because it happens complete random, last time it happens after 5 min uptime, this time it happens after ~30min uptime.
What about kdump? Could it help us to find where the kernel crashes?
What does "addr2line -a ffff8801bbc83db8 -e vmlinux" say under kernel source directory?
addr2line -a ffffffffbbc83db8 -e ./vmlinux
Well I have uploaded the vmlinux file, here it is https://dl.dropboxusercontent.com/u/1664131/vmlinux
Eee wrong command, but this shows the same:
addr2line -a ffff8801bbc83db8 -e vmlinux
Sorrry, please use ffffffff812dda2b as address and try again.
Well I already tried it, it shows that the kernel crashes in the ec.c:
addr2line -a ffffffff812dda2b -e vmlinux
Created attachment 105291 [details]
Please try this patch.
Sorry for the late replay, I was lite busy. Well I have patched latest 3.9 kernel with this path, it still crashes (but as I see this wasn't a fix just some debug, I am right?). Here is the latest crashes https://dl.dropboxusercontent.com/u/1664131/IMG_20130701_193702.jpg running addr2line -a ffffffff812ddb85 -e vmlinux still only shows the ec.c:? nothing more, but hope the are some or info in this crash.
hi, sorry for later response. Could you please try the following patch?
I am on holidays now, so sorry for the delay, I will be back on Friday, so expect an update on Friday or Saturday.
Ok, this time the crash was much longer, unfortunately it doesn't fit the screen. Her is it https://dl.dropboxusercontent.com/u/1664131/IMG_20130810_105942.jpg I have uploaded my vmlinux and config here https://dl.dropboxusercontent.com/u/1664131/vmlinux-3.10.5 https://dl.dropboxusercontent.com/u/1664131/config-3.10.5 because I will be not online next ~two weeks.
Hi, Sorry for later response. I recently find the following patch maybe related with this bug. Please have a try.
After 23h uptime I think I can say this fixed it ;). I hope it is really this. So for now big thanks for helping my. BTW When will this fix be merged with mainline? In 3.13 or 3.14?
It has been merged into v3.13. So mark the bug as PATCH_ALREADY_AVAILABLE.
I see it is already marked. Thanks for helping ;).