Description of problem: On Nvidia GeForce 6150 (NV4E) with freshly installed Fedora 16, the login screen is serverely corruped, so that no useful interaction is possible. Version-Release number of selected component (if applicable): Fully updated F16 as of today; x86_64 binaries (I am writing this from a different machine in a different location, so I don't currently have access to the precise version numbers). How reproducible: Always Steps to Reproduce: 1. Boot into F16 2. 3. Actual results: See above Expected results: Working login screen. Additional info: The main board is an ASUS M2NPV-VM. Smolt incorrectly identifies it as an ASUS A8N-VM CSM (see attached). On this board, 3D acceleration never worked. However, with F14 the default install worked perfectly. On F15, gnome-shell is completely unusable, fallback-mode with compiz worked, but kept crashing, XFCE was working perfectly. Now on F16, even the login screen is broken. I had already filed a report on the F15 bug, see https://bugzilla.redhat.com/show_bug.cgi?id=713299 and participated in September in the nouveau test day, http://fedoraproject.org/wiki/Test_Day:2011-09-06_Nouveau#cite_note-20 where the precisely same behavior was already seen. Unfortunately, there was no activity in trying to resove this severe bug. I am very willing to help testing on this hardware (after all, it's slowly turning into a brick with each new Fedor version, though the hardware is perfectly fine), but I am no systems programmer, so someone who understands the internals needs to take lead... All the hardware details are detailed in the old bug report. If you need further information, please let me know. Note that I believe that it is also a defect in gdm to rely on accelerated or otherwise special features, as this makes it impossible to reach any fallback in case of graphics driver problems. Description of problem:
Some bug reports mention that nouveau fails on similar chips on the x64 architecture, but works fine with i686. This is not so here. i686 life CD in full graphics mode fails with inconsistent symptoms. Sometimes displays background image, then nothing (as with x64). Other times get error message during boot like [ 1.390219] [drm] nouveau 0000:00:05.0: mem timing table length unknown: 14 Welcome to rescue mode. .... i686 fallback basic graphics mode works, but does not get full refresh rate and resolution. Install to disc also only enables basic graphics mode ("nomodeset" in kernel argument). Tried to get grub2 to boot in full graphics mode, but don't know what to change. Deleting nomodeset, quiet, rhgb only gets me into text mode. What are the correct arguments?
This may be https://bugzilla.redhat.com/show_bug.cgi?id=745202 - that bug may affect both NV3x and NV4x hardware - but I'm not 100% sure yet, so leaving it separate for now. The reason the bug seems 'worse' on F16 is likely that the default login screen in F16 is actually a special case of gnome-shell. GDM is now rather like GNOME itself in that it uses gnome-shell to render the login screen if it detects that your hardware is capable of it, and has a 'fallback mode' for hardware that isn't capable of running Shell. I don't know of a *super* clean way to force the use of GDM's fallback mode - there are lots of dirty ones though (just forcibly removing the gnome-shell package would do the trick, for instance). You can simply switch to KDM or LXDM, of course. Could we get updated debug info (per https://fedoraproject.org/wiki/How_to_debug_Xorg_problems ) from F16? Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
to switch back to a native driver after installing with 'basic graphics' you have to take out all occurrences of 'nomodeset' from /boot/grub2/grub.cfg and also remove /etc/X11/xorg.conf .
Created attachment 541751 [details] Xorg log file as of today
Created attachment 541753 [details] Oldest Xorg log file I added the newest and the oldest Xorg log file. If you need those in between as well, please let me know.
Created attachment 541754 [details] Output from "smoltSendProfile -p > /tmp/smoltprofile.txt"
Created attachment 541756 [details] Output from "glxinfo > /tmp/glxinfo.txt"
(In reply to comment #3) > to switch back to a native driver after installing with 'basic graphics' you > have to take out all occurrences of 'nomodeset' from /boot/grub2/grub.cfg and > also remove /etc/X11/xorg.conf . I got a working X by disabling hardware acceleration (nouveau.noaccel=1 in kernel boot arguments). I do not use "nomodeset" nor do I have an xorg.conf file. All the attached output was obtained in this configuration.
(In reply to comment #2) > I don't know of a *super* clean way to force the use of GDM's fallback mode - > there are lots of dirty ones though (just forcibly removing the gnome-shell > package would do the trick, for instance). You can simply switch to KDM or > LXDM, of course. Woudn't it make sense to default to the fallback mode in GDM? It's just the login screen, after all, so there is no real loss for people with working hardware acceleration, but makes it much easier to recover from flaky graphics hardware. (Getting this machine to work was easily the most time consuming Xorg issue I have had ever since Redhat turned Fedora, of course not helped by the new grub which means relearning boot configuration on a machine without graphics...)
Created attachment 541766 [details] dmesg output with drm.debug=14 log_buf_len=16M as boot parameters
Created attachment 541770 [details] Example of screen corruption The corruption varies, the photo is just one example. Usually the screen turns completely gray or white after 20-30 seconds. Mouse cursor usually moves, but C-A-Del does not function. Other patterns seen are a completely white screen after the boot process finishes, and a correct background image with the f-logo from the graphical boot superimposed in the middle, while everything is locked up.
Thanks for all the info, but sorry, I need to clarify something now. When you say: "I got a working X by disabling hardware acceleration (nouveau.noaccel=1 in kernel boot arguments). I do not use "nomodeset" nor do I have an xorg.conf file. All the attached output was obtained in this configuration." What does the noaccel parameter achieve for you exactly? You get a working Shell desktop? Working fallback desktop? And do you really mean all the attached output was done with the 'nouveau.noaccel' parameter? If so I'm afraid we'd need you to re-do it without: we need the output from *when you hit the problem*, not the output from when you've worked around it. Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 542248 [details] Xorg log file with hardware acceleration enabled
Created attachment 542250 [details] Output from "smoltSendProfile -p > /tmp/smoltprofile.txt"
Created attachment 542252 [details] dmesg output with drm.debug=14 log_buf_len=16M as boot parameters
(In reply to comment #12) > What does the noaccel parameter achieve for you exactly? You get a working > Shell desktop? Working fallback desktop? Obviously, Gnome 3 does not start in regular shell mode. Fallback mode works, but I am using XFCE for independent reasons. > And do you really mean all the attached output was done with the > 'nouveau.noaccel' parameter? If so I'm afraid we'd need you to re-do it > without: we need the output from *when you hit the problem*, not the output > from when you've worked around it. Thanks! I redid all the output with hardware acceleration enabled, except for glxinfo which complains about "no display open" or similar on a virtual text terminal console. Remember, X is totally hosed, so all I can do is switch to a virtual text terminal console. (This takes about 10s to complete - took me a while to realize it works at all - while with hardware acceleration disabled, switching consoles is almost instantaneous.)
Just curious if there is any activity on this bug... Is there any more information that I can provide that would help make nouveau work on this chip?
This may still be a case of #745202, which we're trying to work on. For now, we will likely be blacklisting these cards from Shell. However, the corruption here looks rather a lot worse than what most people report in #745202, so I'm not 100% happy with marking it a blocker. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Kernel 3.4 fixes the issue for me.
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
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.