Bug 7383 - cpu frequency switching seems to be broken (on Intel Conroe 6600), frequencies being shown are wrong
Summary: cpu frequency switching seems to be broken (on Intel Conroe 6600), frequencie...
Status: CLOSED CODE_FIX
Alias: None
Product: Power Management
Classification: Unclassified
Component: cpufreq (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Alexey Starikovskiy
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-18 01:53 UTC by Matthew
Modified: 2011-07-30 05:23 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.19-rc4-mm2
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dsdt.raw (made out of 2.6.19-rc2-mm1) (36.17 KB, application/vnd.rn-realaudio)
2006-10-18 08:50 UTC, Matthew
Details
dmesg for 2.6.19-rc2-mm1 (28.77 KB, text/plain)
2006-10-18 08:51 UTC, Matthew
Details
full acpidump (171.09 KB, application/octet-stream)
2006-10-18 09:51 UTC, Matthew
Details
acpidump of bios version 1502 (little changes) (171.09 KB, application/octet-stream)
2006-10-18 15:02 UTC, Matthew
Details
0x2E3 area (739 bytes, text/plain)
2006-10-19 13:04 UTC, Matthew
Details
0x2da area (730 bytes, text/plain)
2006-10-19 13:04 UTC, Matthew
Details
additional printout about p-states (1.53 KB, patch)
2006-10-23 04:33 UTC, Alexey Starikovskiy
Details | Diff
dmesg with p-states patch, 2.6.19-rc2-mm2 (29.18 KB, text/plain)
2006-10-23 06:08 UTC, Matthew
Details
kernel-config of 2.6.19-rc2-mm2 (44.92 KB, application/octet-stream)
2006-10-23 06:10 UTC, Matthew
Details
Fix error in duplicate elimination code (2.56 KB, patch)
2006-10-23 06:55 UTC, Alexey Starikovskiy
Details | Diff
dmesg of 2.6.19-rc2-mm2, amd64 (30.21 KB, text/plain)
2006-10-26 06:36 UTC, Matthew
Details
kernel-config of 2.6.19-rc2-mm2, amd64 (42.98 KB, application/octet-stream)
2006-10-26 06:42 UTC, Matthew
Details
kernel-config of 2.6.19-rc3-mm1 (x86) (43.52 KB, application/octet-stream)
2006-10-30 03:41 UTC, Matthew
Details
dmesg of 2.6.19-rc3-mm1 (x86) unpatched + after start of cpufreqd (kernel BUG) (29.17 KB, text/plain)
2006-11-05 13:23 UTC, Matthew
Details
dmesg 2.6.19-rc5-mm1 (x86), kernelBUG (30.12 KB, text/plain)
2006-11-09 00:47 UTC, Matthew
Details
Cleaned patch for acpi-cpufreq.c duplicates removal (773 bytes, patch)
2006-11-09 07:08 UTC, Alexey Starikovskiy
Details | Diff
Another way to fix the duplicates removal... (1.15 KB, patch)
2006-11-09 07:10 UTC, Alexey Starikovskiy
Details | Diff
dmesg of 2.6.19-rc4-mm2 with output after cpufreq-activation (amd64), 1st patch (#50) (30.18 KB, text/plain)
2006-11-10 02:03 UTC, Matthew
Details
dmesg of 2.6.19-rc5-mm1 with output after cpufreq-activation (amd64), 1st patch (#50) (30.18 KB, text/plain)
2006-11-10 02:03 UTC, Matthew
Details
fix for srcu breaking cpufreq notify from Ingo Molnar (154 bytes, patch)
2006-11-16 12:32 UTC, Alexey Starikovskiy
Details | Diff

Description Matthew 2006-10-18 01:53:26 UTC
Most recent kernel where this bug did not occur: 2.6.19-rc2
Distribution: GNU/Gentoo Linux
Hardware Environment: Intel Conroe 6600 (Core 2 Duo), Asus P5W DH Deluxe
Software Environment: x86, powernowd, gnome
Problem Description: frequencies being displayed aren't correct, frequency
switching doesn't seem to work: it stays at the highest frequency: 2.6 GHz

Steps to reproduce: start in system, frequency switching: userspace, start powernowd

cat scaling_available_frequencies
2394000 1596000 1 0 33554432 0 -1339546588 -1339546588 -313505024 -407094144 

 cat cpuinfo_max_freq
3981462272 

cat cpuinfo_min_freq
0

cat scaling_driver
acpi-cpufreq 

can this harm hardware ?
Comment 1 Hiroshi Miura 2006-10-18 03:34:50 UTC
This looks like a problem of ACPI BIOS.
The scaling_available_frequencies may be retrieved from ACPI BIOS table,
so it seems to be broken or not to be configured properly.

Recent BIOS is ver 1407 Oct 3rd, 2006, and Asus claims 1101 supports e6600.
http://drivers.softpedia.com/get/BIOS/Asus/Asus-P5W-DH-Deluxe-BIOS-1407.shtml

Could you show more information such as bios version, bios configuration
and binary data of 'cat /proc/acpi/dsdt > dsdt.raw'?

Comment 2 Matthew 2006-10-18 08:25:23 UTC
as far as I know I am using the latest: 1407
I don't know if that helps but MMconfig seems to be broken with this bios 

and I also get a e820 something message

which part of bios configuration do you want to know, everything ?

Comment 3 Matthew 2006-10-18 08:49:53 UTC
hm, sorry for that useless question ...
thanks for you help, btw:

here ist the relevant information:

Version: 1407
Build Date: 09/26/06
(so it is the newest version I can think of)

** CPU Configuration ** 
Modify Ratio support: [Disabled]
Microcode Updation: [Enabled]
Max CPUID Value Limit: [Enabled]
Execute Disable Function: [Enabled]
Enhanced C1 Control: [Auto]
CPU Internal Thermal Control: [Auto]
Intel(R) SpeedStep(tm) tech.: [Automatic]

** PCIPnP **
Plug And Play O/S: [No]
PCI Latency Timer: 64
Allocate IRQ to VGA: [Yes]
Palette Snooping: [Disabled]
IRQ (3-15) assigned to: [PCI Device]

** Power **
Suspend Mode: [Auto]
Repost Video on S3 Resume [Yes]
ACPI 2.0 Support: [Yes]
ACPI APIC Support [Yes]

** APM **
Power Button Mode [On/Off]
Restore on AC Power Loss [Power Off]
Comment 4 Matthew 2006-10-18 08:50:36 UTC
Created attachment 9295 [details]
dsdt.raw (made out of 2.6.19-rc2-mm1)
Comment 5 Matthew 2006-10-18 08:51:22 UTC
Created attachment 9296 [details]
dmesg for 2.6.19-rc2-mm1
Comment 6 Venkatesh Pallipadi 2006-10-18 09:15:18 UTC
This seems to be broken BIOS _PSS table. Can you attach the entire acpidump 
output. You can find acpidump in latest version of pmtools here

http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
Comment 7 Matthew 2006-10-18 09:51:46 UTC
Created attachment 9297 [details]
full acpidump

when executing acpidump I get a "Wrong checksum for generic table!" error, so
something must be broken ...
Comment 8 Matthew 2006-10-18 10:00:59 UTC
the version of pmtools I used is 20060606 (if this information is needed)
Comment 9 Matthew 2006-10-18 15:02:33 UTC
Created attachment 9301 [details]
acpidump of bios version 1502 (little changes)

I've just downloaded & installed bios version 1502 for this board (P5W DH
Deluxe, Asus) frequency changing still doesn't work, but now there is only
shown 2 "effective" frequencies 
the 2.4 GHZ (in MHz), the 1.6 GHz (in MHz) and some 0 (zeros)
Comment 10 Matthew 2006-10-18 15:03:32 UTC
I got the new bios version from this site:
http://www.forumdeluxx.de/forum/showthread.php?threadid=256507 
Comment 11 Matthew 2006-10-19 02:14:12 UTC
with bios version 1502 I get the following:

cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
2394000

cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
0
(the minimal frequency seems still broken)

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2394000 1596000 0 0 0 0 0 0 0 0

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
acpi-cpufreq

powernowd therefore shows the following:
powernowd -v
powernowd: PowerNow Daemon v0.90hun6, (c) 2003-2004 John Clemens
powernowd: Settings:
powernowd:   verbosity:        1
powernowd:   mode:             1     (AGGRESSIVE)
powernowd:   step:           100 MHz (100000 kHz)
powernowd:   lowwater:        20 %
powernowd:   highwater:       80 %
powernowd:   poll interval: 1000 ms
powernowd: Found 1 physical cpu and 2 virtual cpus:
powernowd: cpu0: 0 kHz - 2394000 kHz

Comment 12 Venkatesh Pallipadi 2006-10-19 06:11:55 UTC
BIOS seems to be using secondary table here for P-satet support. So, there is
not much info in acpidump.

OperationRegion (STBL, SystemMemory, 0x7FF89540, 0x02E3)
OperationRegion (STBL, SystemMemory, 0x7FF89830, 0x02DA)

So, we will need dump of these addresses as well.
You can use something like
acpidump -a 0x7FF89540 -l 0x2E3
acpidump -a 0x7FF89830 -l 0x2da

and attach the output here.

Thanks.
Comment 13 Matthew 2006-10-19 13:04:02 UTC
Created attachment 9307 [details]
0x2E3 area
Comment 14 Matthew 2006-10-19 13:04:31 UTC
Created attachment 9308 [details]
0x2da area
Comment 15 Matthew 2006-10-20 07:57:28 UTC
hope they are the right outputs ...

thanks
Comment 16 Matthew 2006-10-21 05:19:11 UTC
this bug also applies to 2.6.19-rc2-mm2 for me ...
Comment 17 Venkatesh Pallipadi 2006-10-21 09:56:20 UTC
Bios seems to be listing the frequencies cleanly. I see 2 frequency entries for
2394 and 1596 MHz. So thinsg are OK from that aspect. 

Only issue as far as I see is minumum frequency being told as zero. That is most
likely a kernel bug. Does cpu frequency scaling work cleanly for you despite of
this issue. I mean, does scaling_cur_freq show 1.6 when system is idle and 2.4
when system is busy?

Comment 18 Matthew 2006-10-21 14:05:37 UTC
no, unfortunately it doesn't ...

I've just updated to the testing version of powernowd (0.97) & rebooted the
computer and
the frequency switching applet of gnome now shows only 3 frequencies:
252.65 GHz
2.39 GHz
1.60 GHz

before I wrote this I started powernowd at in the current frequency it showed:
252645135
& gnome frequency switching applet 252... GHZ (!)

therefore I immediately turned it off

cat now shows:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2394000 1596000 252645135 252645135 252645135 252645135 252645135 252645135
252645135 252645135


sorry, if I have to write this, but this case is getting to "hot" for me:
since I don't know if I can do any harm to the hardware by going further in
testing configurations / ... && I am really dependent on this PC (I am studying
and getting into higher semester and put money aside for a really long time to
be able to buy this) I won't try any further if I have no guarantee that there
won't be any consequences / it will work in the near future 

thanks for you help so far 
Comment 19 Matthew 2006-10-21 15:42:04 UTC
to make it clear:

- the absence of frequency switching function lies in the "stable" release of
powernowd
- when the most recent version is emerged 0.97 (Gentoo), frequency switching
"shomehow" works by switching to 252-something GHz but it stays there as far as
I can observe so down-switching isn't working (I immediately turned off the PC
as I don't know if it will damage hardware; can you please give me information
if damage can occur in this case?)
- frequency table seems to be pretty broken: frequencies from 730.80 GHz to
-1894840 MHz [negative value] (seems to change from session to session / reboot)

hope that helps 
Comment 20 Matthew 2006-10-22 01:41:28 UTC
as aspected: it changes everytime the available frequencies at a reboot:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2394000 1596000 235867919 1309609769 -1893789937 218959119 1871646479 151982047
218763151 267079487

if no frequency-switching application is activated (my scaling_governor is
"userspace") it stays at 2394000, if I activate a current frequency-switching
application switching "works" however the frequency is much too high

strangely 
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
1596000

and 
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
38945346

from time to time show correct values 
Comment 21 Matthew 2006-10-23 04:25:33 UTC
this now applies to 2.6.19-rc2-mm2 for me (since I updated yesterday to the new
kernel version) but also applies / should apply to 2.6.19-rc2-mm1:

I could isolate the problem / the cause which leads to all these weird
frequencies shown in 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies :

Power management options (ACPI, APM)  ---> CPU Frequency scaling  ---> 
[ ]     Use ACPI tables to decode valid frequency/voltage (deprecated)  
was set, since this interfered with 

<*>   ACPI Processor P-States driver  

for me, this somehow caused wrong readout of frequency values 

the "safe" (mostly showing valid values) configuration now is:

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=y
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=y
# CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI is not set
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_SMI is not set
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set

when a frequency-switching daemon is started it however still shows "0" (zero)

in /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

/proc/cpuinfo
stays at
 cpu MHz         : 2394.000

so switching still doesn't work ...
Comment 22 Alexey Starikovskiy 2006-10-23 04:33:38 UTC
Created attachment 9330 [details]
additional printout about p-states

Please add this patch and send dmesg. Also please try to disable CPU_HOTPLUG.
Comment 23 Matthew 2006-10-23 05:21:24 UTC
thanks for that patch, unfortunately the kernel doesn't want to compile:

 CC      drivers/acpi/tables.o
  CC      drivers/acpi/blacklist.o
  CC      drivers/acpi/osl.o
  CC      drivers/acpi/utils.o
  CC      drivers/acpi/dispatcher/dsfield.o
  CC      drivers/acpi/dispatcher/dsmthdat.o
  CC      drivers/acpi/dispatcher/dsopcode.o
  CC      drivers/acpi/dispatcher/dswexec.o
  CC      drivers/acpi/dispatcher/dswscope.o
  CC      drivers/acpi/dispatcher/dsmethod.o
  CC      drivers/acpi/dispatcher/dsobject.o
  CC      drivers/acpi/dispatcher/dsutils.o
  CC      drivers/acpi/dispatcher/dswload.o
  CC      drivers/acpi/dispatcher/dswstate.o
  CC      drivers/acpi/dispatcher/dsinit.o
  LD      drivers/acpi/dispatcher/built-in.o
  CC      drivers/acpi/events/evevent.o
  CC      drivers/acpi/events/evregion.o
  CC      drivers/acpi/events/evsci.o
  CC      drivers/acpi/events/evxfevnt.o
  CC      drivers/acpi/events/evmisc.o
drivers/acpi/events/evmisc.c: In function 'acpi_ev_global_lock_handler':
drivers/acpi/events/evmisc.c:334: warning: unused variable 'status'
  CC      drivers/acpi/events/evrgnini.o
  CC      drivers/acpi/events/evxface.o
  CC      drivers/acpi/events/evxfregn.o
  CC      drivers/acpi/events/evgpe.o
  CC      drivers/acpi/events/evgpeblk.o
  LD      drivers/acpi/events/built-in.o
  CC      drivers/acpi/executer/exconfig.o
  CC      drivers/acpi/executer/exfield.o
  CC      drivers/acpi/executer/exnames.o
  CC      drivers/acpi/executer/exoparg6.o
  CC      drivers/acpi/executer/exresolv.o
  CC      drivers/acpi/executer/exstorob.o
  CC      drivers/acpi/executer/exconvrt.o
  CC      drivers/acpi/executer/exfldio.o
  CC      drivers/acpi/executer/exoparg1.o
  CC      drivers/acpi/executer/exprep.o
  CC      drivers/acpi/executer/exresop.o
  CC      drivers/acpi/executer/exsystem.o
  CC      drivers/acpi/executer/excreate.o
  CC      drivers/acpi/executer/exmisc.o
  CC      drivers/acpi/executer/exoparg2.o
  CC      drivers/acpi/executer/exregion.o
  CC      drivers/acpi/executer/exstore.o
  CC      drivers/acpi/executer/exutils.o
  CC      drivers/acpi/executer/exdump.o
  CC      drivers/acpi/executer/exmutex.o
  CC      drivers/acpi/executer/exoparg3.o
  CC      drivers/acpi/executer/exresnte.o
  CC      drivers/acpi/executer/exstoren.o
  LD      drivers/acpi/executer/built-in.o
  CC      drivers/acpi/hardware/hwacpi.o
  CC      drivers/acpi/hardware/hwgpe.o
  CC      drivers/acpi/hardware/hwregs.o
  CC      drivers/acpi/hardware/hwsleep.o
  LD      drivers/acpi/hardware/built-in.o
  CC      drivers/acpi/namespace/nsaccess.o
  CC      drivers/acpi/namespace/nsload.o
  CC      drivers/acpi/namespace/nssearch.o
  CC      drivers/acpi/namespace/nsxfeval.o
  CC      drivers/acpi/namespace/nsalloc.o
  CC      drivers/acpi/namespace/nseval.o
  CC      drivers/acpi/namespace/nsnames.o
  CC      drivers/acpi/namespace/nsutils.o
  CC      drivers/acpi/namespace/nsxfname.o
  CC      drivers/acpi/namespace/nsdump.o
  CC      drivers/acpi/namespace/nsinit.o
  CC      drivers/acpi/namespace/nsobject.o
  CC      drivers/acpi/namespace/nswalk.o
  CC      drivers/acpi/namespace/nsxfobj.o
  CC      drivers/acpi/namespace/nsparse.o
  LD      drivers/acpi/namespace/built-in.o
  CC      drivers/acpi/parser/psargs.o
  CC      drivers/acpi/parser/psparse.o
  CC      drivers/acpi/parser/psloop.o
  CC      drivers/acpi/parser/pstree.o
  CC      drivers/acpi/parser/pswalk.o
  CC      drivers/acpi/parser/psopcode.o
  CC      drivers/acpi/parser/psscope.o
  CC      drivers/acpi/parser/psutils.o
  CC      drivers/acpi/parser/psxface.o
  LD      drivers/acpi/parser/built-in.o
  CC      drivers/acpi/resources/rsaddr.o
  CC      drivers/acpi/resources/rscreate.o
  CC      drivers/acpi/resources/rsinfo.o
  CC      drivers/acpi/resources/rsio.o
  CC      drivers/acpi/resources/rslist.o
  CC      drivers/acpi/resources/rsmisc.o
  CC      drivers/acpi/resources/rsxface.o
  CC      drivers/acpi/resources/rscalc.o
  CC      drivers/acpi/resources/rsirq.o
  CC      drivers/acpi/resources/rsmemory.o
  CC      drivers/acpi/resources/rsutils.o
  LD      drivers/acpi/resources/built-in.o
  CC      drivers/acpi/sleep/poweroff.o
  CC      drivers/acpi/sleep/wakeup.o
  LD      drivers/acpi/sleep/built-in.o
  CC      drivers/acpi/tables/tbconvrt.o
  CC      drivers/acpi/tables/tbget.o
  CC      drivers/acpi/tables/tbrsdt.o
  CC      drivers/acpi/tables/tbxface.o
  CC      drivers/acpi/tables/tbgetall.o
  CC      drivers/acpi/tables/tbinstal.o
  CC      drivers/acpi/tables/tbutils.o
  CC      drivers/acpi/tables/tbxfroot.o
  LD      drivers/acpi/tables/built-in.o
  CC      drivers/acpi/utilities/utalloc.o
  CC      drivers/acpi/utilities/utdebug.o
  CC      drivers/acpi/utilities/uteval.o
  CC      drivers/acpi/utilities/utinit.o
  CC      drivers/acpi/utilities/utmisc.o
  CC      drivers/acpi/utilities/utxface.o
  CC      drivers/acpi/utilities/utcopy.o
  CC      drivers/acpi/utilities/utdelete.o
  CC      drivers/acpi/utilities/utglobal.o
  CC      drivers/acpi/utilities/utmath.o
  CC      drivers/acpi/utilities/utobject.o
  CC      drivers/acpi/utilities/utstate.o
  CC      drivers/acpi/utilities/utmutex.o
  CC      drivers/acpi/utilities/utcache.o
  CC      drivers/acpi/utilities/utresrc.o
  LD      drivers/acpi/utilities/built-in.o
  CC      drivers/acpi/bus.o
  CC      drivers/acpi/glue.o
  CC      drivers/acpi/ac.o
  CC      drivers/acpi/battery.o
  CC      drivers/acpi/button.o
  CC      drivers/acpi/ec.o
  CC      drivers/acpi/fan.o
  CC      drivers/acpi/video.o
  CC      drivers/acpi/pci_root.o
  CC      drivers/acpi/pci_link.o
  CC      drivers/acpi/pci_irq.o
  CC      drivers/acpi/pci_bind.o
  CC      drivers/acpi/power.o
  CC      drivers/acpi/processor_core.o
  CC      drivers/acpi/processor_throttling.o
  CC      drivers/acpi/processor_idle.o
  CC      drivers/acpi/processor_thermal.o
  CC      drivers/acpi/processor_perflib.o
drivers/acpi/processor_perflib.c: In function
'acpi_processor_get_performance_states':
drivers/acpi/processor_perflib.c:284: error: expected ';' before ')' token
drivers/acpi/processor_perflib.c:284: error: expected statement before ')' token
drivers/acpi/processor_perflib.c: In function 'acpi_processor_register_performance':
drivers/acpi/processor_perflib.c:791: warning: implicit declaration of function
'acpi_processor_get_performance_info'
make[2]: *** [drivers/acpi/processor_perflib.o] Error 1
make[1]: *** [drivers/acpi] Error 2
make: *** [drivers] Error 2
Comment 24 Matthew 2006-10-23 05:35:16 UTC
I changed:

(u32) px->control, (u32) px->status)); 

