Bug 7383
Description
Matthew
2006-10-18 01:53:26 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'? 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 ? 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] Created attachment 9295 [details]
dsdt.raw (made out of 2.6.19-rc2-mm1)
Created attachment 9296 [details]
dmesg for 2.6.19-rc2-mm1
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/ Created attachment 9297 [details]
full acpidump
when executing acpidump I get a "Wrong checksum for generic table!" error, so
something must be broken ...
the version of pmtools I used is 20060606 (if this information is needed) 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)
I got the new bios version from this site: http://www.forumdeluxx.de/forum/showthread.php?threadid=256507 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 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. Created attachment 9307 [details]
0x2E3 area
Created attachment 9308 [details]
0x2da area
hope they are the right outputs ... thanks this bug also applies to 2.6.19-rc2-mm2 for me ... 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? 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 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 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 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 ... Created attachment 9330 [details]
additional printout about p-states
Please add this patch and send dmesg. Also please try to disable CPU_HOTPLUG.
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 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 yes, sure. Created attachment 9331 [details]
dmesg with p-states patch, 2.6.19-rc2-mm2
Created attachment 9332 [details]
kernel-config of 2.6.19-rc2-mm2
so far, so good :) P-states are found correctly, error seems to be in duplicates elimination code. that's good news, thanks :) Created attachment 9333 [details]
Fix error in duplicate elimination code
This patch should fix the problem... Please check
ok, thanks, testing it right now ... 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 ... 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 :) Thank you for report and testing :) Marking it resolved. 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
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 Created attachment 9363 [details]
kernel-config of 2.6.19-rc2-mm2, amd64
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 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
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 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 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.. > 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)
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 ... 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)
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)
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... 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 i386 and x86_64 share this file, so patch either fixes both arches or nothing. please attach dmesg from run of x86_64 + patch. Created attachment 9443 [details]
Cleaned patch for acpi-cpufreq.c duplicates removal
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.
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 Created attachment 9449 [details]
dmesg of 2.6.19-rc4-mm2 with output after cpufreq-activation (amd64), 1st patch (#50)
Created attachment 9450 [details]
dmesg of 2.6.19-rc5-mm1 with output after cpufreq-activation (amd64), 1st patch (#50)
Comment on attachment 9449 [details]
dmesg of 2.6.19-rc4-mm2 with output after cpufreq-activation (amd64), 1st patch (#50)
wrong description ...
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. >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
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...
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 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 |