Bug 95044 - [NVA0] [Reclocking] GPU doesn't relax memory clocks
Summary: [NVA0] [Reclocking] GPU doesn't relax memory clocks
Status: ASSIGNED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ben Skeggs
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-20 21:41 UTC by debianlinuxero1
Modified: 2016-06-16 16:55 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Kernel_log (60.28 KB, text/plain)
2016-04-20 21:41 UTC, debianlinuxero1
no flags Details
VBIOS (61.00 KB, application/octet-stream)
2016-04-21 11:00 UTC, debianlinuxero1
no flags Details
MMIO trace log file (5.09 MB, application/x-xz)
2016-04-22 20:09 UTC, debianlinuxero1
no flags Details
Remove high-speed mode for GDDR3 (2.31 KB, patch)
2016-05-08 21:41 UTC, Roy
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description debianlinuxero1 2016-04-20 21:41:00 UTC
Created attachment 123101 [details]
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.
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]
VBIOS

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]
> 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.
Comment 4 debianlinuxero1 2016-04-21 23:12:49 UTC
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.
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 : 

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.
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 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!
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.


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.