summaryrefslogtreecommitdiffstats
path: root/kernel/posix-cpu-timers.c
diff options
context:
space:
mode:
authorDave Jones <davej@redhat.com>2005-10-21 17:21:03 -0400
committerLinus Torvalds <torvalds@g5.osdl.org>2005-10-21 14:28:58 -0700
commit0213df74315bbab9ccaa73146f3e11972ea6de46 (patch)
tree68a71915bb58a18168cd13744772bd447bcf8b29 /kernel/posix-cpu-timers.c
parent3078fcc1d18c7235b034dc889642c5300959fa20 (diff)
downloadop-kernel-dev-0213df74315bbab9ccaa73146f3e11972ea6de46.zip
op-kernel-dev-0213df74315bbab9ccaa73146f3e11972ea6de46.tar.gz
[PATCH] cpufreq: fix pending powernow timer stuck condition
AMD recently discovered that on some hardware, there is a race condition possible when a C-state change request goes onto the bus at the same time as a P-state change request. Both requests happen, but the southbridge hardware only acknowledges the C-state change. The PowerNow! driver is then stuck in a loop, waiting for the P-state change acknowledgement. The driver eventually times out, but can no longer perform P-state changes. It turns out the solution is to resend the P-state change, which the southbridge will acknowledge normally. Thanks to Johannes Winkelmann for reporting this and testing the fix. Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'kernel/posix-cpu-timers.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud