Bugzilla – Bug 732851
kernel panic
Last modified: 2012-06-14 04:02:09 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0a1) Gecko/20111125 Firefox/11.0a1 SeaMonkey/2.8a1 I was typing a post in a forum when suddenly the kernel panicked. This is the 2nd panic I get since installing oS 12.1. This time I tried to copy what I saw on the console before rebooting (see below, "Additional information"). Maybe other stuff went by just before, too fast for me to write them down. If there is any way to get more information after rebooting, just tell me where. Reproducible: Sometimes Steps to Reproduce: 0. Do nothing out of the ordinary. Actual Results: kernel panic Expected Results: don't panic Additional information: what I copied (by hand) from /dev/tty1 after my keyboard lights had gone blinking: Kernel panic - not syncing: Fatal exception in interrupt: Pid:3962, comm: plugin-containe Tainted: G D 3.1.0-1.2-desktop #1 Call trace: [<ffffffff810043fa>] dump_trace+0xaa/0x260 [<ffffffff81582a4a>] dump_stack+0x69/0x6f [<ffffffff815851d1>] panic+0xa4/0x1b8 [<ffffffff8159d62f>] oops_end+0xef/0xf0 [<ffffffff8159f662>] do_page_fault+0x402/0x530 [<ffffffff8159c8b5>] page_fault+0x25/0x30 [<ffffffff8100476a>] show_stack_log_eol+0x16a/0x1e0 [<ffffffff810048c3>] show_registers+0xe3/0x2d0 [<ffffffff8159d6eb>] __die+0xbb/0x100 [<ffffffff81005c10>] die+0x40/0x90 [<ffffffff81003202>] do_double_fault+0x25/0x30 panic occurred, switching back to text console Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 0 Pid: 3598 comm: seamonkey-bin Tainted: G D 3.1.0-1.2-desktop #1 [<ffffffff810043fa>] dump_trace+0xaa/0x260 [<ffffffff81582a4a>] dump_stack+0x69/0x6f [<ffffffff815851d1>] panic+0xa4/0x1b8 [<ffffffff810c3706>] watchdog_overflow_callback+0xb6/0xc0 [<ffffffff810f0(d6>] __perf_event_overflow+0x96/0x200 [<ffffffff81013234>] p4_pmn_handle_irq+0x114/0x1e0 [<ffffffff8159f7d5>] notifier_call_chain+0x45/0x60 [<ffffffff8159f835>] __atomic_notifier_call_chain+0x45/0x70 [<ffffffff8159f89d>] notify_die+0x2d/0x40 [<ffffffff8159cdb7>] default_do_nmi+0x37/0x220 [<ffffffff8159d188>] do_nmi+0x68/0x70 [<ffffffff8159cb70>] nmi+0x20/0x30 [<ffffffff8159d507>] oops_begin+0x67/0xa0 [<ffffffff81584286>] no_context+0xac/0x148 [<ffffffff8159f662>] do_page_fault+0x4021/0x530 [<ffffffff8159c8b5>] page_fault+0x25/0x30 DWARF2 unwinder stuck at page_fault+0x25/0x30 Leftover inexact backtrace: panic occurred, switching back to text console
I see so many bugs when searching for "kernel panic" that for the love of me I couldn't tell which one (if any) this is a dupe of.
When logging in to KDE Plasma window manager I had those kernel panics about once a day; I also had X freezes (not going back to text console, but some snow all over the X display and no reaction to mouse or keyboard, not even to Ctrl-Alt-F1). Several days ago I have changed to logging in to Gnome and both panics and freezes have disappeared.
I've also had panics under Gnome, two in the last few hours. No X freezes under Gnome so far.
BTW: How do you debug a kernel panic?
I have a kind of impression the following conditions (separately or in combination) are risk-increasing factors: - from power-on to the end of gnome-session restore - high load (including SeaMonkey browser-mailer-chat with more than 200 browser tabs) - high load, when keyboard typeahead happens for one or more words - when left for hours with no one using the keyboard or mouse These are subjective, I don't have STR or hard numbers. Once (but only once) it happened while YaST was updating the system, and that was a real PITA.
The one you've attached is a secondary oops (tainted D). Can you configure kdump (yast kdump) and boot with oops=panic? That will cause the system to crash dump when it fails rather than display the secondary oops it is now.
(In reply to comment #6) > The one you've attached is a secondary oops (tainted D). Can you configure > kdump (yast kdump) and boot with oops=panic? That will cause the system to > crash dump when it fails rather than display the secondary oops it is now. How do you want kdump to be configured? The "System → Kernel Kdump" section in yast2 has so many options (on five pages: start-up, dump filtering, dump target, email notification, expert settings) that I feel lost. Otherwise I'll reconfigure grub, adding oops=panic on the kernel command-line so I won't forget to boot with it.
Had an event a few minutes ago, near the end of the systemd init sequence. Seemed to end in reboot, but unsuccessful: finally it ended up repeatedly displaying two lines in alternation on /dev/tty1, too fast for me to read them. Had to reboot manually by cycling the power switch off then immediately on: that was successful, but when I could log in I found that the /var/crash directory (where the YaST settings made me expect to find the panic dump) was empty. I must have done something stupid, but what?
Created attachment 485564 [details] kdump config If you had to manually cycle the power, then the system didn't crash. Or, it's possible that kexec doesn't work on your system. You can test this after a successful boot by running sync a few times and then 'echo c > /proc/sysrq-trigger' Configure Yast2 Kdump by unchecking pretty much everything, like in the attached photo. It's also worthwhile to update makedumpfile to the version from Factory (or Kernel:kdump). 'makedumpfile --dump-dmesg vmcore' will dump the full log.
BTW, please don't set the report as NEEDINFO on the assignee (me). Most of us filter NEEDINFO reports out of our searches.
(In reply to comment #9) [...] > Configure Yast2 Kdump by unchecking pretty much everything, like in the > attached photo. > Done. It was the opposite, with everything ticked and "compressed" dump. On the previous page, "Kdump memory" is set to 128 MB: is that OK? > It's also worthwhile to update makedumpfile to the version from Factory (or > Kernel:kdump). After I send this comment, I'll start hunting for that. 'makedumpfile --dump-dmesg vmcore' will dump the full log. On restart from the panic, right?
Yep. While it would have worked with all the boxes checked and with the compressed dump enabled, it takes a while and save a ton of stuff that you'd just remove anyway.
I haven't had this problem recently. Hard to tell if the underlying bug has been fixed or if the circumstances leading to this (sporadic) bug just haven't happened recently on my system. For instance, low temperature (which doesn't happen in summer in the North hemisphere where I live) used to be an aggravating circumstance. I'm resolving it as WORKSFORME for the time being. I suppose that if someone else gets bitten by a similar bug and can document it better, a new report should be files and, of course, not RESOLVED immediately as a DUPLICATE of this one.