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)
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
