Bug 752840 - More screen corruption on NV4E
More screen corruption on NV4E
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau (Show other bugs)
16
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-10 10:14 EST by oliver
Modified: 2013-02-13 07:44 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 07:44:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg log file as of today (83.39 KB, text/x-log)
2011-12-07 03:18 EST, oliver
no flags Details
Oldest Xorg log file (67.93 KB, text/x-log)
2011-12-07 03:20 EST, oliver
no flags Details
Output from "smoltSendProfile -p > /tmp/smoltprofile.txt" (3.09 KB, text/plain)
2011-12-07 03:24 EST, oliver
no flags Details
Output from "glxinfo > /tmp/glxinfo.txt" (23.82 KB, text/plain)
2011-12-07 03:26 EST, oliver
no flags Details
dmesg output with drm.debug=14 log_buf_len=16M as boot parameters (265.63 KB, text/plain)
2011-12-07 04:16 EST, oliver
no flags Details
Example of screen corruption (321.28 KB, image/jpeg)
2011-12-07 04:28 EST, oliver
no flags Details
Xorg log file with hardware acceleration enabled (65.02 KB, text/x-log)
2011-12-07 18:11 EST, oliver
no flags Details
Output from "smoltSendProfile -p > /tmp/smoltprofile.txt" (3.09 KB, text/plain)
2011-12-07 18:12 EST, oliver
no flags Details
dmesg output with drm.debug=14 log_buf_len=16M as boot parameters (306.85 KB, text/plain)
2011-12-07 18:13 EST, oliver
no flags Details

  None (edit)
Description oliver 2011-11-10 10:14:41 EST
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:
Comment 1 oliver 2011-11-13 18:24:09 EST
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?
Comment 2 Adam Williamson 2011-12-06 18:36:16 EST
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
Comment 3 Adam Williamson 2011-12-06 18:37:38 EST
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 .
Comment 4 oliver 2011-12-07 03:18:48 EST
Created attachment 541751 [details]
Xorg log file as of today
Comment 5 oliver 2011-12-07 03:20:14 EST
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.
Comment 6 oliver 2011-12-07 03:24:08 EST
Created attachment 541754 [details]
Output from "smoltSendProfile -p > /tmp/smoltprofile.txt"
Comment 7 oliver 2011-12-07 03:26:19 EST
Created attachment 541756 [details]
Output from "glxinfo > /tmp/glxinfo.txt"
Comment 8 oliver 2011-12-07 03:30:45 EST
(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.
Comment 9 oliver 2011-12-07 03:40:00 EST
(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...)
Comment 10 oliver 2011-12-07 04:16:20 EST
Created attachment 541766 [details]
dmesg output with drm.debug=14 log_buf_len=16M as boot parameters
Comment 11 oliver 2011-12-07 04:28:24 EST
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.
Comment 12 Adam Williamson 2011-12-07 12:37:04 EST
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
Comment 13 oliver 2011-12-07 18:11:55 EST
Created attachment 542248 [details]
Xorg log file with hardware acceleration enabled
Comment 14 oliver 2011-12-07 18:12:53 EST
Created attachment 542250 [details]
Output from "smoltSendProfile -p > /tmp/smoltprofile.txt"
Comment 15 oliver 2011-12-07 18:13:59 EST
Created attachment 542252 [details]
dmesg output with drm.debug=14 log_buf_len=16M as boot parameters
Comment 16 oliver 2011-12-07 18:21:22 EST
(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.)
Comment 17 oliver 2012-01-24 06:26:44 EST
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?
Comment 18 Adam Williamson 2012-03-20 16:21:06 EDT
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
Comment 19 oliver 2012-06-12 16:17:08 EDT
Kernel 3.4 fixes the issue for me.
Comment 20 Fedora End Of Life 2013-01-16 07:27:54 EST
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
Comment 21 Fedora End Of Life 2013-02-13 07:44:06 EST
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.

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