Red Hat Bugzilla – Bug 439877
Kernel panics seemingly at random
Last modified: 2008-10-22 17:39:33 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux 2.6.24.3-50.fc8) KHTML/3.5.9 (like Gecko) Description of problem: Running on a Dell Inspiron 1420. When booting up, especially with kernel-2.6.24.3-50, the kernel appears to panic, the mouse and keyboard stop functioning, and the capslock and numlock indicators start blinking. This problem occasionally happens while the system is in use. I am not able to determine whether or not the problem is in the kernel or X11. Version-Release number of selected component (if applicable): kernel-2.6.24.3-34, kernel-2.6.24.3-50 How reproducible: Always Steps to Reproduce: 1. Boot up the 2.6.24.3-50 kernel 2. Wait. Actual Results: Panic with 2.6.24.3-50; harder to reproduce with 2.6.24.3-34. Expected Results: The kernel should not panic. Additional info:
We really need to capture the panic messages that are being printed to the tty. This can be tricky whilst you're in X. Read http://fedoraproject.org/wiki/KernelCommonProblems#head-aacc422f26396dee978174e105c6a2b8ed962971 especially the part about netconsole, and give that a try.
1. Netconsole is difficult in this case, because the panic is difficult to reproduce. It does not happen as a result of any sort of action, it just happens at completely random intervals. The machine in question is a laptop, and is not always on the same network (or on any network at all). 2. I just had the same problem on my machine, a Dell D620. I tried to use the magic sysrq key, but this did not produce any log messages. The symptoms are the same -- capslock and scroll lock indicators flashing (with a frequency of 1 second). Do these indicators flashing have any meaning? It seems like something that is deliberate... This panic occurred immediately after yum finished installing some updates, if that is any help.
the flashing lights means "we just paniced, and I spewed a backtrace to a tty" it's there as an indicator so that when we see a locked up X we can discriminate between "X locked up" and "kernel panic". Without seeing that trace, there's really nothing we can do.
The next time this happens, I am going to try the magic sysrq key; I may not have had it activated last time. Does suspend to RAM cause this key to be disabled for any reason? Is there anything else I should try? Is there a possible way to have the kernel's backtrace dumped into a file instead of a tty (unless, of course, the problem comes from a disk driver of some sort...)?
if the lights are blinking, sysrq won't do anything. It's already wedged. we can't dump to a file because after a panic, we've no idea just what state the kernel is in, and it could corrupt disks if it wrote to them. I've no idea how well the kdump stuff works right now, that might be worth experimenting with.
Thanks for taking the time to file a report, if you could get more of an error message or log that would be great. For now I'm going to change the status to NEEDINFO before this can be fixed.
The information we've requested above is required in order to review this problem report further and diagnose or fix the issue if it is still present. Since it has been thirty days or more since we first requested additional information, we're assuming the problem is either no longer present in the current Fedora release, or that there is no longer any interest in tracking the problem. Setting status to "CLOSED: INSUFFICIENT_DATA". If you still experience this problem after updating to our latest Fedora release and can provide the information previously requested, please feel free to reopen the bug report. Thank you in advance.