Distribution: cpufreq powernow-k8 modules doesn't work with Sempron 3100 CPU correctly. Hardware Environment: CPU: AMD Sempron 3100+ Socket 745 MB: Gigabyte K8NS Pro RAM: 512Mb PC3200 Hynix PowerSupply: 350Watts Unknown Software Environment: Fedora Core 1 partly upgaded to FC4 test1 Problem Description: When loading the powernow-k8 module on any recent kernel (I've tried 2.6.8 through 2.6.10) on my Sempron desktop, I see: powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.09e) powernow-k8: 0 : fid 0x8 (1800 MHz), vid 0x6 (1400 mV) powernow-k8: 1 : fid 0x0 (900 MHz), vid 0x18 (950 mV) cpu_init done, current fid 0x8, vid 0x4 powernow-k8: vid trans failed, vid 0x3, curr 0x4 powernow-k8: transition frequency failed powernow-k8: vid trans failed, vid 0x3, curr 0x4 powernow-k8: transition frequency failed ... and many more of those 'vid trans failed' errors (one every time there's an attempted freq change). Actually as soon as my PC is idle the CPU speed is set to 900MHz and cpufreq_ondemand can't change it to smth else. I tried using cpufreq_userspace driver with the same effect: after userspace cpufreq daemon changed CPU speed to 900MHz it couldn't restore it to 1800MHz on high load. Note: Original AMD cpu driver supplied for Windows XP works OK.
Created attachment 5007 [details] This patch solved my problems This patch resolves the issues while following closely AMD specifications.
I was having a similar problem on my Winchester 3000+ on a Gigabyte K8N Ultra-9 (nForce4 Ultra chipset). The patch fixed my problem on gentoo-sources 2.6.11-r7. The same problem existed on vanilla 2.6.12-rc4.
I got the same error messages as the original poster on an Athlon 64 3500+ (Venice) @ Gigabyte K8N-Ultra SLI (So939 nForce 4) using gentoo-sources-2.6.11-r9 and this patch fixed them for me, too. :-)
Can I please have an update on this one? Was the patch merged? Is 2.6.12-rc5 functioning correctly? Thanks.
I still see the same problem in 2.6.12-rc5. The patch still corrects the problem for me as well.
This patch is not included into 2.6.12-rc5.
I just did a quick test of 2.6.12. Seems that the problem is fixed on my system.
For me it is fixed in 2.6.12, too. :-)
As for 2.6.12 the bug is no longer valid. Another patch has obviously fixed this problem.