No, the frequency does not drop when the temperature rises, on either maverick or natty kernel.
Although I never saw this problem when I was running natty, running a machine-stressing compile on a maverick kernel now did get within a couple of degrees of critical before I ^Zed the build. I do have the same problem that Jamie reports of the fans never coming up to full speed; in my case they max out around 3800rpm on 'auto', and about 6350rpm on 'disengaged'. When running at full speed, this is enough to keep the machine 10°C away from the critical trip point.
The last problem is that the acpi thermal thresholds themselves are screwed up. With a single thermal zone on the system, I have:
No, the frequency does not drop when the temperature rises, on either maverick or natty kernel.
Although I never saw this problem when I was running natty, running a machine-stressing compile on a maverick kernel now did get within a couple of degrees of critical before I ^Zed the build. I do have the same problem that Jamie reports of the fans never coming up to full speed; in my case they max out around 3800rpm on 'auto', and about 6350rpm on 'disengaged'. When running at full speed, this is enough to keep the machine 10°C away from the critical trip point.
The last problem is that the acpi thermal thresholds themselves are screwed up. With a single thermal zone on the system, I have:
$ cat /sys/class/ thermal/ thermal_ zone0/trip_ point_{ 0,1}_{temp, type}
100000
critical
127500
passive
$
The 'passive' trip point is higher than the 'critical' trip point. And the cooling devices are all tied to the passive trip point:
$ cat /sys/class/ thermal/ thermal_ zone0/cdev* _trip_point
1
1
1
1
$
So screwy ACPI tables seem to be at least part of the problem.