Comment 12 for bug 45404

Ben Collins : yes.
I'm running this on 2.6.22-rc5 on a Thinkpad X40, and:

1) This Thinkpad model is also affected, indeed.
2) The bug is still present on the original unpatched package (it's even more visible because of dynticks, see above).
3) The Kristian Berge Nessa's patch works flawlesly, and actualy fix the problem (CPU usage become marginal).

I also slightly modified the Kristian's patch to make POLL_DELAY a 200ms delay ("#define POLL_DELAY 200", in thinkpad-keys.c line 40), rather than 100ms on Kristian's, and worse, 50ms on the original.

That's because a second bug, related to this one, in hotkey-setup: not only it use a large amount of CPU by doing needly heavy operations, but it also suck lot of power, by waking up the CPU out of C3/C4 power saving c-states too often (odd for a laptop utility), and this should be avoided now we have a tickless kernel.

The original, unpatched, hotkey-setup wakes the CPU 20 times a second for no good reason. Kristian reduced this nvram poll freq to 10Hz. But I think we should go for 5Hz : that's what tpb does (tpb being the original IBM Thinkpad special keys manager, well tested), and 5Hz is enough to keep up and not loose any key event.

Arjan van de Ven pointed out tpb as an heavy power consumer on the PowerTOP hall of shame ( http://www.linuxpowertop.org/known.php#tpb ), but hotkey-setup is doing much n worse because of this to small nvram polling delay. With Kristian's patch and a 200ms POLL_DELAY, we're on par with tpb (not _that_ bad).