* little system-hang when switching frequencies @ 2004-06-08 18:00 Thomas Breitner 2004-06-09 15:59 ` Dominik Brodowski 0 siblings, 1 reply; 6+ messages in thread From: Thomas Breitner @ 2004-06-08 18:00 UTC (permalink / raw) To: cpufreq 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: >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 --- -- ____________________________________________ Thomas Breitner mail@tombreit.de | http://www.tombreit.de ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: little system-hang when switching frequencies 2004-06-08 18:00 little system-hang when switching frequencies Thomas Breitner @ 2004-06-09 15:59 ` Dominik Brodowski 2004-06-09 21:26 ` Thomas Breitner 0 siblings, 1 reply; 6+ messages in thread From: Dominik Brodowski @ 2004-06-09 15:59 UTC (permalink / raw) To: Thomas Breitner; +Cc: cpufreq Hi, On Tue, Jun 08, 2004 at 08:00:41PM +0200, Thomas Breitner wrote: > 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. > 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 > 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. > especially, because the speedstep_ich-module *should* be right for my > chipset: > >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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: little system-hang when switching frequencies 2004-06-09 15:59 ` Dominik Brodowski @ 2004-06-09 21:26 ` Thomas Breitner 2004-06-10 8:13 ` Dominik Brodowski 2004-06-10 9:08 ` Bruno Ducrot 0 siblings, 2 replies; 6+ messages in thread From: Thomas Breitner @ 2004-06-09 21:26 UTC (permalink / raw) To: Dominik Brodowski; +Cc: cpufreq Am Mi, den 09.06.2004 schrieb Dominik Brodowski um 17:59: > Hi, > > On Tue, Jun 08, 2004 at 08:00:41PM +0200, Thomas Breitner wrote: > > 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. > > > 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 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... > > 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. > > > especially, because the speedstep_ich-module *should* be right for my > > chipset: > > >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. > 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 > Dominik > > _______________________________________________ > Cpufreq mailing list > Cpufreq@www.linux.org.uk > http://www.linux.org.uk/mailman/listinfo/cpufreq -- ______________________________________ thomas breitner www.tombreit.de | mail@tombreit.de ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: little system-hang when switching frequencies 2004-06-09 21:26 ` Thomas Breitner @ 2004-06-10 8:13 ` Dominik Brodowski 2004-06-10 16:58 ` Thomas Breitner 2004-06-10 9:08 ` Bruno Ducrot 1 sibling, 1 reply; 6+ messages in thread From: Dominik Brodowski @ 2004-06-10 8:13 UTC (permalink / raw) To: Thomas Breitner; +Cc: cpufreq On Wed, Jun 09, 2004 at 11:26:47PM +0200, Thomas Breitner wrote: > 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... > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: little system-hang when switching frequencies 2004-06-10 8:13 ` Dominik Brodowski @ 2004-06-10 16:58 ` Thomas Breitner 0 siblings, 0 replies; 6+ messages in thread From: Thomas Breitner @ 2004-06-10 16:58 UTC (permalink / raw) To: linux; +Cc: cpufreq Am Do, den 10.06.2004 schrieb Dominik Brodowski um 10:13: > On Wed, Jun 09, 2004 at 11:26:47PM +0200, Thomas Breitner wrote: > > 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... > > > 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 > 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 > Cpufreq@www.linux.org.uk > http://www.linux.org.uk/mailman/listinfo/cpufreq -- ______________________________________ thomas breitner www.tombreit.de | mail@tombreit.de ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: little system-hang when switching frequencies 2004-06-09 21:26 ` Thomas Breitner 2004-06-10 8:13 ` Dominik Brodowski @ 2004-06-10 9:08 ` Bruno Ducrot 1 sibling, 0 replies; 6+ messages in thread From: Bruno Ducrot @ 2004-06-10 9:08 UTC (permalink / raw) To: Thomas Breitner; +Cc: cpufreq On Wed, Jun 09, 2004 at 11:26:47PM +0200, Thomas Breitner wrote: > Am Mi, den 09.06.2004 schrieb Dominik Brodowski um 17:59: > > On Tue, Jun 08, 2004 at 08:00:41PM +0200, Thomas Breitner wrote: ... > 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... 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. ... > 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. > 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, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-06-10 16:58 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-06-08 18:00 little system-hang when switching frequencies Thomas Breitner 2004-06-09 15:59 ` Dominik Brodowski 2004-06-09 21:26 ` Thomas Breitner 2004-06-10 8:13 ` Dominik Brodowski 2004-06-10 16:58 ` Thomas Breitner 2004-06-10 9:08 ` Bruno Ducrot
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.