Nouveau - Feb 2015 - [Bug 89273] New: [NVA8] nouveau screen corruption and X lockup when reclocking

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

            Bug ID: 89273
           Summary: [NVA8] nouveau screen corruption and X lockup when
                    reclocking
           Product: xorg
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: maxim.stargazer at gmail.com
        QA Contact: xorg-team at lists.x.org

Created attachment 113734
  --> https://bugs.freedesktop.org/attachment.cgi?id=113734&action=edit
Thinkpad T410, Quadro NVS 3100M (256M GDDR3) vbios dump

Kernel: 3.19.1
Hardware: Thinkpad T410, Quadro NVS 3100M (256M GDDR3) [similar hw but
different VRAM compared to bug 88415]
Problem: reclocking between pstates 3 and 7 is flawless, but reclocking to
pstate f causes problems.
Possible scenarios:

1. X server is not running, trying to reclock from the fb. 
   echo f > pstate
  Image gets corrupted (vertical flickering lines), but there is no lockup and
after
   echo 7 > pstate
everything gets back to normal. After that system works just fine.
Dmesg attached (with nouveau.debug=debug)

2. X server is running. 
   echo f > pstate
   Screen gets corrupted in similar fashion, but system locks up and after few
second stops to respond even to SysRq.
I managed to get dmesg for this scenario too.

I also mmiotraced functioning reclocking with the nvidia blob. Trace is quite
large (120MB). Should I truncate it somehow to upload, or just provide as is?

-- 
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/20150221/26a6fd10/attachment.html>

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

--- Comment #1 from Max Sydorenko <maxim.stargazer at gmail.com> ---
Created attachment 113735
  --> https://bugs.freedesktop.org/attachment.cgi?id=113735&action=edit
dmesg of reclock without X

dmesg of reclock without X running (to pstate f and back to 7)

-- 
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/20150221/5924445d/attachment.html>

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

--- Comment #2 from Max Sydorenko <maxim.stargazer at gmail.com> ---
Created attachment 113736
  --> https://bugs.freedesktop.org/attachment.cgi?id=113736&action=edit
dmesg of reclock with X (and glxgears)

-- 
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/20150221/99c8c85b/attachment.html>

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

--- Comment #3 from Roy <rspliet at eclipso.eu> ---
(In reply to Max Sydorenko from comment #0)
> Created attachment 113734 [details]
> Thinkpad T410, Quadro NVS 3100M (256M GDDR3) vbios dump
> 
> Kernel: 3.19.1
> Hardware: Thinkpad T410, Quadro NVS 3100M (256M GDDR3) [similar hw but
> different VRAM compared to bug 88415]
> Problem: reclocking between pstates 3 and 7 is flawless, but reclocking to
> pstate f causes problems.
[...]
> I also mmiotraced functioning reclocking with the nvidia blob. Trace is
> quite large (120MB). Should I truncate it somehow to upload, or just
provide
> as is?
Thanks for reporting. I've had very little GDDR3 cards to test with (in
fact...
just one), so these logs will be extremely useful. If you can, please provide
the trace in full. Feel free to compress it using xz or similar.

-- 
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/20150221/adf05e77/attachment.html>

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

--- Comment #4 from Ilia Mirkin <imirkin at alum.mit.edu> ---
I believe the two issues are unrelated. The flickering issue is probably due to
incorrect timing parameters somewhere. The hang is, more than likely, due to

[  144.038590] nouveau W[   PFIFO][0000:01:00.0] unknown intr 0x00000040, ch 3

Which we don't handle currently. rnndb has it as

                        <bitfield pos="6"
name="PEEPHOLE_FAULT"/>

So we probably have to reprogram PBUS.HOST_MEM.CHAN and PBUS.HOST_MEM.PEEPHOLE
(or at the very least the latter) -- that's 0x1704 and 0x1710 respectively.
Not
100% sure what they are, but software/nv50.c does:

    nv_wr32(priv, 0x001704, chan->vblank.channel);
    nv_wr32(priv, 0x001710, 0x80000000 | chan->vblank.ctxdma);

Hopefully someone who understands these things a little better will step in
here.

-- 
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/20150221/539d8267/attachment.html>

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

--- Comment #5 from Max Sydorenko <maxim.stargazer at gmail.com>
---
> Thanks for reporting. I've had very little GDDR3 cards to test with (in
> fact... just one), so these logs will be extremely useful. If you can,
> please provide the trace in full. Feel free to compress it using xz or
> similar.
Here is direct link to xz-ed mmiotrace
https://www.dropbox.com/s/el0zzw80ttmt584/mmiotrace.log.tar.xz?dl=0

-- 
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/20150221/04f76d92/attachment-0001.html>

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

Martin Peres <martin.peres at free.fr> changed:

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

--- Comment #6 from Martin Peres <martin.peres at free.fr> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/172.

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