<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [NVA0] [Reclocking] GPU doesn't relax memory clocks" href="https://bugs.freedesktop.org/show_bug.cgi?id=95044#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [NVA0] [Reclocking] GPU doesn't relax memory clocks" href="https://bugs.freedesktop.org/show_bug.cgi?id=95044">bug 95044</a> from <a class="email" href="mailto:rspliet@eclipso.eu" title="Roy <rspliet@eclipso.eu>"> Roy</a> <pre>(In reply to debianlinuxero1 from <a href="show_bug.cgi?id=95044#c2">comment #2</a>) > Created <a href="attachment.cgi?id=123111" name="attach_123111" title="VBIOS">attachment 123111</a> <a href="attachment.cgi?id=123111&action=edit" title="VBIOS">[details]</a> > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>