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)