[ltp] T60p idle GPU temperature?

[Alex Deucher]

On Sat, Jul 7, 2012 at 11:38 AM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
> On Sat, 07 Jul 2012, Alex Deucher wrote:
>> > The Linux ATI framebuffer/DRM power management is crap, at least for the
>> > X300/X600/X1500/X1600 ATIs, so it really runs the GPU a lot hotter (and
>> > wastes a lot more power) than what non-KMS X.org used to do, and let's not
>> > even compare it to what fglrx could do...
>>
>> The radeon KMS and non-KMS pm support is mostly identical.  If you are
>> experiencing differences, it's probably due to the fact that KMS
>> utilizes the GPU more readily than UMS did.
>
> Dynamic clocks worked somewhat well with non-KMS.  This is not true for KMS
> IME, at least not for the R300 family.

The UMS dynamic clocks option just used a lower clock speed when the
displays were off.  The KMS code does the same thing with both dynpm
and profiles.  KMS uses the GPU a lot more than UMS did (uses the GPU
to accelerate GPU buffer moves, dynamically uses GART, etc.).

>
> I've numerically tested this at the time one still could run non-KMS, with
> the built-in thinkpad power-meter (when in battery mode), and also by the
> built-in planar temperature sensor which sits close to the GPU on a T43
> (Radeon X300).
>
> I've been running the latest 3.0 kernel, and power management didn't improve
> much.  Unless one also needs up-to-date mesa for better power saving modes
> to work?  I'm runing a very outdated mesa from Debian stable, after all...
>
> Still, I recall that the difference was very noticeable on an mostly idle
> GPU (static screen, no OpenGL context active, no composition manager
> running).
>
> That said, you're probably aware that switching power profiles in the
> current KMS code (well, up to kernel 3.0 KMS code to be exact) causes some
> sort of PCIe transient error in several ThinkPads, that results in unhandled
> NMIs (reasons a0 and b0 on a T43 2687).  This has been reported, but no
> solution has been found so far.  I'm living with it, since it doesn't seem
> to cause any instability to the box, but it is annoying :-(

It's changing the number of PCIE lanes that causes this.  You can
disable that code (rv370_set_pcie_lanes()).  The host bridge doesn't
seem to like having the lanes switched on it when it's running and
generates the NMI.

Alex

>
> --
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh