Description of problem: gnome-shell will only run in fallback mode on a Nvidia GT520 graphics card (which has a NVD9 chipset) During X start-up, this error is logged in Xorg.0.log ---- [ 9.067] (EE) NOUVEAU(0): Error creating GPU channel: -19 [ 9.067] (EE) NOUVEAU(0): Error initialising acceleration. Falling back to NoAccel ---- The gnome-shell session starts, but in fallback mode, with no 3D acceleration and without the new GUI. This only happens using the nouveau drivers. If I use the proprietary nvidia drivers, gnome-shell starts correctly in the regular (non-fallback) mode. Version-Release number of selected component (if applicable): nouveau rpm = xorg-x11-drv-nouveau-0.0.16-27.20110720gitb806e3f.fc16.i686 How reproducible: Always Steps to Reproduce: 1. Install FC16 using on system with Nvidia GT520 2. login to a gnome session Actual results: gnome-shell starts in fallback mode Expected results: gnome-shell starts in beautiful glitzy mode Additional info: I also see this warning in Xorg.0.log ---- [root@speedy log]# grep AIGLX Xorg.0.log [ 8.754] (==) AIGLX enabled [ 9.078] (II) AIGLX: Screen 0 is not DRI2 capable [ 9.078] (II) AIGLX: Screen 0 is not DRI capable [ 9.162] (II) AIGLX: Loaded and initialized swrast ----- This page refers to that warning, which might be relevant: https://jeremy.visser.name/2009/10/no-dri-on-x-org-with-a-radeon-check-your-virtual-size/ According to that page "because of various technical reasons, when the Virtual size is too big (which, evidently, 2048×2048 is), DRI gets disabled" I believe when DRI is disabled, gnome-shell will run in fallback mode. When I check the default "Virtual" size on my display it is larger than 2048x2048 ------ [root@speedy log]# xrandr Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192 ------ Could this large "Virtual" size be causing DRI to get disabled? I checked this page http://nouveau.freedesktop.org/wiki/InstallDRM#Firmware It has this comment for NVD9 chips "free firmware in development, still needs proprietary firmware". However, if I search /var/log/messages, it does not indicate that it's trying to request any firmware, so that comment might be out of date. I will attach Xorg.0.log
Created attachment 547553 [details] Xorg.0.log showing startup into fallback mode
The comment isn't out of date. I haven't included the code to enable acceleration on GF119 (which we call NVD9) in F16 yet. Firstly, the comment is correct and it will only work with proprietary firmware at this point. Secondly, apparently even *with* the firmware on some NVD9 chips it doesn't work and just locks up. I'm working on it upstream, and as soon as I have a viable solution that will actually work, the support will land in F16.
I get the same error messages in Xorg.0.log under Fedora 16 with my GeForce GT 610, which also is based on the NVd9 chip. [ 30.763] (EE) NOUVEAU(0): Error creating GPU channel: -19 [ 30.763] (EE) NOUVEAU(0): Error initialising acceleration. Falling back to NoAccel So I tried Fedora 18 beta + updates. Same error. I have not tried supplying firmware. The nouveau front page still calls out the NVd9 for firmware issues, but the firmware status section does not. I infer that proprietary firmware is no longer needed. I suspect that error -19 is -ENODEV (no such device). Should this bug report be updated to apply to Fedora 18 beta? Ben Skeggs: what's the status of this?
The issue is still the same, no-ones been able to figure out yet *why* our own firmware doesn't work.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 WONTFIX if it remains open with a Fedora 'version' of '16'. 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 prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 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 to click on "Clone This Bug" and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Ben: Could you change the version to Fedora 18? That seems better than my cloning this bug. Thanks.
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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. Thank you for reporting this bug and we are sorry it could not be fixed.