little system-hang when switching frequencies
hello cpufreq-team,
---
basically this is my debian-cpufreqd-bugreport (#253299), but they advised me to also try it on your list
---
using speedstep_smi, i get little "cpu-hangs" when frequency is switching from a high (here: 1 ghz) to a low (here: 730 mhz) value. for a trickle of a second the systems stops responding (mouse hangs etc), which i noticed especially when listening to music.
this does not occur when switching from low to high frequency.
sorry, i'm not sure if this belongs to the kernel-related cpu-frequency-scaling-drivers...
especially, because the speedstep_ich-module *should* be right for my chipset:
Quoted 3 lines
theo@theoschlepp:~$ lspci 0000:00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 04)
but, only speedstep_smi is usable for me.
Hope i'm right in this place,
thanks in advance,
thomas
ps:
1. from dmesg:
CPU: Intel(R) Pentium(R) III Mobile CPU 1000MHz stepping 01
2. from /var/log/messages:
cpufreqd: parse_config_general(): ACPI workaround enabled.
3. using debian-kernel-source-package (kernel-source-2.6.6) with following part-.config:
(the same behaviour was with kernel-source-2.6.5)
---
# CPU Frequency scaling
#CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_PROC_INTF is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=m CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_24_API is not set CONFIG_CPU_FREQ_TABLE=y
#
# CPUFreq processor drivers
#
# CONFIG_X86_ACPI_CPUFREQ is not set
# 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 is not set CONFIG_X86_SPEEDSTEP_ICH=m CONFIG_X86_SPEEDSTEP_SMI=m
# CONFIG_X86_P4_CLOCKMOD is not set CONFIG_X86_SPEEDSTEP_LIB=m
# CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set # CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set
---
Signature · 4 lines
____________________________________________ Thomas Breitner [email protected] | http://www.tombreit.de
Hi,
Quoted 4 lines · Thomas Breitner
using
speedstep_smi, i get little "cpu-hangs" when frequency is switching from a high (here: 1 ghz) to a low (here: 730 mhz) value. for a trickle of a second the systems stops responding (mouse hangs etc), which i noticed especially when listening to music.
This doesn't really surprise me. speedstep-smi is "1st generation speedstep", which was neither intended for dynamic frequency scaling nor to be fast. It works by telling the BIOS to change the frequency, which will stop all other activity on the system, then set the new frequency, and then return to the OS. Obviously, this is much slower than a write to a processor MSR, such as the new "Centrino" Pentium-M processors do.
Quoted 1 line
this does not occur when switching from low to high frequency.
In some cases, the BIOS returns an error. Then, empirical testing has shown, delaying for some time and re-trying helps: in the first re-try, the system is stopped for 50 ms, in the second re-try, it's 100 ms, and the third 150 ms, fourth 200 ms, fifth 250 ms -- so it may take up to 750 ms plus the time the BIOS takes until the system becomes responsive again. To determine whether this is the case on your system, uncomment the line //#define SPEEDSTEP_DEBUG
in arch/i386/kernel/cpu/cpufreq/speedstep-smi.c
use your system as usual, and check whether there are messages like
cpufreq: retry 1, previous result 1
in the kernel log
Quoted 2 lines
sorry, i'm not sure if this belongs to the kernel-related cpu-frequency-scaling-drivers...
It does -- though cpufreqd might consider not to load on speedstep-smi driven systems.
Quoted 5 lines
especially, because the speedstep_ich-module *should* be right for my chipset:
Quoted 3 lines
theo@theoschlepp:~$ lspci 0000:00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 04)
Currently, everything which is revision 4 or lower is not handled by speedstep-ich because:
/* speedstep.c causes lockups on Dell Inspirons 8000 and
* 8100 which use a pretty old revision of the 82815
* host brige. Abort on these systems.
*/
If you want to try it out on your system, change the line
if (rev < 5) {
in arch/i386/kernel/cpu/cpufreq/speedstep-ich.c to
if (rev < 4) {re-compile, and test -- but be advised that this might cause lockups!
If it works on your system, then I'll submit a patch which will check for Dell Inspiron 8x00 and only disallow speedstep-ich for them, not for the notebook you're using.
Dominik
Am Mi, den 09.06.2004 schrieb Dominik Brodowski um 17:59:
Quoted 17 lines
Hi,
Quoted 4 lines · Thomas Breitner
using
speedstep_smi, i get little "cpu-hangs" when frequency is switching from a high (here: 1 ghz) to a low (here: 730 mhz) value. for a trickle of a second the systems stops responding (mouse hangs etc), which i noticed especially when listening to music.This doesn't really surprise me. speedstep-smi is "1st generation speedstep", which was neither intended for dynamic frequency scaling nor to be fast. It works by telling the BIOS to change the frequency, which will stop all other activity on the system, then set the new frequency, and then return to the OS. Obviously, this is much slower than a write to a processor MSR, such as the new "Centrino" Pentium-M processors do.
Quoted 1 line
this does not occur when switching from low to high frequency.
Quoted 11 lines
In some cases, the BIOS returns an error. Then, empirical testing has shown, delaying for some time and re-trying helps: in the first re-try, the system is stopped for 50 ms, in the second re-try, it's 100 ms, and the third 150 ms, fourth 200 ms, fifth 250 ms -- so it may take up to 750 ms plus the time the BIOS takes until the system becomes responsive again. To determine whether this is the case on your system, uncomment the line //#define
SPEEDSTEP_DEBUG
inarch/i386/kernel/cpu/cpufreq/speedstep-smi.c
use your system as usual, and check whether there are messages like
cpufreq: retry 1, previous result 1
in the kernel log
yes, you're right, enabling debuging of speedstep-smi gave me:
---
theoschlepp:/home/theo# tail -f /var/log/kern.log Jun 9 21:31:40 localhost kernel: cpufreq: retry 4, previous result 0 Jun 9 21:31:40 localhost kernel: cpufreq: retry 5, previous result 0 Jun 9 21:31:40 localhost kernel: cpufreq: change to 731 MHz succeeded after 6 tries with result 0 Jun 9 21:31:55 localhost kernel: cpufreq: change to 997 MHz succeeded after 1 tries with result 0 Jun 9 21:32:01 localhost kernel: cpufreq: retry 1, previous result 0 Jun 9 21:32:01 localhost kernel: cpufreq: retry 2, previous result 0 Jun 9 21:32:01 localhost kernel: cpufreq: retry 3, previous result 0 Jun 9 21:32:01 localhost kernel: cpufreq: retry 4, previous result 0 Jun 9 21:32:01 localhost kernel: cpufreq: retry 5, previous result 0 Jun 9 21:32:01 localhost kernel: cpufreq: change to 731 MHz succeeded after 6 tries with result 0 Jun 9 21:34:01 localhost kernel: cpufreq: change to 997 MHz succeeded after 1 tries with result 0 Jun 9 21:34:17 localhost kernel: cpufreq: retry 1, previous result 0 Jun 9 21:34:17 localhost kernel: cpufreq: retry 2, previous result 0 Jun 9 21:34:17 localhost kernel: cpufreq: retry 3, previous result 0 Jun 9 21:34:17 localhost kernel: cpufreq: retry 4, previous result 0 Jun 9 21:34:17 localhost kernel: cpufreq: retry 5, previous result 0 Jun 9 21:34:17 localhost kernel: cpufreq: change to 731 MHz succeeded after 6 tries with result 0 ---
i don't understand the meaning of result "0", but it seems that the system needs *only* one - the first - try to switch from low to high frequency - but it needs always 6 retries to switch back. ok, this part is *fixed*, i should buy a new laptop...
Quoted 21 lines
Quoted 2 lines
sorry, i'm not sure if this belongs to the kernel-related cpu-frequency-scaling-drivers...
It does -- though cpufreqd might consider not to load on speedstep-smi driven systems.
Quoted 5 lines
especially, because the speedstep_ich-module *should* be right for my chipset:
Quoted 3 lines
theo@theoschlepp:~$ lspci 0000:00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 04)Currently, everything which is revision 4 or lower is not handled by speedstep-ich because:
/*
speedstep.ccauses lockups on Dell Inspirons 8000 and
* 8100 which use a pretty old revision of the 82815
* host brige. Abort on these systems.
*/If you want to try it out on your system, change the line
Quoted 9 lines
if (rev < 5) { in arch/i386/kernel/cpu/cpufreq/speedstep-ich.c to if (rev < 4) {re-compile, and test -- but be advised that this might cause lockups!
If it works on your system, then I'll submit a patch which will check for Dell Inspiron 8x00 and only disallow speedstep-ich for them, not for the notebook you're using.
the same here: i followed your advise, but seemingly trust too much in my laptop (well, it is in fact an inspiron 8100...):
changed (rev < 5) in (rev < 4) and ended up immediatly after loading speedstep-ich in a lockup (if thats the technical word for a completly non-respondent system).
but: switching frequencies under the preinstalled win xp works "in both directions". how is this possible when it's the bios which is causing the "little system hang"?
thank you very much,
i will forward this story to the associated debian-cpufreqd-bug, thomas
Quoted 6 lines
Dominik
_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq
Signature · 4 lines
______________________________________ thomas breitner www.tombreit.de | [email protected]
Quoted 3 lines · Thomas Breitner
i don't understand the meaning of result "0", but it seems that the system needs *only* one - the first - try to switch from low to high frequency - but it needs always 6 retries to switch back.
Result "0" means there's no postive or negative return value in =D; but the "state" (=b) [ebx?] is still at the old state...
Quoted 3 lines
but: switching frequencies under the preinstalled win xp works "in both directions". how is this possible when it's the bios which is causing the "little system hang"?
Hm, have you tried the ACPI P-States cpufreq driver? Also, it might be that win xp knows more about speedstep-smi than we do, as Intel didn't release any specification on speedstep-smi...
Dominik
Am Do, den 10.06.2004 schrieb Dominik Brodowski um 10:13:
Quoted 5 lines · Thomas Breitner
Quoted 3 lines
i don't understand the meaning of result "0", but it seems that the system needs *only* one - the first - try to switch from low to high frequency - but it needs always 6 retries to switch back.
Quoted 8 lines
Result "0" means there's no postive or negative return value in =D; but the "state" (=b) [ebx?] is still at the old state...
Quoted 3 lines
but: switching frequencies under the preinstalled win xp works "in both directions". how is this possible when it's the bios which is causing the "little system hang"?
Hm, have you tried the ACPI P-States cpufreq driver?
what great idea! it works out of the box! just a little tunig of cpufrqd.conf.
i can now use the two P-states of my p-IIIm (Inspiron 8100):
---
Jun 10 18:48:37 localhost kernel: cpufreq: CPU0 - ACPI performance management activated. Jun 10 18:48:37 localhost kernel: cpufreq: P0: 1000 MHz, 15800 mW, 500 uS Jun 10 18:48:37 localhost kernel: cpufreq: *P1: 733 MHz, 12500 mW, 500
uS
---
and what's best: i have no "little system hangs when switching frequencies" anymore!
thanks a lot, if you don't have any notes i forward this that the debian-cpufreqd-bug can be closed.
cheers,
thomas
Quoted 10 lines
Also, it might be that
win xp knows more about speedstep-smi than we do, as Intel didn't release any specification on speedstep-smi...Dominik
_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq
Signature · 4 lines
______________________________________ thomas breitner www.tombreit.de | [email protected]
Quoted 2 lines · Thomas Breitner
Am Mi, den 09.06.2004 schrieb Dominik Brodowski um 17:59:
Quoted 1 line · Thomas Breitner
...
Quoted 8 lines
Jun 9 21:34:01 localhost kernel: cpufreq: change to 997 MHz succeeded after 1 tries with result 0 Jun 9 21:34:17 localhost kernel: cpufreq: retry 1, previous result 0 Jun 9 21:34:17 localhost kernel: cpufreq: retry 2, previous result 0 Jun 9 21:34:17 localhost kernel: cpufreq: retry 3, previous result 0 Jun 9 21:34:17 localhost kernel: cpufreq: retry 4, previous result 0 Jun 9 21:34:17 localhost kernel: cpufreq: retry 5, previous result 0 Jun 9 21:34:17 localhost kernel: cpufreq: change to 731 MHz succeeded
Quoted 7 lines
after 6 tries with result 0
---i don't understand the meaning of result "0", but it seems that the system needs *only* one - the first - try to switch from low to high frequency - but it needs always 6 retries to switch back. ok, this part is *fixed*, i should buy a new laptop...
It's likely the SMI handler is not able to disable BM arbitration due to DMA tranferts somehow. It may be related to disk io, or sound, etc. Then it give up.
...
Quoted 5 lines
the same here: i followed your advise, but seemingly trust too much in my laptop (well, it is in fact an inspiron 8100...):
changed (rev < 5) in (rev < 4) and ended up immediatly after loading speedstep-ich in a lockup (if thats the technical word for a completly non-respondent system).
For now, I don't have a clue to correct this with this northbridge. We should check bus activities somehow before setting ARB_DIS probably. I believe it's also needed even for other bridges btw.
Quoted 3 lines
but: switching frequencies under the preinstalled win xp works "in both directions". how is this possible when it's the bios which is causing the "little system hang"?
No idea. BTW, are you sure the frequency change under XP? If yes, there is likely a loop which somehow check BM activities (and is able to yield the processor, of course) before calling the SMI handler.
Cheers,
Signature · 4 lines
Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care.