Created attachment 617296 [details]
Description of problem:
One or two seconds after boot gdm/gnome-shell hard locks. I see a backtrace in Xorg log.
Version-Release number of selected component (if applicable):
# uname -a
Linux localhost.localdomain 3.6.0-0.rc7.git0.1.fc18.x86_64 #1 SMP Mon Sep 24 13:15:40 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Steps to Reproduce:
1. Install test day image http://adamwill.fedorapeople.org/graphics_test_week_20120924/20120924-test_days-x86_64.iso
2. Live usb boot it.
Hard lock. Mouse pointer won't move. Can't switch to ctrl-alt-f2. etc.
Reach responsive desktop.
Nouveau test day 2012-09-25
Are you able to get dmesg output or /var/log/messages from after the hang?
Created attachment 617559 [details]
Discussed at 2012-10-04 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-04/f18-beta-blocker-review-2.1.2012-10-04-16.00.log.txt .
As this looks like a single-system X showstopper, we reject it as a blocker and accept it as NTH, by established precedent (X bugs that affect only a single system or small range of systems are not considered to be wide enough to be blockers; we don't have the development capacity to commit to fixing all such bugs).
There are other bugs reported that involve nouveau lockups - see https://bugzilla.redhat.com/show_bug.cgi?id=861646 for e.g. - but we cannot yet conclude that they all have the same cause. If there is a single bug causing lockups on multiple NVIDIA adapters that is a potential blocker and one bug should be nominated and (re-)proposed as as blocker.
This is quite likely the same nouveau GTX 580 - F17 Common Bug.
The only difference is it's gotten worse with kernel 3.5.x, the nouveau.noaccel=1 trick no longer works.
This looks like the upstream report for this issue
Two not so good workarounds.
1. Add "nomodeset" to your kernel boot parameters. (This left me at non native resolution and no multimonitor support)
2. Use the proprietary nvidia driver
leif: 'nomodeset' is essentially equivalent to saying 'I want to use vesa' these days. few video drivers have a UMS mode any more. nouveau does not. So if you disable KMS, you get the fallback driver - vesa.
18 beta is out, no point being NTH for it any more.
Leif, are you able to reproduce it on latest Fedora 18 or 19?
Created attachment 759868 [details]
Retested and still crashes seconds after reaching desktop in Fedora-19-Nightly-x86_64-Live-desktop-20130610.20-1.iso
Created attachment 759869 [details]
"yum remove xorg-x11-drv-nouveau" is probably the best workaround for this issue currently. llvmpipe is a bit sluggish for me, but gives a functioning GNOME desktop at least.
Btw, this GPU lockup still happens with Fedora 20 alpha (testday-2013-10-10.x86_64.iso).
Can we blacklist nouveau for this card? The out of the box experience (i.e. before removing nouveau driver) leaves a hung display seconds after reaching desktop.
$ glxinfo | grep "renderer string"
OpenGL renderer string: Gallium 0.4 on NVC8
I tried adding that string (prefixed with "-") to /usr/share/gnome-session/hardware-compatibility without any luck. Which drove me to removing nouveau package altogether.
Got similar problems on EN8600GT (NV50).
But problems coincide with
.. adding RAM.
I have been noticing corruption of the GDM background image though ever since I installed Fedora 20 x86_64. Can't remember that happening on Fedora 20 i686.
(In reply to Leif Gruenwoldt from comment #13)
> Btw, this GPU lockup still happens with Fedora 20 alpha
> Can we blacklist nouveau for this card? The out of the box experience (i.e.
> before removing nouveau driver) leaves a hung display seconds after reaching
> $ glxinfo | grep "renderer string"
> OpenGL renderer string: Gallium 0.4 on NVC8
> I tried adding that string (prefixed with "-") to
> /usr/share/gnome-session/hardware-compatibility without any luck. Which
> drove me to removing nouveau package altogether.
This issue should be fixed if you try a 3.17 kernel, there's one available in rawhide. The patches are FAR too invasive to safely pull back to earlier kernels at this early point.
(In reply to Spenk from comment #15)
> .. adding RAM.
> I have been noticing corruption of the GDM background image though ever
> since I installed Fedora 20 x86_64. Can't remember that happening on Fedora
> 20 i686.
This is a different bug, could you please file a new one with a full kernel log attached from after the corruption is present.
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 20 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.