Bug 5027

Summary:	Usermode speed governor is dangerous on Athlon 64 X2
Product:	Power Management	Reporter:	Josh Rosen (bjrosen)
Component:	cpufreq	Assignee:	cpufreq (cpufreq)
Status:	CLOSED PATCH_ALREADY_AVAILABLE
Severity:	high	CC:	akpm, bunk
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.11.12	Subsystem:
Regression:	---	Bisected commit-id:

Description Josh Rosen 2005-08-08 13:07:42 UTC

Most recent kernel where this bug did not occur:2.6.11.12
Distribution:Fedora Core 3
Hardware Environment:Athlon 64 X2 4400+, MSI K8N Neo4 (Nforce4), 4G DDR
Software Environment:
Problem Description:The Usermode speed governor can set the two processors on
the  chip to different speeds. When the cores are out of sync there can be
system crashes or other bad behavior. I had both a system crash and a failure on
a kernel make which reported and irreproducible error. The following error
message is issued by the kernel,
Aug  7 20:51:42 nimitz kernel: powernow-k8: error - out of sync, fid 0xc 0x2,
vid 0xa 0x12
Aug  7 20:51:42 nimitz kernel: Warning: CPU frequency is 1000000, cpufreq
assumed 2000000 kHz.

The X2 cores seem to need to run at the same clock speed. Currently the cores
are managed as two separate CPUs, for the purposes of clock speed management
they need to be treated as a single entity, i.e. the when when changing the
speed the kernel needs to change them both simultaneously.

I've switched to the performance governor for the moment and everything seems
stable. 

p.s. I tried to load the ondemand governor, but the kernel won't accept that one
for A64 X2s. 

Steps to reproduce:

Comment 1 Andrew Morton 2005-08-18 10:21:03 UTC

mark.langsdorf@amd.com said:

The old driver (driver version 1.20 and earlier, in 2.6.11 kernels
 and earlier) wasn't dual-core aware and would attempt to 
 transition frequencies on each core without respect to the other.
 This would cause some warning messages but I'm surprised that
 it caused system stability.

 The latest driver (driver version 1.40 and later, in 2.6.12 
 kernels and later) is dual core aware and uses the cpus field
 of the cpufreq_policy struct to keep track of them.  It doesn't
 have any known stability problems nor does it generate warning
 messages on dual-core systems.

 I think we're covered, here.

So please test a 2.6.12.x or 2.6.13-rcY kernel.

Comment 2 Dominik Brodowski 2005-11-15 13:54:53 UTC

any update on this? e.g. new test results?

Comment 3 Adrian Bunk 2006-04-14 03:55:55 UTC

I'm assuming this issue is already fixed in recent 2.6 kernels.

Please reopen this bug if it's still present in kernel 2.6.16.5.