to

(u32) px->control, (u32) px->status);

in line 284 & it compiled fine 

is that the right fix for this error ?

thanks 
Comment 25 Alexey Starikovskiy 2006-10-23 05:50:06 UTC
yes, sure.
Comment 26 Matthew 2006-10-23 06:08:55 UTC
Created attachment 9331 [details]
dmesg with p-states patch, 2.6.19-rc2-mm2
Comment 27 Matthew 2006-10-23 06:10:27 UTC
Created attachment 9332 [details]
kernel-config of 2.6.19-rc2-mm2
Comment 28 Alexey Starikovskiy 2006-10-23 06:37:09 UTC
so far, so good :)
P-states are found correctly, error seems to be in duplicates elimination code.
Comment 29 Matthew 2006-10-23 06:48:10 UTC
that's good news, thanks :)
Comment 30 Alexey Starikovskiy 2006-10-23 06:55:15 UTC
Created attachment 9333 [details]
Fix error in duplicate elimination code

This patch should fix the problem... Please check
Comment 31 Matthew 2006-10-23 09:24:22 UTC
ok, thanks, testing it right now ...
Comment 32 Matthew 2006-10-23 09:46:30 UTC
the switching functionality seems to be there, at least for cpu0 (using cpufreqd):

cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to linux@brodo.de, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0
  hardware limits: 1.60 GHz - 2.39 GHz
  available frequency steps: 2.39 GHz, 1.60 GHz
  available cpufreq governors: conservative, ondemand, powersave, userspace, per
