Nouveau - Apr 2014 - [Bug 77230] New: NV40 PGRAPH "unknown bits" - windows render in white

https://bugs.freedesktop.org/show_bug.cgi?id=77230

          Priority: medium
            Bug ID: 77230
          Assignee: nouveau at lists.freedesktop.org
           Summary: NV40 PGRAPH "unknown bits" - windows render in
white
        QA Contact: xorg-team at lists.x.org
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: guinness.meredith at gmail.com
          Hardware: x86-64 (AMD64)
            Status: NEW
           Version: unspecified
         Component: Driver/nouveau
           Product: xorg

Created attachment 97126
  --> https://bugs.freedesktop.org/attachment.cgi?id=97126&action=edit
dmesg from boot to just after login

Previously I was using Fedora 17 and found that once a week or so I would get
nouveau errors and had to reboot.

Recently I installed Fedora 20 (always clean installs) and for the first few
weeks all was good so I thought the problem had been resolved.  Alas the
problem remains, although slightly different, and has slowly deteriorated to
the point that now it presents at login.

As suggested on your site I initially  lodged a bug with redhat, but that seems
to have stalled:
https://bugzilla.redhat.com/show_bug.cgi?id=708422

My workaround is to use vncserver and my notebook to remote into F20. The
virtual consoles on F20 are fine, and the UI also working, the problem is
(excuse the windows terminology) the client area of application windows is
rendered as white.

As an example I can start terminal from my favourites bar, the client area
displays as white, I can type "exit", it is not reflected in terminal,
hit
enter and the window will close

Same white windows in gnote, settings, nautilus, etc

Are there any special configs I can try? I am happy to provide more info, do
more tests and compile nouveau myself if it would help... just need some
guidance.

Thanks,
Troy

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140409/be541130/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=77230

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|NV40 PGRAPH "unknown bits"  |[NV4B] NV40 PGRAPH
"unknown
                   |- windows render in white   |bits" - windows render in
                   |                            |white

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Well, the errors are coming from blit commands (blit = copy image). So it makes
sense that you'd be seeing white or otherwise uninitialized screen areas.

This code hasn't exactly changed of late. It might even be a hw error of
some
sort. I don't think others with NV4B chips are seeing this. And it's an
unknown
error on top of that (that's the "unknown bits" part of it...
normally it'd say
exactly what it was complaining about).

You can disable acceleration by adding NoAccel to the xorg config, or by
booting with nouveau.noaccel=1.

Unless you're able to identify a change of some sort that makes it go from
non-working to working (other than killing acceleration entirely), I'm not
sure
that we'll be able to do much. I'm talking about kernel versions, ddx
versions,
that sort of thing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140409/3f8ae2a5/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=77230

--- Comment #2 from Troy <guinness.meredith at gmail.com> ---
Thank-you Ilia!

On Fedora 20 I have created a minimalist config containing only:

Section "Device"
    Identifier "Videocard0"
    Driver "nouveau"
    Option "NoAccel" "true"
EndSection

... and am now able to login and work normally, although understandably
graphics are slower (but better than remote desktop).

You mention the issue may be related to a hardware error.  Is this (ie
"working" when hw acceleration disabled) conclusive proof, or is there
some
other test I can do to confirm this?  Like memtest for the GPU?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140410/6fdc36d4/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=77230

Troy <guinness.meredith at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |NOTABUG

--- Comment #3 from Troy <guinness.meredith at gmail.com> ---
Well it took a while but I eventually discovered Video Memory Test (VMT) which
is like memtest but for video ram.  I downloaded the ISO version (VMTCE) from
sourceforge:

http://sourceforge.net/projects/vmtce/files/

After completing the test there were 223,834 errors.

Nice... not.

Further investigation suggests nVidia might have switched the type of solder
the year after my card was manufactured, due to high failure rates in
notebooks:

http://www.tgdaily.com/hardware-features/39045-nvidia-gpu-failures-caused-by-material-problem-sources-claim

Anyway, my problem is indeed a hardware error, most likely all those solder
joints have micro fractures.

Thanks for pointing me in the right direction.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140425/6f0c2c22/attachment.html>