Bug 95044

Summary: [NVA0] [Reclocking] GPU doesn't relax memory clocks
Product: xorg Reporter: debianlinuxero1
Component: Driver/nouveauAssignee: Ben Skeggs <skeggsb>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: nouveau
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
i915 platform: i915 features:
Description Flags
MMIO trace log file
Remove high-speed mode for GDDR3 none

Description debianlinuxero1 2016-04-20 21:41:00 UTC
Created attachment 123101 [details]

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 :

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

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.
Comment 1 Ilia Mirkin 2016-04-20 21:43:09 UTC
Please attach your vbios (/sys/kernel/debug/dri/0/vbios.rom)
Comment 2 debianlinuxero1 2016-04-21 11:00:29 UTC
Created attachment 123111 [details]

The vbios.rom file
Comment 3 Roy 2016-04-21 13:41:02 UTC
(In reply to debianlinuxero1 from comment #2)
> Created attachment 123111 [details]
> 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.
Comment 4 debianlinuxero1 2016-04-21 23:12:49 UTC

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.
Comment 5 debianlinuxero1 2016-04-22 20:08:08 UTC
As karolherbst pointed on the #nouveau irc channel, I patched my distro kernel sources with this patch : 


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.
Comment 6 debianlinuxero1 2016-04-22 20:09:59 UTC
Created attachment 123159 [details]
MMIO trace log file
Comment 7 Roy 2016-05-08 21:41:34 UTC
Created attachment 123554 [details] [review]
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.
Comment 8 debianlinuxero1 2016-05-09 18:20:18 UTC
I've just applied the patch and check.


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!
Comment 9 Roy 2016-06-16 16:55:25 UTC
Ben: you mentioned that this patch might break reclocking on one of your cards. Please confirm this claim.
Comment 10 Martin Peres 2019-12-04 09:12:07 UTC
-- 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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.