formance
  current policy: frequency should be within 1.60 GHz and 2.39 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 2.39 GHz.
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 1
  hardware limits: 1.60 GHz - 2.39 GHz
  available frequency steps: 2.39 GHz, 1.60 GHz
  available cpufreq governors: conservative, ondemand, powersave, userspace, per
formance
  current policy: frequency should be within 1.60 GHz and 1.60 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.

I'm going to compile some software, looking if I can figure out what's wrong
with switching ...
Comment 33 Matthew 2006-10-23 09:54:03 UTC
ok, this bug seems to be solved, switching now works fine, although it still
shows 0 MHz in the gnome "CPU Frequency Scaling Monitor" (2.14.2), when switched
down in frequency 

cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to linux@brodo.de, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0
  hardware limits: 1.60 GHz - 2.39 GHz
  available frequency steps: 2.39 GHz, 1.60 GHz
  available cpufreq governors: conservative, ondemand, powersave, userspace,
performance
  current policy: frequency should be within 1.60 GHz and 2.39 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 2.39 GHz.
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 1
  hardware limits: 1.60 GHz - 2.39 GHz
  available frequency steps: 2.39 GHz, 1.60 GHz
  available cpufreq governors: conservative, ondemand, powersave, userspace,
performance
  current policy: frequency should be within 1.60 GHz and 2.39 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.

