|
Description
m.oliver
2011-11-10 15:14:41 UTC
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. |