Nouveau - Apr 2016 - [Bug 95044] New: [NVA0] [Reclocking] GPU doesn't relax memory clocks

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

            Bug ID: 95044
           Summary: [NVA0] [Reclocking] GPU doesn't relax memory clocks
           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: debianlinuxero1 at gmail.com
        QA Contact: xorg-team at lists.x.org

Created attachment 123101
  --> https://bugs.freedesktop.org/attachment.cgi?id=123101&action=edit
Kernel_log

The card doesn't relax memory clocks on step down reclock transitions.

For example, if I try [code]echo 07 > pstate[/code] from a 0f state, I see
this
:

[code]
03: core 300 MHz shader 600 MHz memory 100 MHz
07: core 400 MHz shader 800 MHz memory 300 MHz AC DC *
0f: core 576 MHz shader 1242 MHz memory 999 MHz
AC: core 399 MHz shader 799 MHz memory 999 MHz
[/code]

The problem happens in the 3 step down possible transitions :

0f -> 07, 07 -> 03 and 0f -> 03.

The memory clock always stands as high as the major's state I set up.



The system is :

Phenom II X4 905e, 4 GB DDR3 @ 1333, nVidia GeForce GTX 260, 790FX chipset.

Debian GNU/Linux stretch (Testing) x64

Kernel 4.4.0-1, libdrm-nouveau2 2.4.67-1.


The attachment file shows a kernel dmesg after switching from state 0f to 07.

-- 
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/20160420/c894858b/attachment-0001.html>

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

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Please attach your vbios (/sys/kernel/debug/dri/0/vbios.rom)

-- 
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/20160420/e789674f/attachment.html>

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

--- Comment #2 from debianlinuxero1 at gmail.com ---
Created attachment 123111
  --> https://bugs.freedesktop.org/attachment.cgi?id=123111&action=edit
VBIOS

The vbios.rom file

-- 
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/20160421/891d662a/attachment.html>

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

--- Comment #3 from Roy <rspliet at eclipso.eu> ---
(In reply to debianlinuxero1 from comment #2)
> Created attachment 123111 [details]
> VBIOS
> 
> The vbios.rom file
Thanks, that's helpful. I'm afraid I also need some info from the
official
driver though. In particular a peek from the 0x1002c0, 0x1002c4 and 0x1002e0
registers in the lowest performance level. Could you obtain an mmiotrace of the
official driver going down from the highest to the lowest performance level, xz
it and attach it to this bug please? Alternatively you can nvapeek these
registers in the lowest level (as observed in nvidia-settings).

For reference: I suspect the "high CAS" bit (MR[2], bit 0) in the
GDDR3 specs
we used for reference is in fact bogus. Your VBIOS appears to set this bit upon
boot, but apart from the lowest perf lvl, the values written for CAS would
always correspond between the low and high lookup-tables. For the lowest
perflvl, only the low lookup-table contains an entry for the CAS latency. Trace
should help determine whether the official driver unsets the "high
CAS" bit or
rather ignores it.

-- 
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/20160421/96e69f39/attachment.html>

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

--- Comment #4 from debianlinuxero1 at gmail.com ---
Hello.

This is what I nvapeek'ed :

001002c0: 00000652

001002c4: 001002c8

001002e0: 0020001b



I tried to do the mmiotrace procediment as explained here :
https://wiki.ubuntu.com/X/MMIOTracing

The command choosen was "xinit nvidia-settings", with the intention to
force
clocks with the "Prefer Maximum Performance" option, then relaxing
with
"Adaptive Mode".

But all what I got was 40 minutes of black screen.
The system didn't shutdown neither with magic sysrq.

-- 
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/20160421/38f51309/attachment.html>

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

--- Comment #5 from debianlinuxero1 at gmail.com ---
As karolherbst pointed on the #nouveau irc channel, I patched my distro kernel
sources with this patch : 

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86/mm/kmmio.c?id=cfa52c0cfa4d727aa3e457bf29aeff296c528a08

Build with the same options as current kernel.

It did the trick.

I finally was able to do the mmiotrace test.

The test consisted in running the bare X server with only the nvidia-settings
application.

Forced Maximum Performance level.

At reach then forced adaptive.

At reach then exited both application and X.

-- 
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/20160422/983239cf/attachment.html>

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

--- Comment #6 from debianlinuxero1 at gmail.com ---
Created attachment 123159
  --> https://bugs.freedesktop.org/attachment.cgi?id=123159&action=edit
MMIO trace log file

-- 
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/20160422/7d20a876/attachment.html>

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

--- Comment #7 from Roy <rspliet at eclipso.eu> ---
Created attachment 123554
  --> https://bugs.freedesktop.org/attachment.cgi?id=123554&action=edit
Remove high-speed mode for GDDR3

Risking to make a fool out of myself because I haven't even compile-tested
this; please patch your kernel with the attached and see if it resolves your
problem.

-- 
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/20160508/fe9021b5/attachment.html>

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

--- Comment #8 from debianlinuxero1 at gmail.com ---
I've just applied the patch and check.


IT WORKS!!


It switches well towards all transitions, from down to top (step by step), top
to down (step by step) and from extreme to extreme (03 -> 0f and 0f ->
03).

Good work!

-- 
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/20160509/6dacb956/attachment.html>

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

Roy <nouveau at spliet.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|nouveau at lists.freedesktop.o |skeggsb at gmail.com
                   |rg                          |

-- 
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/20160616/bda92ac0/attachment.html>

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

Roy <nouveau at spliet.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nouveau at lists.freedesktop.o
                   |                            |rg

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20160616/ed6ab599/attachment.html>

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

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

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

--- Comment #10 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/263.

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