was there some weird issue with the second last rawhide kernel? [DIAGNOSED?]

Adam Williamson awilliam at redhat.com
Fri Jun 20 20:04:32 UTC 2014


On Fri, 2014-06-20 at 14:32 -0400, Robert P. J. Day wrote:

>   if, however, i simply unplug the external monitor from HDMI, no
> problem, and i can plug in the monitor after booting. oh, and as
> before, once i'm running under this new (but clearly broken) kernel,
> when i go to shut down, massive kernel panic and stack trace.
> 
>   i can do more testing tomorrow, but this has now been an issue for
> the last three rawhide kernel releases. is no one else seeing
> something like this? more later ...

Issues like this are very hardware specific; it'd be very unusual for
there to be a bug which affected *any* system with an HDMI display,
because the code for dealing with HDMI displays attached to NVIDIA
adapters is entirely different from the code for dealing with HDMI
displays attached to Intel adapters or AMD adapters.

Even within a single driver, the code for different cards can differ
quite drastically. Your issue is almost certainly at *least* specific to
NVIDIA (it's very unlikely anyone with a different brand of video
adapter would see it). It's possible that it's also specific to the
NVIDIA hardware generation your card comes from, or even to your
specific card family or model.

(For example, the first few 3.16 kernels would not initialize graphics
correctly *at all* on my particular hardware...but you wouldn't have
seen that bug, as it was specific at least to the 'nv50' hardware
generation, and may possibly only have actually triggered on my
particular card).

So, anyway, what we'd need you to do is get logs and file a bug against
xorg-x11-drv-nouveau (see the explanation to poma as to why that's the
correct component). I don't *think* you're seeing the same bug as Dan
Mossor, as he hit his bug as far back as 3.13.

Getting the logs should be pretty simple. Boot the system, and edit the
kernel command line for one of the 3.16 kernels affected by the bug to
include the parameter 'drm.debug=15'. Boot it, and wait for the bug to
kick in. Now boot back to a working kernel, and do 'journalctl -b-1
> /tmp/crash.log'. Now the file /tmp/crash.log should have a full log
from the affected boot, including all the verbose debugging messages you
get by passing 'drm.debug=15', and you can attach that to your bug
report.

Let us know if you need any more help in filing the report.

You could in fact also/instead file the bug upstream at
http://bugs.freedesktop.org/ - I don't think the nouveau in Fedora's
3.16 kernels diverges at all from upstream, so the bug is very likely an
upstream one.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net



More information about the test mailing list