Kernel Panic, CentOS 7.1503 Fully Updated, With Executing Gkrellm.

Home » CentOS » Kernel Panic, CentOS 7.1503 Fully Updated, With Executing Gkrellm.
CentOS 9 Comments

Just a heads up, since I know gkrellm is in EPEL and not in the main CentOS repos. However, something fairly fundamental has changed, as prior to updating, gkrellm worked fine, but now every time I execute gkrellm the kernel panics.

I’m going to triage on a different machine, as the panic corrupted at least one system library used by nautilus, but rpm -Va is your friend in these situations, and yum reinstall is its close kin. So I would prefer to duplicate on a burner machine, and I’ll try to get a snapshot of the panic.

If anyone else wants to try to reproduce, simply try installing the current gkrellm from EPEL on a fully updated CentOS 7 machine and see if it panics on you. I kindof hope it’s local to my machine and its configuration (/home is LUKS, for instance), and it would be great if someone could verify that.

9 thoughts on - Kernel Panic, CentOS 7.1503 Fully Updated, With Executing Gkrellm.

  • I can’t duplicate this, but I’m also on 4.0.0-0.rc6.el7.elrepo.x86_64 which may make a difference. Will try it on the stock kernel, too when I reboot next time.


  • If it’s that easy to reproduce, please grab the panic message or generate a vmcore through crashdump and report it at against kernel component.

    You may be using an EPEL application but kernel shouldn’t be panicking like that, specially if you’re running it as an user.


  • Thanks for the pointer with some details. I see that I have a bit to learn. The first thing I need to do is reproduce it on other hardware.

    I will say that I have experienced the same bug twice, but the first time I thought it was a botched yum update with CR enabled (and me having several packages installed from a mixed set of repos as well as some hand-built RPMs in there), and that was with / on ext4. This happened with / on xfs and an almost pristine install of the 20150228
    rolling ISO updated to 1503. I use gkrellm as a quick visual dashboard of system load, and it is useful in that context. I also have it in my startup applications, so the kp happens immediately after logging in.
    (Both times with the same /home on ext4 over LUKS.) The second time, nautilus would not start on a reboot/re-login due to corruption of one of its libraries (found in the ‘tracker’ package). So I am a bit loath to hit this one again on my main machine, as I just don’t have time this week for another reinstall.

    Yeah, if gkrellm (run as a non-privileged user) can panic the kernel, a non-gui app hitting the same bits can too (unless it’s related to the video card’s driver). Pairing a non-privileged userland kp witha a remote arbitrary code execution bug could be nasty. That’s why I still hope it’s local to my machine. But now to try to reproduce on other hardware. (for reference, hardware on which I saw the bug is a Dell Precision M6500 with a Core i7-740QM and an AMD/ATI Firepro 7820M video, with / on a Samsung PM830 SSD)

  • Ok, I can’t reproduce on my Precision M4300 with a Core 2 Duo T9300 and nVidia Quadro 360M video. However, I do notice some differences between my M6500’s login screen and the login screen of the M4300, notably the CentOS logo at bottom center. So, to do more digging……

  • Thanks for doing all this testing but it’s not really necessary in order to report the bug.. you know that, right?

    If you can share the original backtraces, it already helps and someone may even point you to a fix if it’s a known issue.


  • Ok, I have the vmcore, but the debuginfo for kernel
    3.10.0-229.1.2.el7.x86_64 I can’t find. Found and installed for kernel
    3.10.0-123.13.2.el7.x86_64 but that doesn’t help me troubleshoot the
    -229.1.2 kernel…..

  • It does reproduce on the M6500, but at least no corrupted libs this time. Karanbir, Johnny, where might I find the -229.1.2 kernel’s debuginfo package to get a backtrace from the vmcore I have from the panic?