| 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@lists.freedesktop.org |
| Reporter | debianlinuxero1@gmail.com |
| QA Contact | xorg-team@lists.x.org |
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.
Please attach your vbios (/sys/kernel/debug/dri/0/vbios.rom)
Created attachment 123111 [details]
VBIOS
The vbios.rom file
(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.
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.
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.
Created attachment 123159 [details]
MMIO trace log file
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.
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!
| What | Removed | Added |
|---|---|---|
| Assignee | nouveau@lists.freedesktop.org | skeggsb@gmail.com |
| What | Removed | Added |
|---|---|---|
| CC | nouveau@lists.freedesktop.org |
| What | Removed | Added |
|---|---|---|
| Resolution | --- | MOVED |
| Status | ASSIGNED | RESOLVED |
-- 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/iss= ues/263.