Description of problem: gnome-shell does not display correctly with my Nvidia Geforce FX 5200. The top bar is multi-colored and the text on it is scrambled. The text is also scrambled in the menu under my name and in the list of application categories. Also the logo in the GDM logon screen is scrambled. Version-Release number of selected component (if applicable): xorg-x11-drv-nouveau-0.0.16-27.20110720gitb806e3f.fc16.x86_64 How reproducible: always Steps to Reproduce: 1. boot the machine 2. logon 3. Actual results: The top bar is multi-colored and the text is scrambled Expected results: The top bar should be black and the text legible. Additional info: This worked in Fedora 15.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please add drm.debug=0x04 to the kernel command line, restart computer, and attach * your X server config file (/etc/X11/xorg.conf, if available), * X server log file (/var/log/Xorg.*.log*; check with grep Backtrace /var/log/Xorg* which logs might be the most interesting ones, send us at least Xorg.0.log) * output of the dmesg command, and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 527804 [details] Output of dmesg after logging in to gnome-shell, booting with drm.debug=0x04.
Created attachment 527805 [details] Xorg.0.log after logging on with drm.debug=0x04
Created attachment 527806 [details] System log
I have submitted the requested info. I do not use an xorg.conf.
I've seen multiple other reports of this corruption with FX 5xxx era cards, including: http://forums.fedoraforum.org/showthread.php?t=272157 I've asked the reporters in that thread to add their data here. Marking as triaged and upping the severity a bit. Ben suspects this is down to mesa. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 753394 has been marked as a duplicate of this bug. ***
*** Bug 746826 has been marked as a duplicate of this bug. ***
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Hello, I have the same problem in FC16 with Gnome 3 as sfsheldo, in my case with a FX5500 nVidia Card. At the suggestion of AdamW, who replied on my question in: http://forums.fedoraforum.org/showthread.php?t=272157 I send some data: My computer: Processor: AMD Athlon(tm) XP1500 (AMD XP 2,2 Ghz Boxed) Memory: 1003 MB. My Video Card: VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5500] (rev a1) (prog-if 00 [VGA controller]) Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at de000000 (32-bit, non-prefetchable) [size=16M] Memory at c0000000 (32-bit, prefetchable) [size=256M] Expansion ROM at dfee0000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: nouveau Kernel modules: nouveau, nvidiafb My kernel: [gastonv@gastonv ~]$ uname -a Linux gastonv 3.1.4-1.fc16.i686 #1 SMP Tue Nov 29 12:46:54 UTC 2011 i686 i686 i386 GNU/Linux Removing gnome-shell and with that I can work in Xfce properly. Many thanks in advance, Gaston Verhulst.
I have done a test making a xorg.conf file: Xorg :1 -configure cp /root/xorg.conf.new /etc/X11/xorg.conf and change one section, adding Option "Accel" "False": Section "Device" ### Available Driver options are:- ### Values: <i>: integer, <f>: float, <bool>: "True"/"False", ### <string>: "String", <freq>: "<f> Hz/kHz/MHz", ### <percent>: "<f>%" ### [arg]: arg optional #Option "SWcursor" # [<bool>] #Option "HWcursor" # [<bool>] #Option "NoAccel" # [<bool>] #Option "ShadowFB" # [<bool>] #Option "VideoKey" # <i> #Option "WrappedFB" # [<bool>] #Option "GLXVBlank" # [<bool>] #Option "ZaphodHeads" # <str> #Option "PageFlip" # [<bool>] Option "Accel" "False" Identifier "Card0" Driver "nouveau" BusID "PCI:1:0:0" EndSection With this a have Gnome3 with a correct to bar, but without Gnome 3 icons. Only pup-up menus for Applications and Locations. With this configuration i don't have good results in order to play video streams. So, awaiting a solution, I go back to Xfce-desktop.
Gaston: what that does is simply disable acceleration for the adapter, which as a consequence gives you GNOME's fallback mode rather than the 3D-accelerated Shell, hence working around the bug. You could use fallback mode without disabling acceleration - go to System Settings, System Info, Graphics, and toggle the Forced Fallback Mode switch. That'll make GNOME always use its fallback mode, until you toggle it back again. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Hello Adam, I have installed Gnome 3 again with yum install gnome-shell. gnome-shell.i686 3.2.1-2.fc16 @fedora After restart, the Google top bar and the pop-up menus are perfect readable on a black background. Then I have toggled Gnome Forced Fallback Mode. From now I can watch the video-streams very well. I have to thank you very much for the hint. Now I am in Google 3 with Pop-up menus on the top bar and only one window indicator right under corner. Please how can I get the original gnome 3 icons instead? Thanks in advance, Gaston.
You can't really get all the features of Shell in fallback mode. If you have specific questions about customizing the layout in fallback mode it'd be best to ask them on the user mailing list or on the forums, rather than in a bug report. thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 760837 has been marked as a duplicate of this bug. ***
I updated my system with the Geforce FX 5200 card to rawhide to try out "gnome-shell for everyone". In the course of experimenting with that I booted in runlevel 3 with nouveau enabled, and started X with startx. Everything that I complained about (except for the gdm logo of course) looked great. I rebooted into gdm, logged on, and things looked bad. I rebooted again into run level 3, did startx, and things looked good again.
latest 3.1.5-2.fc16.i686.PAE kernel provides a black band at login, and no improvement on Gnome (I think that it is worst) Not happy, as it was working as a charm in F15, and no real improvement since reporting
I made same experiment as per comment #18 everything is o.k, but you are not in Gnome3 but in fallback mode (i.e. Gnome 2) Anyone working on this bug?? Working on a 32bit
in case it's useful info, update to kernel-3.1.5-6 and mesa-* 7.11.2-1 doesn't appear to have made a difference on my FX5500 on F16 32-bit.
I confirm comment #20 that run-level 3 does not give you gnome-shell in Fedora 16. I installed Fedora 16 onto an external USB disk to test this.
When I ran startx on my system with rawhide, the graphics were on llvmpipe, not nouveau, according to system info.(In reply to comment #18) > I updated my system with the Geforce FX 5200 card to rawhide to try out > "gnome-shell for everyone". In the course of experimenting with that I booted > in runlevel 3 with nouveau enabled, and started X with startx. Everything > that I complained about (except for the gdm logo of course) looked great. I > rebooted into gdm, logged on, and things looked bad. I rebooted again into run > level 3, did startx, and things looked good again. I checked this again, and it turns out that with startx the graphics are provided by llvmpipe rather than nouveau.
if bug is connected to nouveau driver, I do not see any activity on that package. Shall be this bug marked as irresolvable for this release??. Last package was released in August
I have the same issue with a classroom of computer with the FX 5200 cards, one thing that I found that was interesting. If I use gnome-tweak-tool, and go to the font settings, and then changed the text scaling to another value, and then changed it back to 1.0, it would display the text in the top panel/bar correctly, but this would only work for that session. Logging in again would have it broken. Also, I see the same problem with the top panel/bar on the sign in screen most of the time, but once and awhile it will show as a black bar with the text fine. Also, the Fedora log displays as scrambled colors on the sign in screen with various sizes? Tried both an upgrade install on machines and a clean install.
antonio: there isn't much interesting code in the xorg-x11-drv-nouveau package any more: with KMS drivers, almost all the interesting code is in the kernel and in mesa. This is why xorg-x11-drv-{nouveau,ati,intel} get updated relatively infrequently - there just isn't much changing in there. However, we continue to use these components as convenient places to lodge all the bug reports for each entire driver 'stack' - even if the actual code that needs to be changed is in the kernel, it's usually better to have the bug filed against xorg-x11-drv-nouveau, as that's where people tend to look and it makes sure the bug gets assigned to the correct maintainer. If you look in the kernel changelog for entries from Ben Skeggs, you'll see where the 'real' work happens. Ben is aware of this bug and was trying to work on it last I heard, but the fact that he doesn't have an affected adapter makes it harder. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Thank you for the update, Adam. Lately things have gotten worse in Rawhide. Application windows display as completely black, including the window decoration. The stuff in gnome shell, including the dash, the workspace selector, and the application icons display correctly, however.
Adding the following script to the start-up programs (gnome-session-properties) helps a bit. Artifacts *will* appear again, though: #------------------------------- CUT HERE ------------------------------------ #!/bin/sh STARTED=`grep -i "GNOME Shell started" ~/.xsession-errors` while [ -z "$STARTED" ] do sleep 1 STARTED=`grep -i "GNOME Shell started" ~/.xsession-errors` done gsettings set org.gnome.settings-daemon.plugins.xsettings active false gsettings set org.gnome.desktop.background show-desktop-icons false sleep 1 gsettings set org.gnome.settings-daemon.plugins.xsettings active true gsettings set org.gnome.desktop.background show-desktop-icons true #------------------------------- CUT HERE ------------------------------------ Hope this helps (at least a bit)
Some notes: 1) We cannot install proprietary driver since RPMFusion doesn't support legacy driver any longer 2) since all distributions are affected from this bug, I have no doubt that an adapter will be available 3) from a comment, I understand that things are growing worst in rawhide What can we do to help the maintainer?? can we help providing any test???
(In reply to comment #26) > Ben is aware of this bug and was trying to work on it last I heard, but the > fact that he doesn't have an affected adapter makes it harder. Hi Adam, thanks again for the update. are you saying Ben doesn't have access to a FX5200 or FX5500 card? i can provide one if needed - as long as Ben has access to a PC with an AGP slot. regarding inactivity, i had a look on the nouveau wiki and found this comment in a presentation linked from the most recent news item: "nvfx (NV30,40): gallium driver. Works but no maintainer." (presentation attributed to Martin Peres, Ben Skeggs et al, dated sep 13 2011) is that relevant and still true? "no maintainer" sounds worrying.
cje: yes, that's correct. It would probably help Ben to have access to an affected card indeed; he's located in Australia, though, if that makes it harder for you to send him the card. Ben, any thoughts? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I have a few NV3x boards, just my AGP machine has died. I played with the issue a little last week at a friend's house and tracked the breakage down to a range of koji builds, I haven't yet been able to determine the exact cause of the breakage or a solution. "No maintainer" is unfortunately correct. I have a rewrite of the NVFX driver pending that is actually maintainable, but it's not finished and currently blocked on some massive changes to nouveau's userspace code (which will address the various "fail ttm_validate -12" bugs on low-memory cards. I fully intend on finishing the rewrite once this is complete.
Some additional things. I have set the force-fallback mode to get the desktop get it to work. The gnome3 would come up, but the top bar/panel was messed up, and the fonts on the right after the activating of the icons would be messed up. This could be fixed by setting the font scaling to something, and then back, but would not stay after a logout. The force-fallback fixed the desktop, but the sign in screen would about 75% of the time come up with the graphical box in which it would have the rounded corners, but the graphic would not show up ok, and the top bar would be messed up. Found the difference in the process was caused by these lines in the :0-greeting.log file. gnome-session[1615]: DEBUG(+): fill: *** Launching helper 'bash -c 'gnome-shell --help | grep -q gdm-mode && /usr/libexec/gnome-session-check-accelerated'' to know if session is runnable gnome-session[1615]: WARNING: Session 'gdm-shell' runnable check failed: Timed out When this failed with the Timed out, the sign in screen would show up as the older square corner box, and the graphic and top bar show up fine. Did some testing, and found that setting the grub.cfg file with the additional options of nouveau.modeset=0. Also, tried this with the fdblacklist=nouveau but found it worked fine without that. May be that it causes that, but for now. That gets it to always come up with the square sign in screen with graphics. Not sure why it sometimes timed out and other times doesn't? Ideally, would like to get the gnome3 to work 100%, but this is the best solution that I have found for my needs in my classroom. Thanks.
Adam and Ben: many thanks for the updates - it's good to know what's going on! "tracked the breakage down to a range of koji builds" was going to be my next move too. perhaps i can help with the next step? can you tell me what range of builds you narrowed it down to and which packages you were looking at? do you think experienced (but not necessarily in GFX drivers) programmers and other testers might be able to help with the "massive changes to nouveau's userspace code"? can you provide a link to that work? thanks again. i hope it doesn't feel like i'm nagging - i'm well aware that there's lots of nvidia cards but there's only one Ben Skeggs! :-)
setting nouveau.modeset=0 will result in the nouveau driver not being used at all; it has no UMS code any more. You will get the vesa driver. Obviously you won't hit this bug, but you'll have no kind of acceleration at all. Just FYI.
Thanks for the info on what the nouveau.modeset=0 does. Originally, I had found a link that said to have the nouveau blacklisted and to have the nouveau.modeset=0 that also worked, but then tried it with just the modeset option, and it still worked. But now at least it isn't getting the scambled graphics.
I see some activity on the nouveau mailing list that seems connected to this bug and nvfx code. Is it correct??
5 months since been reported: no improvement and no activity. Any update??
antonio: comment #32 is the status update. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Why no one posted any screenshots in here? I believe this is a dupe of bug 802069 (or vice versa, but that one at least has some screenshots attached).
I confirm that bug 802069 is a dupe of this bug. Nobody posted a screen-shot as it was clear what is happening from other forums and the problem is under investigation in nouveau world :-)
*** Bug 802069 has been marked as a duplicate of this bug. ***
802069 was proposed as a Beta blocker, so transferring that nomination here. It is a reasonable proposal, as this really does cause major issues for a pretty wide range of cards. We released F16 with this bug but we weren't truly aware of the breadth of impact at the time. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
To reiterate, we have seen this bug on NV43, NV44 and NV34 card.
Created attachment 570410 [details] example screenshot from nv43
Discussed at 2012-03-16 blocker review meeting. Accepted as a beta blocker per criterion "after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied", in the case of NV3x / NV4x cards. Note that blacklisting these cards from running Shell is a perfectly acceptable way to address the bug; we're not requiring that the driver be fixed before Beta release. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Ben, desktop team - can you please come up with a blacklist for this? This is a beta blocking bug, and Beta compose date is scheduled for Thursday, so we really need a build in and update proposed by then. Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 571511 [details] Patch to blacklist all NV30 and NV40 cards driven by Gallium NVFX I have no way of testing this, but I think it is correct.
Thanks, Tom. I just looked carefully through all the reports and noticed a couple of things: * All the NV3x reports are actually specific to the NV34: there's none for NV30, NV31, NV35 or NV36. I do have a theory to explain that, though - the NV34 cards look by far the most common, they're the lower-end ones. The others seem to be higher end and workstation cards, which are less likely to be in use these days. If all you want is a graphics card it's to be expected you might still be using an FX 5200. But if you're the kind of person who bought a FX 5800, you're highly likely to have upgraded to a newer high-end card by now. * The NV4x (NV43 and NV44 are the models that have specific reports) corruption looks, to me, a little different from the NV3x corruption. There's no 'rainbow effect' on the dash, and the font corruption looks somewhat different - the NV4x screenshots show the text as somewhat garbled and with blank areas. The NV3x screenshots look more like there's colored garbage being rendered over the text, there aren't blank spots. I'm *somewhat* suspicious that we don't have reports from other NV4x hardware, but then, I haven't looked yet. I'm going to take a look through the nouveau bug list now, and see. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 767337 has been marked as a duplicate of this bug. ***
767337 shows the NV4x-style corruption on a "nVidia Corporation C68 [GeForce 7025 / nForce 630a] (rev a2)" - so that's another in the NV4x series confirmed to be suffering from this bug, it's listed as the NV68 at http://nouveau.freedesktop.org/wiki/CodeNames#NV40 , but part of the NV40 family - and a "HP DV6000" laptop, no graphics hardware info given...HP seem to have sold various laptops under this name, with quite a range of NVIDIA hardware, so we can't tell what chip that one has. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 753689 has been marked as a duplicate of this bug. ***
https://bugzilla.redhat.com/show_bug.cgi?id=752840 shows rather *worse* corruption with an NV4E. It seems so much worse it may not actually be the same bug, but it's another NV4x chip with a clear corruption issue. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
So, I went through the whole list of nouveau reports, and I don't see as many reports of this on NV4x hardware as I would expect if it truly hit all those cards. I also talked to bodhi_zazen, who has an NV42, with a somewhat different rendering issue - see https://bugzilla.redhat.com/show_bug.cgi?id=735893 . He's active on #fedora-qa IRC. He says he does *not* see this bug - he has that wacky shadow issue, but he does *not* see garbled text rendering in Shell. So that seems to definitely indicate that at least some NV4x hardware does not hit the specific type of corruption we're discussing in this bug.
Created attachment 571530 [details] Screen shot of gnome-shell on F17 on my FX5200 (NV34)
I have attached a screen shot on my FX5200 with F17. The white square is the system settings window. The FX5200 is one of the last Nvidia AGP cards available. I got mine 2 years from Amazon.
I applied the patch in attachment 571511 [details]. GDM came up in fallback mode, and when I logged in, my session was in fallback mode. I got a message "Gnome 3 failed to load ...". The second time I logged in I did not get that message, and it still was in fallback mode. I am a little disappointed I did not get llvmpipe.
Copying this in here from the mailing list: Using NVidia GeForce FX 5600 in HP laptop: On either F17-alpha or F17-beta-tc?: I click on Activities and see a vertical left menu plus a horizontal menu with tabs Windows | Applications. I scroll through Applications and start a Terminal. All I get is a transparent box with no prompt. I can see an ibeam pointer so I try typing text. Nothing. So next I try to start Firefox. All I get is a blank white box.
I posted a forum thread to try and get us some more data on affected hardware, here. I'm not yet totally convinced this really hits all NV40 family adapters. http://forums.fedoraforum.org/showthread.php?t=277844 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
sfsheldo: yes, right now blacklisted cards are a corner case where you wind up with fallback mode not llvmpipe. I believe there are plans to fix that, but I'm not sure if there's a time frame. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
As I posted in the forum thread, I have been running F16 and Gnome shell on a NV4B card ever since the alpha, and have not seen any hint of this corruption. [Me@tower11 ~]$ glxinfo | grep render direct rendering: Yes OpenGL renderer string: Gallium 0.4 on NV4B Now this does look like some corruption I have seen in the past on the NV4B and even a FX 5200 card when the fan died and the GPU started overheating. Possibly it could be a heat related issue??
Okay, so I just talked to Ben about this. We've got some reports already of NV4x which are not hitting corruption. Ben agrees with me that the NV3x cases and NV4x cases look somewhat different. So, we're going to split this bug back up. This bug is now for *NV3x corruption only*. I will, for now, re-open https://bugzilla.redhat.com/show_bug.cgi?id=802069 for the NV4x cases, and request more information there. We suspect that those cases may actually be dupes of https://bugzilla.redhat.com/show_bug.cgi?id=770197 , the bug for corruption due to VRAM exhaustion - Ben says even some cards in the NV4x generation have rather small amounts of VRAM. As far as this bug goes, Ben will try to come up with an actual fix at the weekend. Until then, as far as this bug goes, we recommend blacklisting NV3x chips only: NV3[0-9A-F] Ben does also know of an ugly hack which would 'fix' the low-VRAM cases at the expense of making all GL rendering slower.
So now we really just need to construct the blacklist. Can someone please provide a patch for gnome-session? I'd do it, but my regexp foo is weak and I fear screwing it up. We want to blacklist NV3[anything]. The actual renderer string would be "Gallium (version) on NV3x". -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I follow this interesting discussion since my comment 12 on 2011-12-07, where I said that the problem happens in FC16. In that comment, I was forgotten to report that the problem did not happen in FC15, in which Gnome 3 was introduced for the first time. Thus, in FC15 I used Gnome 3 successfully. Sorry for the late remark. Greetings,
Thanks, Gaston - yep, we're aware it's a regression, in fact a while back Ben managed to isolate it to a specific range of builds: https://bugzilla.redhat.com/show_bug.cgi?id=745202#c32 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Gaston, I reported that it was o.k. on FC15 on comment 19 ;-)
I have submitted a new gnome-session build which should blacklist the affected adapters: https://admin.fedoraproject.org/updates/gnome-session-3.3.92-2.fc17 I won't mark it as fixing this bug as it doesn't, it just works around it. But it can be considering as 'addressing' the bug for blocker purposes. Please, anyone with an NV3x adapter, grab that gnome-session and check that you get fallback mode. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Hello, Trying to install that new gnome-session, I think /lib/libsystemd-login.so.0 is not on the right place, not in the right directory: [root@gastonv Downloads]# rpm -Uhv gnome-session-3.3.92-2.fc17.i686.rpm fout: Failed dependencies: libsystemd-login.so.0(LIBSYSTEMD_LOGIN_38) is needed by gnome-session-3.3.92-2.fc17.i686 gnome-session = 3.2.1-2.fc16 is needed by (geïnstalleerd) gnome-session-xsession-3.2.1-2.fc16.i686 [root@gastonv Downloads]# locate libsystemd-login.so /lib/libsystemd-login.so.0 /lib/libsystemd-login.so.0.0.6 [root@gastonv Downloads]# yum list installed | grep gnome-session gnome-session.i686 3.2.1-2.fc16 @anaconda-0 gnome-session-xsession.i686 3.2.1-2.fc16 @anaconda-0 Thanks in advance, Gaston.
I installed the packages referenced in comment 68, using "yum install". After logging out and in, I get gdm-fallback mode and fallback mode in my acccount, so I think the packages "address" the issue. Thanks.
shall it be backported to F16??
gaston: try 'yum localinstall gnome-session-*' (so it uses yum to resolve deps, and installs both the gnome-session packages at once, which you want to do) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
antonio: if we get a patch we're happy with for a stable release and which seems to work, yeah. 17 is the priority right now as we're on a tight schedule for the beta.
If anyone with a card affected by this bug is around and free to test in the next hour or so, please post back or even better drop by #fedora-devel on Freenode IRC; we're working on a different way to do this, as a patch to mesa, which would also fix the 'low VRAM' cases, and need testers. thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I can test with my NV34 fx 5200 card over the next hour. I don't do Freenode IRC, however.
OK, can you folks please *downgrade* gnome-session to 3.3.92-1 or earlier, and install this mesa build: http://koji.fedoraproject.org/koji/buildinfo?buildID=309217 and let us know the results? It should have the same ultimate effect: you should get fallback mode. Thanks!
Adam: Reply on Comment 72. I receive the following error: Have I done something wrong? I tried also 'yum --skip-broken localinstall gnome-session-*' without success. [root@gastonv Downloads]# ls gnome-session-3.3.92-2.fc17.i686.rpmgnome-session-3.3.92-2.fc17.i686.rpm [root@gastonv Downloads]# yum localinstall gnome-session-*Loaded plugins: langpacks, presto, refresh-packagekit Setting up Local Package Process Examining gnome-session-3.3.92-2.fc17.i686.rpm: gnome-session-3.3.92-2.fc17.i686 Marking gnome-session-3.3.92-2.fc17.i686.rpm as an update to gnome-session-3.2.1-2.fc16.i686 Resolving Dependencies --> Running transaction check ---> Package gnome-session.i686 0:3.2.1-2.fc16 will be updated --> Processing Dependency: gnome-session = 3.2.1-2.fc16 for package: gnome-session-xsession-3.2.1-2.fc16.i686 ---> Package gnome-session.i686 0:3.3.92-2.fc17 will be an update --> Processing Dependency: libsystemd-login.so.0(LIBSYSTEMD_LOGIN_38) for package: gnome-session-3.3.92-2.fc17.i686 --> Finished Dependency Resolution Error: Package: gnome-session-3.3.92-2.fc17.i686 (/gnome-session-3.3.92-2.fc17.i686) Requires: libsystemd-login.so.0(LIBSYSTEMD_LOGIN_38) Error: Package: gnome-session-xsession-3.2.1-2.fc16.i686 (@anaconda-0) Requires: gnome-session = 3.2.1-2.fc16 Removing: gnome-session-3.2.1-2.fc16.i686 (@anaconda-0) gnome-session = 3.2.1-2.fc16 Updated By: gnome-session-3.3.92-2.fc17.i686 (/gnome-session-3.3.92-2.fc17.i686) gnome-session = 3.3.92-2.fc17 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
Replying to Adam's comment 76: I downgraded gnome-session, and installed the 6 relevent mesa packages in koji. Here is what I have now: [steve2@sfs-ath ~]$ rpm -qa 'mesa*' mesa-libGLU-8.0.1-7.fc17.x86_64 mesa-libGL-8.0.1-7.fc17.x86_64 mesa-dri-drivers-8.0.1-7.fc17.x86_64 mesa-libGLES-8.0.1-7.fc17.x86_64 mesa-dri-filesystem-8.0.1-7.fc17.x86_64 mesa-libGL-devel-8.0.1-7.fc17.x86_64 [steve2@sfs-ath ~]$ rpm -qa 'gnome-session*' gnome-session-xsession-3.3.92-1.fc17.x86_64 gnome-session-3.3.92-1.fc17.x86_64 I logged off, and logged on, and I did NOT get fallback mode. GDM was in shell mode, and so was my account. I rebooted just to make sure, and still no fallback. ~ ~ ~ ~ ~ ~ "note" 16L, 589C
thanks. ajax will try and figure out what's wrong. I think we're going to go ahead and do RC1 with the gnome-shell solution. If there's an RC2, we could pull the mesa solution into that if we fix it up. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
adamw: I tested my old nvidia card as requested by you on IRC. Tested Fedora 17 , Beta RC1 , gnome-desktop I do not have the problem , my problem is worse. I get a jumbled, pixilated, multi-colored screen -> white screen. When I re-start X , the log in screen is displayed without any problem , text is fine. When I log in as the live user -> pixilated multi-colored screen of death.
huh. gaston: oh, I forgot you're on F16, sorry. You won't be able to use the F17 packages on F16, sorry. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Adam: and I did not have seen that it was a rpm for FC17. No problem and thanks for the fine communication.
Using gnome-session-3.3.92-2.fc17 on NV43 does not start fallback mode automatically and it does not fix the rendering issues.
kamil: that's expected. as I wrote, we decided not to lump the NV3x corruption and VRAM exhaustion issues together, and the patch I added only blacklists NV3x adapters, not NV4x. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Can anyone with an NV3x (not an NV4x or anything else) please confirm that Beta RC2 boots to fallback? Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I updated my system with the NV34 card this morning to the latest 3.4.0 stuff and mesa*-8.0.1-9 (maybe that is beyond RC2), and it booted to fallback.
Those packages match what was in RC2, so that's a good test. Anyone else? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
My LiveCD tests on a GeForce FX 5500 [NV34] 256MB PCI F15 - Good F16 & F17Alpha - Bad F17BetaRC2 - Fallback Mode :(
fallback mode is intended. we don't have a fix for the corruption yet. the intention for rc2 is to force fallback mode on these cards. thanks for testing. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Discussed again at 2012-04-03 emergency blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting/2012-04-03/fedora-meeting.2012-04-03-23.08.html . We agreed that we have sufficient confidence now that the blacklist included in Beta RC1 and RC2 works as intended. That doesn't mean the bug is fixed, as the *bug* is the bad rendering of Shell; the blacklist is just a workaround. But it does mean this bug is no longer a release blocker, so we agreed to drop that status. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I tried the Beta-RC3 live cd on my system with the NV34 card. After a little flailing around, it came up in fallback mode, but I did not see any icon in the menus or on the desktop to do the installation. I knew the command was "liveinst" and I tried that, and it did its thing.
*** Bug 811914 has been marked as a duplicate of this bug. ***
FYI patch from attachment 571511 [details] resolves the problem on my NV40.
I just revived a desktop machine with a nv34 card. Here is what I did to get an acceptable gnome-shell experience on it: 1. add export LIBGL_ALWAYS_SOFTWARE=1 export CLUTTER_DEFAULT_FPS=15 export CLUTTER_VBLANK=none to my .bashrc 2. remove the NV3 line from /usr/share/gnome-session/hardware-compatibility This makes the desktop work ok for me. Of course, we really need this to happen automatically in gnome-session (if the hardware-compatibility list matches, force software rendering).
I do not find /usr/share/gnome-session/hardware-compatibility in my F16!!! I was eager to test
Oh, sorry. My comment was about F17
The bug was reported against 16, then all work is for 17 and no change in version. Furthermore, it means that comment #94 cannot be backported to 16.
The solution in comment #94 worked for me with my NV34 card on F17. gdm came up slightly corrupted with the nouveau driver, but after I logged on my session displayed the gnome shell very well. It was using llvmpipe. It also was using a lot of cpu.
I applied comment #94 to my F17 system an it worked. In /usr/share/gnome-session/hardware-compatibility I left softpipe uncommented instead of llvpipe. Does it make any difference??
There is a build of mutter for BZ813648 that fixes the window content problem I attached a screen shot of in comment #57. The text in the panels and some dialog boxes is still scrambled.
I tried a fresh install of rawhide with my FX 5200 card. After I installed mutter from F17, things worked pretty well. Rawhide has mesa-8.1. Is there any chance that the nouveau driver from that will be backported to F17?
Hi all, on F17 with FX5200 card, I get a gnome shell experience using the comment [#94]. Many thanks
I think that it necessary to resume the situation of this bug, not easy for a newcomer to understand where we are and what is going to happen, and what to test.
(In reply to comment #104) > I think that it necessary to resume the situation of this bug, not easy for a > newcomer to understand where we are and what is going to happen, and what to > test. Many millions of laptops were sold with these NV3x cards around 2004-2006. I own one of these laptops. Still perfectly serviceable. 3.2ghz cpu. It would be good if these NV3x cards could be fully supported without having to jump through a bunch of workarounds and special settings. .
Just wanted to add that I'm experiencing this problem as well with a nVidia Quadro NVS 285 (NV44). I ended up disabling noveau and installing the nvidia drivers.
I am getting text artifacts (but not rainbow textures) with 64-bit F18, kernel 3.6.0 rc7 and a NVC3 card (555M). Should I file a new bug?
Ben, what's the status on this?
I'm sorry I don't have any more to add that box is on RHEL and in production now
Sorry, I meant Ben Skeggs, the nouveau maintainer :)
I updated my F18 installation this morning and tried it with my NV34 card. I had to comment out the workaround in /usr/share/gnome-session/hardware-compatibility to get gnome-shell to work. Things are still broken. In particular, the menu under my name is white on transparent, and when I click on the checkerboard in the dash, the "all applications" icon display is messed up. When I click on an individual category, the icons are displayed correctly. I will attach a screenshot.
Created attachment 619974 [details] Screenshot of gnome-shell on F18 o9n my FX5200 (NV34)
I'm obviously not Ben, but I think if I also speak for him when I say the NVFX driver is not in fixable state. NVFX got replaced in mesa 9.0 with a completely rewritten driver which should hopefully fix the problem at hand, or if not is at least fixable. I don't really know what mesa version Fedora 18 will ship, the images so far included 8.1, but there are packages for 9.0 already on koji. The right thing to do here is blacklist NVFX for gnome shell. Sadly we are not exposing the 3D driver name in any way (the new driver is called nv30), so the blacklisting has to take the mesa version into account.
When I did my F18 test, I had the following mesa components, which I installed from fedora-updates: mesa-libxatracker-9.0-0.3.fc18.x86_64 mesa-libglapi-9.0-0.3.fc18.x86_64 mesa-dri-filesystem-9.0-0.3.fc18.x86_64 mesa-libEGL-9.0-0.3.fc18.x86_64 mesa-libgbm-9.0-0.3.fc18.x86_64 mesa-libGL-9.0-0.3.fc18.x86_64 mesa-dri-drivers-9.0-0.3.fc18.x86_64 mesa-libGLU-9.0-0.3.fc18.x86_64 I think the nv30 driver still needs some work.
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 . Stephen's test gives us some indications here, but just to be sure, we clearly need more information: * Does Mesa 9.0 fix this? * Does Mesa 9.0 change the renderer string such that our blacklist doesn't work any more? * Does blacklisting in F18 give you fallback mode or llvmpipe Shell? If Mesa 9.0 fixes this, obviously, we should dump the blacklist. If it doesn't fix this, we should ensure the blacklist still works. Mesa 9.0 has been stable since September 25 so any updated F18 system should have it, as should F18 Beta TC1: http://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC1/ . Just to confirm Stephen's test, can those affected by this grab TC1 and check if a) the blacklist still works and b) whether Shell works if they disable the blacklisting in /usr/share/gnome-session/hardware-compatibility ? Then we can determine the status of this bug. Ben (Skeggs), please advise if any of the above is incorrect.
In reply to comment #115, the blacklist still works on F18 with mesa 9.0. With the blacklist, gnome comes up in fallback mode. The "multicolor corruption of panel" is gone, but the menu and the icon display are messed up for me as I described in comment #111 and shown in the attachment in comment #112.
GeForce FX 5500 [NV34] PCI F18 Beta TC1 32-bit Live USB a) Boots to fallback mode, so the blacklist still works. Renderer string is: Gallium 0.4 on NV34. Version string is: 1.5 Mesa 9.0-devel b) Bypassing hardware-compatibility blacklist does allow the shell to start. "All" and "Accessories" under "Show Applications" are fouled as described above. The other categories are OK. The top bar calendar and menus have a transparent background. The network icon drop-down is OK.
Created attachment 621877 [details] Screencast of issues Screencast of issues
Discussed at 2012-10-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-10/f18beta-blocker-review-3.2012-10-10-16.05.log.txt . Agreed that with the information provided, it seems clear the blacklist is still working, and so this is not a blocker.
I can assure you the blacklist does not contain NVC3 which exhibits similar problems (see comment 107).
patryk: that is likely a separate bug, please do file it separately, yup. We don't blacklist broken adapters as a matter of course; this case was a special exception because it affects an entire generation of hardware and it's known to be difficult to fix, so the blacklist made sense. We only do blacklisting in that kind of circumstance. If it's just a case of 'one adapter has issues' and there's no particular indication it'll be very difficult to fix, the idea is we should devote resources to fixing the bug, not working around it with a blacklist.
Any news on this issue, please?
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
Moving this bug to Rawhide version as this bug occurs in F16 to F18 releases and it's very likely to hit also F19.
Certainly does this with F18, packages as follows: xorg-x11-drv-nouveau-1.0.3-1.fc18.x86_64 kernel-3.7.2-201.fc18.x86_64 gnome-shell-3.6.2-6.fc18.x86_64 Just in case MESA is implicated as posited in other reports. mesa-libGLES-9.0.1-3.fc18.x86_64 mesa-libGLw-devel-6.5.1-13.fc18.x86_64 mesa-dri-drivers-9.0.1-3.fc18.i686 mesa-libEGL-9.0.1-3.fc18.i686 mesa-libglapi-9.0.1-3.fc18.i686 mesa-libGL-devel-9.0.1-3.fc18.x86_64 mesa-libxatracker-9.0.1-3.fc18.x86_64 mesa-libGLU-9.0.0-1.fc18.i686 mesa-libGL-9.0.1-3.fc18.i686 mesa-libGLU-9.0.0-1.fc18.x86_64 mesa-libGLU-devel-9.0.0-1.fc18.x86_64 mesa-libgbm-9.0.1-3.fc18.i686 mesa-dri-filesystem-9.0.1-3.fc18.i686 mesa-libGLw-6.5.1-13.fc18.x86_64 mesa-libEGL-9.0.1-3.fc18.x86_64 mesa-libglapi-9.0.1-3.fc18.x86_64 mesa-libgbm-9.0.1-3.fc18.x86_64 mesa-libEGL-devel-9.0.1-3.fc18.x86_64 mesa-dri-filesystem-9.0.1-3.fc18.x86_64 mesa-libGL-9.0.1-3.fc18.x86_64 mesa-dri-drivers-9.0.1-3.fc18.x86_64 Device: 01:00.0 VGA compatible controller: NVIDIA Corporation Device 0dfc (rev a1) Platform: Dell Latitude E6530
comment #94 is obviously fine also for F18 (user has a better experience also artifacts from login screen disappear)
indeed, using comment #94 on f18 (for NV1X video card), allowed -shell to work correctly, even if very slow.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Stephen and others affected by this bug, are you able to reproduce it on latest Fedora 19?
Fedora-Live-Desktop-i686-19-TC3-1.iso LiveUSB nVidia GeForce FX5500 256MB PCI Better, but still has artifacts, font issues, etc. The blacklist remains enabled, so I get llvmpipe until I bypass it. I'll add a few screenshots...
Created attachment 760935 [details] 1
Created attachment 760936 [details] 2
At the first time when I got this issue, I had to reinstall fedora on my system. But after reinstall I installed cinnamon and KDE both on my system. I think the issue is not of Gnome only it is something related to GTK in core and both environment cinnemon and Gnome started showing similar problems of icons and texts on them, while KDE is good to work with. Atlast because of KDE environment I didn't have to reinstall fedora again. I liked Gnome but now KDE is a bettor option for me, atleast I can work on it without any problem.
In response to comment 129 (sorry about it being a year late), I no longer use this mother board and video card. I got a new mother board with an AMD APU. At the end the Nvidia card ran Mate and Compiz adequately, even the wobbly windows. I had uninstalled Gnome.
Ultimately this bug led me too to abandon completely Gnome 3 (I went for LXDE instead) -- I don't think I'll be back soon, even though I have better hardware now.
Jose (or anyone else who still has affected hardware), if it's not too inconvenient could you possibly test it with say a Fedora 20 live image (you should be able to edit the blacklist and restart gdm.service to get GNOME to start over), just to let us know if the issue still exists? thanks!
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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 19 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 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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.
(In reply to awilliam from comment #136) > Jose (or anyone else who still has affected hardware), if it's not too > inconvenient could you possibly test it with say a Fedora 20 live image (you > should be able to edit the blacklist and restart gdm.service to get GNOME to > start over), just to let us know if the issue still exists? thanks! (CLOSED EOL)