Bug 860477 - nouveau Xorg crash following boot (GTX 580)
Summary: nouveau Xorg crash following boot (GTX 580)
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-25 22:39 UTC by Leif Gruenwoldt
Modified: 2015-06-29 11:40 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-29 11:40:53 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Xorg log (58.58 KB, text/x-log)
2012-09-25 22:39 UTC, Leif Gruenwoldt
no flags Details
dmesg (102.94 KB, text/plain)
2012-09-26 13:26 UTC, Leif Gruenwoldt
no flags Details
dmesg (5.40 KB, text/plain)
2013-06-11 21:15 UTC, Leif Gruenwoldt
no flags Details
Xorg log (49.90 KB, text/plain)
2013-06-11 21:16 UTC, Leif Gruenwoldt
no flags Details


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 54437 0 None None None Never

Description Leif Gruenwoldt 2012-09-25 22:39:20 UTC
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 23:53:32 UTC
Are you able to get dmesg output or /var/log/messages from after the hang?

Comment 2 Leif Gruenwoldt 2012-09-26 13:26:26 UTC
Created attachment 617559 [details]
dmesg

Comment 3 Adam Williamson 2012-10-04 17:31:31 UTC
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 18:30:23 UTC
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-09 00:08:41 UTC
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 18:20:06 UTC
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 23:34:00 UTC
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 23:34:29 UTC
18 beta is out, no point being NTH for it any more.

Comment 9 Martin 2013-06-11 16:39:43 UTC
Leif, are you able to reproduce it on latest Fedora 18 or 19?

Comment 10 Leif Gruenwoldt 2013-06-11 21:15:25 UTC
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 11 Leif Gruenwoldt 2013-06-11 21:16:28 UTC
Created attachment 759869 [details]
Xorg log

Comment 12 Leif Gruenwoldt 2013-10-11 13:56:56 UTC
"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 14:01:55 UTC
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 14:16:51 UTC
Listening in. 
Got similar problems on EN8600GT (NV50).
But problems coincide with

Comment 15 Spenk 2014-08-16 14:26:28 UTC
.. 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 21:41:06 UTC
(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 21:41:54 UTC
(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 08:47:21 UTC
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 11:40:53 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.