On 04/02/2015 07:29 AM, Marcelo Ricardo Leitner wrote:
If it's that easy to reproduce, please grab the panic message or generate a vmcore through crashdump and report it at bugzilla.redhat.com against kernel component.
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.
You may be using an EPEL application but kernel shouldn't be panicking like that, specially if you're running it as an user.
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)