thanks a lot! you rock :)
Comment 34 Alexey Starikovskiy 2006-10-23 11:30:06 UTC
Thank you for report and testing :) Marking it resolved.
Comment 35 Matthew 2006-10-26 06:36:31 UTC
Created attachment 9362 [details]
dmesg of 2.6.19-rc2-mm2, amd64

I'm afraid this has to be re-opened:

I've just tried out the kernel on amd64 an I get the following message when
cpufreqd is being started:

Unable to handle kernel paging request at ffff81047ee10954 RIP: 
 [<ffffffff80545ed6>] cpufreq_stat_notifier_trans+0x6b/0x86
PGD 8063 PUD 0 
Oops: 0002 [1] PREEMPT SMP 
last sysfs file: /devices/system/cpu/cpu1/cpufreq/scaling_governor
CPU 0 
Modules linked in: w83627ehf eeprom lm90 i2c_isa xt_limit iptable_mangle
ipt_LOG ipt_MASQUERADE ip_nat ipt_TOS ipt_REJECT xt_state iptable_filter usblp
cx88_alsa cx8800 cx8802 cx88xx compat_ioctl32 ir_common tveeprom videodev
v4l1_compat btcx_risc ohci1394 video_buf v4l2_common ieee1394 i2c_i801
Pid: 9106, comm: kondemand/0 Not tainted 2.6.19-rc2-mm2 #1
RIP: 0010:[<ffffffff80545ed6>]	[<ffffffff80545ed6>]
cpufreq_stat_notifier_trans+0x6b/0x86
RSP: 0018:ffff81007a517cf0  EFLAGS: 00010292
RAX: ffff81047ee10954 RBX: ffff81007ee10c00 RCX: ffff81007ee10940
RDX: ffff81007e1d8100 RSI: ffff81007ee10c00 RDI: ffffffff80890900
RBP: 00000000ffffffff R08: 0000000000000002 R09: 0000000000000002
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: ffff81007a517dc0 R14: ffffffff808908c0 R15: 0000000000000001
FS:  0000000000000000(0000) GS:ffffffff807dc000(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff81047ee10954 CR3: 000000007c12d000 CR4: 00000000000006e0
Process kondemand/0 (pid: 9106, threadinfo ffff81007a516000, task
ffff81007e1d8100)
Stack:	0000000000000286 0000000000000000 ffff81007a517dc0 0000000000000001
 0000000000000000 ffffffff8028e702 ffffffff808908f0 ffff81007ee0a400
 ffff81007a517dc0 ffffffff8028f14e ffff81007a517dc0 ffff81007ee03540
Call Trace:
 [<ffffffff8028e702>] notifier_call_chain+0x20/0x32
 [<ffffffff8028f14e>] srcu_notifier_call_chain+0x33/0x4c
 [<ffffffff805445dd>] cpufreq_notify_transition+0x7f/0x95
 [<ffffffff8027433a>] acpi_cpufreq_target+0x27f/0x2b3
 [<ffffffff80546efc>] do_dbs_timer+0x1d9/0x26b
 [<ffffffff80546d23>] do_dbs_timer+0x0/0x26b
 [<ffffffff8024b24d>] run_workqueue+0x93/0xe1
 [<ffffffff80247b17>] worker_thread+0x0/0x119
 [<ffffffff802940f9>] keventd_create_kthread+0x0/0x66
 [<ffffffff80247bfe>] worker_thread+0xe7/0x119
 [<ffffffff80282fa6>] default_wake_function+0x0/0xe
 [<ffffffff802940f9>] keventd_create_kthread+0x0/0x66
 [<ffffffff8022ffca>] kthread+0xd1/0x100
 [<ffffffff8025cf05>] child_rip+0xa/0x15
 [<ffffffff802940f9>] keventd_create_kthread+0x0/0x66
 [<ffffffff8022fef9>] kthread+0x0/0x100
 [<ffffffff8025cefb>] child_rip+0x0/0x15


Code: ff 00 ff 43 04 48 c7 c7 00 09 89 80 e8 7e e6 d1 ff 31 c0 59 
RIP  [<ffffffff80545ed6>] cpufreq_stat_notifier_trans+0x6b/0x86
 RSP <ffff81007a517cf0>
CR2: ffff81047ee10954
 <6>note: kondemand/0[9106] exited with preempt_count 1

frequency-switching also doesn't seem to work on amd64

I don't know if this related to the kernel or cpufreqd since it says:

Modules linked in: w83627ehf eeprom lm90 i2c_isa xt_limit iptable_mangle
ipt_LOG ipt_MASQUERADE ip_nat ipt_TOS ipt_REJECT xt_state iptable_filter usblp
cx88_alsa cx8800 cx8802 cx88xx compat_ioctl32 ir_common tveeprom videodev
v4l1_compat btcx_risc ohci1394 video_buf v4l2_common ieee1394 i2c_i801
Pid: 9106, comm: kondemand/0 Not tainted 2.6.19-rc2-mm2 #1
Comment 36 Matthew 2006-10-26 06:40:43 UTC
I did some more testing & this doesn't seem to be related to cpufreqd ...

so the kernel needs some more patching ...

thanks in advance for your help 
Comment 37 Matthew 2006-10-26 06:42:40 UTC
Created attachment 9363 [details]
kernel-config of 2.6.19-rc2-mm2, amd64
Comment 38 Matthew 2006-10-30 02:00:22 UTC
sorry if that sounded harsh, but sometimes it's pretty difficult to find the
right words/terms (since I'm not a native-speaker)

btw: that error still occurs on 2.6.19-rc3-mm1

Comment 39 Matthew 2006-10-30 03:41:08 UTC
Created attachment 9376 [details]
kernel-config of 2.6.19-rc3-mm1 (x86)

the upper frequency and the second frequency under 
"/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies" are
correct: 2394000 1596000 

the other frequencies are either too low (negative values) or much too high
(e.g. 17 GigaHz) 

under 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 
2394000
it only shows the highest value, when a frequency-switching app is activated
the current frequencies is the same

please help, I'd really like to move to the 2.6.19*-branch since it's support
of my hardware "feels" (incl. reiser4) much better

hope that this patch will make it into the final 2.6.19-kernel to remove those
strange frequency duplicates ...

thanks in advance
Comment 40 Matthew 2006-11-05 08:37:27 UTC
a "workaround" for this issue / problem which works for me is:

using the Enhanced SpeedStep frequency-scaling driver:

<*>   Intel Enhanced SpeedStep                                                   
[*]     Use ACPI tables to decode valid frequency/voltage (deprecated) (NEW)     
[*]     Built-in tables for Banias CPUs (NEW)  

and deselecting the ACPI Processor P-States driver:

< >   ACPI Processor P-States driver  


/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver 
centrino

/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 
2394000 2394000 2394000 2394000 2394000 2394000 2394000 2394000 2394000 1596000 

/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 
1596000
(ondemand governor is activated by cpufreqd)

/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 
2394000

/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 
1596000


Is is possible to leave this driver (X86_SPEEDSTEP_CENTRINO) in the kernel &
maintain it until the problems are really solved / working with X86_ACPI_CPUFREQ ?

Thanks in advance 
Comment 41 Matthew 2006-11-05 09:11:06 UTC
this was tested & worked on:

- 2.6.18-mm1, 2.6.18-mm2
- 2.6.19-rc4-mm2 (+ 2.6.19-rc4-mm1)

with Intel Core 2 Duo (Conroe 6600) & Asus P5W DH Deluxe

thanks again for your help
Comment 42 Venkatesh Pallipadi 2006-11-05 10:35:01 UTC
Matthew: Are you saying that Alexey's patch in comment #30 does not work in
2.6.19-rc3-mm1? Or is it that the patch was not included in 2.6.19-rc3-mm1?

Alexey: Can you please push your patch towards Andrew..
Comment 43 Matthew 2006-11-05 10:57:26 UTC
> this was tested & worked on

sorry, I should have made myself clear:

with "this was tested" I meant the centrino-driver

in addition to that I tested the CPUFREQ-driver from 2.6.19-rc3-mm1 through the
current (2.6.19-rc4-mm1 / 2.6.19-rc4-mm2) and it didn't work (on both x86 & x86_64)

the patch also did not work on amd64-architecture (x86_64) as I can be seen in
the message from #35

I'm going to test the patch from #30 on 2.6.19-rc3-mm1 & current kernels when
I'm ready with my work (+ compiling)
(don't know if the patch was included, but as 2.6.19-rc3-mm1 behaves, it wasn't)
Comment 44 Matthew 2006-11-05 13:20:45 UTC
ok here are the results for x86:

on first boot I got a kernel-panik so I had to remove ALSA, I forgot this, that
was the reason why I skipped the usage of this kernel (snd_register_device_for_dev)

------------------------------------------------------------
2.6.19-rc3-mm1 (non-patched)

scaling_available_frequencies 
shows: 2394000 1596000 0 0 0 0 0 0 0 0 (so the duplicates elimination doesn't
apply / work here)

if I start cpufreqd I get a kernelBUG (shown in dmesg of unpatched 2.6.19-rc3-mm1)
and if I look under

scaling_max_freq 1596000
scaling_min_freq 50

so something's wrong here ... 

=> the patch or parts of it were applied (?) but doesn't work that well


------------------------------------------------------------
2.6.19-rc3-mm1 (patched with Alexey's patch)

scaling_available_frequencies 
2394000 1596000 

(this is ok)

when I start cpufreqd I get 0 (zero) under
scaling_min_freq

and the frequency doesn't change under
cat /proc/cpuinfo

I don't know if this only is of cosmetical nature, but as I know some programs
depend on the output of /proc/cpuinfo

hope this data and the data in the attachment is useful ...
Comment 45 Matthew 2006-11-05 13:23:55 UTC
Created attachment 9411 [details]
dmesg of 2.6.19-rc3-mm1 (x86) unpatched + after start of cpufreqd (kernel BUG)

I also get this kernel BUG message / error on 2.6.19-rc4-mm1 (+ should be the
same for 2.6.19-rc4-mm2)
Comment 46 Matthew 2006-11-09 00:47:02 UTC
Created attachment 9438 [details]
dmesg 2.6.19-rc5-mm1 (x86), kernelBUG

this bug also occurs in 2.6.19-rc5-mm1 (tested on x86)
Comment 47 Alexey Starikovskiy 2006-11-09 01:11:23 UTC
does the patch I made fix the problem? If it does, I can move it into -mm, but 
if it does not, then we need to find another...
Comment 48 Matthew 2006-11-09 02:59:49 UTC
I think it doesn't solve the problem 100%:

1) it only addresses the BUG on x86,(arch/i386/kernel/cpu/cpufreq/) could you
please extend it to amd64 (x86_64) / a patch / part for amd64, too ? it didn't
work for me on amd64 
2) as I see on the cpu frequency scaling monitor in gnome it switches between
frequencies, but it shows 0 (zero) when on the lowest frequency
-> the same also on /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq when
running with ondemand governor under low load (+ cpu1) => 0 (zero)
-> so something elsewhere isn't playing fine with this duplication elimination
code (I guess)
3) this also seems to affect the output of /proc/cpuinfo
-> there's actually no change of frequency whether I have performance or
ondemand governor (with little / no load)
-> this is also important since lots of applications seems to rely on its output
(very important for my laptop / laptops !)

