Red Hat Bugzilla – Full Text Bug Listing
|Summary:||nouveau Xorg crash following boot (GTX 580)|
|Product:||[Fedora] Fedora||Reporter:||Leif Gruenwoldt <leifer>|
|Component:||xorg-x11-drv-nouveau||Assignee:||Ben Skeggs <bskeggs>|
|Status:||CLOSED EOL||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||20||CC:||airlied, ajax, awilliam, bskeggs, bulk, robatino|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-06-29 07:40:53 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Leif Gruenwoldt 2012-09-25 18:39:20 EDT
Created attachment 617296 [details] Xorg log 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): xorg-x11-drv-nouveau-1.0.1-6.fc18.x86_64 # 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 How reproducible: Everytime. 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. Actual results: Hard lock. Mouse pointer won't move. Can't switch to ctrl-alt-f2. etc. Expected results: Reach responsive desktop. Additional info: Nouveau test day 2012-09-25 http://www.smolts.org/client/show/pub_39bd989c-98d9-4ee0-99ab-564373c756e3
Comment 1 Ben Skeggs 2012-09-25 19:53:32 EDT
Are you able to get dmesg output or /var/log/messages from after the hang?
Comment 3 Adam Williamson 2012-10-04 13:31:31 EDT
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.
Comment 4 Leif Gruenwoldt 2012-10-04 14:30:23 EDT
This is quite likely the same nouveau GTX 580 - F17 Common Bug. http://fedoraproject.org/wiki/Common_F17_bugs#Systems_hangs_on_X_startup_with_NVIDIA_GeForce_GTX_580_adapter_.28affects_installation.29 Bug #802026 The only difference is it's gotten worse with kernel 3.5.x, the nouveau.noaccel=1 trick no longer works.
Comment 5 Leif Gruenwoldt 2012-10-08 20:08:41 EDT
This looks like the upstream report for this issue https://bugs.freedesktop.org/show_bug.cgi?id=45517
Comment 6 Leif Gruenwoldt 2012-11-29 13:20:06 EST
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
Comment 7 Adam Williamson 2012-11-29 18:34:00 EST
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.
Comment 8 Adam Williamson 2012-11-29 18:34:29 EST
18 beta is out, no point being NTH for it any more.
Comment 9 Martin 2013-06-11 12:39:43 EDT
Leif, are you able to reproduce it on latest Fedora 18 or 19?
Comment 10 Leif Gruenwoldt 2013-06-11 17:15:25 EDT
Created attachment 759868 [details] dmesg Retested and still crashes seconds after reaching desktop in Fedora-19-Nightly-x86_64-Live-desktop-20130610.20-1.iso
Comment 12 Leif Gruenwoldt 2013-10-11 09:56:56 EDT
"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.
Comment 13 Leif Gruenwoldt 2013-10-11 10:01:55 EDT
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.
Comment 14 Spenk 2014-08-16 10:16:51 EDT
Listening in. Got similar problems on EN8600GT (NV50). But problems coincide with
Comment 15 Spenk 2014-08-16 10:26:28 EDT
.. 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.
Comment 16 Ben Skeggs 2014-08-16 17:41:06 EDT
(In reply to Leif Gruenwoldt from comment #13) > 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. 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.
Comment 17 Ben Skeggs 2014-08-16 17:41:54 EDT
(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.
Comment 18 Fedora End Of Life 2015-05-29 04:47:21 EDT
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' of '20'. 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.
Comment 19 Fedora End Of Life 2015-06-29 07:40:53 EDT
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.