diff options
author | Dave Jones <davej@redhat.com> | 2005-10-21 17:21:03 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2005-10-21 14:28:58 -0700 |
commit | 0213df74315bbab9ccaa73146f3e11972ea6de46 (patch) | |
tree | 68a71915bb58a18168cd13744772bd447bcf8b29 /kernel/kmod.c | |
parent | 3078fcc1d18c7235b034dc889642c5300959fa20 (diff) | |
download | kernel_samsung_aries-0213df74315bbab9ccaa73146f3e11972ea6de46.zip kernel_samsung_aries-0213df74315bbab9ccaa73146f3e11972ea6de46.tar.gz kernel_samsung_aries-0213df74315bbab9ccaa73146f3e11972ea6de46.tar.bz2 |
[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/kmod.c')
0 files changed, 0 insertions, 0 deletions