Thanks in advance for your help, Alexey
Comment 49 Alexey Starikovskiy 2006-11-09 05:38:54 UTC
i386 and x86_64 share this file, so patch either fixes both arches or nothing.
please attach dmesg from run of x86_64 + patch.
Comment 50 Alexey Starikovskiy 2006-11-09 07:08:57 UTC
Created attachment 9443 [details]
Cleaned patch for acpi-cpufreq.c duplicates removal
Comment 51 Alexey Starikovskiy 2006-11-09 07:10:49 UTC
Created attachment 9444 [details]
Another way to fix the duplicates removal...

Please try if any of these two patches fix your problem. They should work on
i386 _and_ X86_64.
Comment 52 Matthew 2006-11-10 02:01:22 UTC
your second patch from (#51) works perfectly on x86, but on amd64 / x86_64 I get
a kernel-panic

*snip*

Code: 83 00 01 83 43 04 01 48 c7 c7 00 f9 8a 80 e8 25 2b cf ff 31
RIP [<ffffffff80572c49>] cpufreq_stat_notifier_trans+0x6c/0x8c
   RSP <ffff81007ff1fb00>
CR2: ffff81047ef79a50
<0>Kernel panic - not syncing: Attempted to kill init!

*snip*
(hope these last lines are enough, since I had to write them down)

--------------------------------------------------------

your 1st patch from (#50) doesn't seem to work on x86:
I get 0 (zero) under scaling_cur_freq  when frequency scaling is activated
/proc/cpuinfo stays the same (2404 MHZ)

when frequency scaling is activated on x86_64 (amd64) I get a kernelBUG / error
-> the only option to restart the computer after that is via Magic SysRQ key or
Reset
dmesg of this bug can be found in next attachment 
Comment 53 Matthew 2006-11-10 02:03:14 UTC
Created attachment 9449 [details]
dmesg of 2.6.19-rc4-mm2 with output after cpufreq-activation (amd64), 1st patch (#50)
Comment 54 Matthew 2006-11-10 02:03:24 UTC
Created attachment 9450 [details]
dmesg of 2.6.19-rc5-mm1 with output after cpufreq-activation (amd64), 1st patch (#50)
Comment 55 Matthew 2006-11-10 02:05:24 UTC
Comment on attachment 9449 [details]
dmesg of 2.6.19-rc4-mm2 with output after cpufreq-activation (amd64), 1st patch (#50)

wrong description ...
Comment 56 Alexey Starikovskiy 2006-11-10 06:52:49 UTC
Matthew,
It looks like you are still applying #9330 or #9333 patches. Could you please
try if clean -mm tree + either patch #9443 or #9444 work?
I can reproduce your problem here on 16-cpu box and both above patches work.
Comment 57 Matthew 2006-11-11 02:25:18 UTC
>It looks like you are still applying #9330 or #9333 patches. Could you please
>try if clean -mm tree + either patch #9443 or #9444 work?
>I can reproduce your problem here on 16-cpu box and both above patches work.

I tried those patches again on a clean 2.6.19-rc4-mm2 and 2.6.19-rc5-mm1 but
still the same:
#9443 doesn't work for me (neither on x86 nor on x86_64)

and #9444 only works on x86 but not on x86_64 (amd64) (I get the kernel-panic)

could you please send me your kernel-config? perhaps I misconfigured anything ...

Thanks in advance
Comment 58 Alexey Starikovskiy 2006-11-16 12:32:57 UTC
Created attachment 9533 [details]
fix for srcu breaking cpufreq notify from Ingo Molnar

It seems that there are more than one bug here... please look if this patch
with #9443 helps...
Comment 59 Matthew 2006-11-18 06:26:02 UTC
your patch / attachment points me to http://lkml.org/lkml/diff/2006/11/16/182/1

>arch/x86_64/kernel/tsc.c

sorry but this file doesn't exist ?!
I looked in 2.6.19-rc4-mm2 through 2.6.19-rc5-mm2
but there's only tce.c, not tsc.c 
Comment 60 Matthew 2006-11-29 14:39:22 UTC
nevermind, it works now, thanks Alexey & the others for your help,

sorry for the long absence of input (2.6.19-rc5-mm2 wouldn't boot &
2.6.19-rc6-mm1 wouldn't compile for me, so I couldn't find out if that
integrated patch works for me), I'm using now 2.6.19-rc6-mm2 and
frequency-switching via ondemand governor works just fine =)

the only change I made from earlier configurations was to set 
Default CPUFreq governor (performance)

instead of 

Default CPUFreq governor (userspace)

and then start cpufreqd to switch governor to ondemand

so this bug can finally be closed

Note You need to log in before you can comment on or make changes to this bug.