Re: CPU off-on-off: lost CPU management?
Hi! This issue is solved with 2.6.22-rc for me. The second core is up with the same speed as core 1 (Bogomips are the same, too). - Stefan Prechtel 2007/6/6, Peter Oruba <[EMAIL PROTECTED]>: I'm sorry, I am not able to reproduce this issue (using 2.6.21.3). Everything works fine on my Turion laptop. It looks like there is also CPU hotplug involved in that issue, since brining cpu1 back on doesn't update siblings and cpu_cores in /proc/cpuinfo as well. Can you specify more details about the system you are using? Have you tried enabling CONFIG_CPU_FREQ_DEBUG and booting with "cpufreq.debug=7"? Peter Oruba - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CPU off-on-off: lost CPU management?
Hi! This issue is solved with 2.6.22-rc for me. The second core is up with the same speed as core 1 (Bogomips are the same, too). - Stefan Prechtel 2007/6/6, Peter Oruba [EMAIL PROTECTED]: I'm sorry, I am not able to reproduce this issue (using 2.6.21.3). Everything works fine on my Turion laptop. It looks like there is also CPU hotplug involved in that issue, since brining cpu1 back on doesn't update siblings and cpu_cores in /proc/cpuinfo as well. Can you specify more details about the system you are using? Have you tried enabling CONFIG_CPU_FREQ_DEBUG and booting with cpufreq.debug=7? Peter Oruba - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CPU off-on-off: lost CPU management?
Hello, I have the same "problems" with CPU-Hotplug. Whenever I turn off the second core and turn it back on, /proc/cpuinfo shows that the second core is on, but at a different speed. # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 72 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60 stepping: 2 cpu MHz : 800.000 cache size : 512 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8legacy ts fid vid ttp tm stc bogomips: 1596.96 clflush size: 64 processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 72 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60 stepping: 2 cpu MHz : 1995.071 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8legacy ts fid vid ttp tm stc bogomips: 3990.71 clflush size: 64 dmesg shows the following after resume from s2disk (only the first time, then "CPU: Vendor unknown../Your system my be unstable" doesn't appear): Disabling non-boot CPUs ... Cannot set affinity for irq 0 CPU 1 is now offline SMP alternatives: switching to UP code CPU1 is down Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Enabling non-boot CPUs ... SMP alternatives: switching to SMP code Booting processor 1/1 eip 3000 Initializing CPU#1 Calibrating delay using timer specific routine.. 3990.61 BogoMIPS (lpj=1995306) CPU: Vendor unknown, using generic init. CPU: Your system may be unstable. CPU: After generic identify, caps: 178bfbff ebd3fbff 2001 001f CPU: After all inits, caps: 178bfbff ebd3fbff 2001 001f CPU1: AuthenticAMD AMD Turion(tm) 64 X2 Mobile Technology TL-60 stepping 02 CPU1 is up Switched to high resolution mode on CPU 1 But I don't noticed a shorter batterylife or more cpu hotness, so I think the second core is running at the same speed as CPU0 and /proc/cpuinfo (and possibly other files) doesn't update correctly. Regards, Stefan 2007/4/8, Mircea Bardac <[EMAIL PROTECTED]>: Hi everyone, After reading "CPU offline but power consumption increased?" lkml thread I wanted to test CPU on-off on my Turion 64 X2. I found out something strange, related to the way CPU is turned off and back on. I don't know if this is a kernel bug, but looks pretty suspicious. The initial situation, both cores running at 1.6 GHz, full info displayed /proc/cpuinfo # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 72 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-52 stepping: 2 cpu MHz : 1600.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc bogomips: 3195.47 clflush size: 64 processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 72 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-52 stepping: 2 cpu MHz : 1600.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc bogomips: 3195.47 clflush size: 64 The initial situation, both cores running at 1.6 GHz, full info displayed cpufreq-info # cpufreq-info cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006 Report errors and bugs to [EMAIL
Re: CPU off-on-off: lost CPU management?
Hello, I have the same problems with CPU-Hotplug. Whenever I turn off the second core and turn it back on, /proc/cpuinfo shows that the second core is on, but at a different speed. # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 72 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60 stepping: 2 cpu MHz : 800.000 cache size : 512 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8legacy ts fid vid ttp tm stc bogomips: 1596.96 clflush size: 64 processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 72 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60 stepping: 2 cpu MHz : 1995.071 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8legacy ts fid vid ttp tm stc bogomips: 3990.71 clflush size: 64 dmesg shows the following after resume from s2disk (only the first time, then CPU: Vendor unknown../Your system my be unstable doesn't appear): Disabling non-boot CPUs ... Cannot set affinity for irq 0 CPU 1 is now offline SMP alternatives: switching to UP code CPU1 is down Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Enabling non-boot CPUs ... SMP alternatives: switching to SMP code Booting processor 1/1 eip 3000 Initializing CPU#1 Calibrating delay using timer specific routine.. 3990.61 BogoMIPS (lpj=1995306) CPU: Vendor unknown, using generic init. CPU: Your system may be unstable. CPU: After generic identify, caps: 178bfbff ebd3fbff 2001 001f CPU: After all inits, caps: 178bfbff ebd3fbff 2001 001f CPU1: AuthenticAMD AMD Turion(tm) 64 X2 Mobile Technology TL-60 stepping 02 CPU1 is up Switched to high resolution mode on CPU 1 But I don't noticed a shorter batterylife or more cpu hotness, so I think the second core is running at the same speed as CPU0 and /proc/cpuinfo (and possibly other files) doesn't update correctly. Regards, Stefan 2007/4/8, Mircea Bardac [EMAIL PROTECTED]: Hi everyone, After reading CPU offline but power consumption increased? lkml thread I wanted to test CPU on-off on my Turion 64 X2. I found out something strange, related to the way CPU is turned off and back on. I don't know if this is a kernel bug, but looks pretty suspicious. The initial situation, both cores running at 1.6 GHz, full info displayed /proc/cpuinfo # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 72 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-52 stepping: 2 cpu MHz : 1600.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc bogomips: 3195.47 clflush size: 64 processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 72 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-52 stepping: 2 cpu MHz : 1600.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc bogomips: 3195.47 clflush size: 64 The initial situation, both cores running at 1.6 GHz, full info displayed cpufreq-info # cpufreq-info cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006 Report errors and bugs to [EMAIL PROTECTED],
Re: [PATCH] i386: disable local apic timer via command line or dmi quirk
2007/3/21, Grzegorz Chwesewicz <[EMAIL PROTECTED]>: On Wed, 21 Mar 2007 15:09:30 +0100, Ingo Molnar wrote > * Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > > The local APIC timer stops to work in deeper C-States. This is handled > > by the ACPI code and a broadcast mechanism in the clockevents / tick > > managment code. > > > > Some systems do not expose the deeper C-States to the kernel, but > > switch into deeper C-States behind the kernels back. This delays the > > local apic timer interrupts for ever and makes the systems unusable. > > > > Add a command line option to disable the local apic timer and a dmi > > quirk for known broken systems. Confirming that my machine on 2.6-git with this patch works just like on 2.6.20. Great work. -- Greetings - Grzegorz Chwesewicz Works here too, thx ;) Kind regards, Stefan Prechtel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: disable local apic timer via command line or dmi quirk
2007/3/21, Grzegorz Chwesewicz [EMAIL PROTECTED]: On Wed, 21 Mar 2007 15:09:30 +0100, Ingo Molnar wrote * Thomas Gleixner [EMAIL PROTECTED] wrote: The local APIC timer stops to work in deeper C-States. This is handled by the ACPI code and a broadcast mechanism in the clockevents / tick managment code. Some systems do not expose the deeper C-States to the kernel, but switch into deeper C-States behind the kernels back. This delays the local apic timer interrupts for ever and makes the systems unusable. Add a command line option to disable the local apic timer and a dmi quirk for known broken systems. Confirming that my machine on 2.6-git with this patch works just like on 2.6.20. Great work. -- Greetings - Grzegorz Chwesewicz Works here too, thx ;) Kind regards, Stefan Prechtel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
2007/3/21, Andi Kleen <[EMAIL PROTECTED]>: On Wednesday 21 March 2007 12:14, Thomas Gleixner wrote: > On Wed, 2007-03-21 at 11:37 +0100, Andi Kleen wrote: > > > The BIOS/ACPI is broken and does only expose C1, which should not > > > switch off LAPIC. The BIOS is switching into deeper C-States behind the > > > kernels back somehow. > > > > Hmm, perhaps we can check AMD && (cstate >= 2 || has a battery) ? > > Should be doable by looking up the battery object in ACPI > > Which makes us rely on another ACPI feature. What guarantees that the > ACPI tables are correct for this one ? Nothing, but wrong C2 and wrong battery state together seems unlikely. -Andi Hello I uploaded the output of dmesg (kernel 2.6.21-rc4-git5) (battery / ac) and dmidecode I can boot on battery with nolapic_timer and the second core is online, too. /proc/acpi/processor/C000/ shows the same as before but /proc/interrupts has changed: (battery) CPU0 CPU1 0: 47131 0 local-APIC-edge-fasteoi timer LOC: 0 46978 (ac) CPU0 CPU1 0: 59137 0 local-APIC-edge-fasteoi timer LOC: 0 58984 - Stefan Prechtel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
2007/3/21, Andi Kleen [EMAIL PROTECTED]: On Wednesday 21 March 2007 12:14, Thomas Gleixner wrote: On Wed, 2007-03-21 at 11:37 +0100, Andi Kleen wrote: The BIOS/ACPI is broken and does only expose C1, which should not switch off LAPIC. The BIOS is switching into deeper C-States behind the kernels back somehow. Hmm, perhaps we can check AMD (cstate = 2 || has a battery) ? Should be doable by looking up the battery object in ACPI Which makes us rely on another ACPI feature. What guarantees that the ACPI tables are correct for this one ? Nothing, but wrong C2 and wrong battery state together seems unlikely. -Andi Hello I uploaded the output of dmesg (kernel 2.6.21-rc4-git5) (battery / ac) and dmidecode I can boot on battery with nolapic_timer and the second core is online, too. /proc/acpi/processor/C000/ shows the same as before but /proc/interrupts has changed: (battery) CPU0 CPU1 0: 47131 0 local-APIC-edge-fasteoi timer LOC: 0 46978 (ac) CPU0 CPU1 0: 59137 0 local-APIC-edge-fasteoi timer LOC: 0 58984 - Stefan Prechtel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
2007/3/20, Thomas Gleixner <[EMAIL PROTECTED]>: On Mon, 2007-03-19 at 22:51 +0100, Stefan Prechtel wrote: > 2007/3/19, Thomas Gleixner <[EMAIL PROTECTED]>: > > On Mon, 2007-03-19 at 21:35 +0100, Stefan Prechtel wrote: > > >CPU0 CPU1 > > > 0: 28289 0 local-APIC-edge-fasteio timer > > > ... > > > LOC: 28237 28236 > > > > > > after a read: (I hope that is this what you want :-) > > >CPU0 CPU1 > > > 0: 30344 0 local-APIC-edge-fasteio timer > > > ... > > > LOC: 30292 30291 > > > > Is this with AC plugged in ? If yes, please provide the same numbers for > > battery mode. > > Yes. And here is the output for battery mode (2.6.20): >CPU0 CPU1 > 0: 292153 0 local-APIC-edge-fasteio timer > LOC: 292114 292113 > >CPU0 CPU1 > 0: 293263 0 local-APIC-edge-fasteio timer > LOC: 293224 293223 Hmm. Can you please apply the following patch on top of 2.6.20 and check, if the WARN_ON_ONCE triggers when you boot w/o AC plugged ? Thanks, tglx Good morning! The WARN_ON / WARN_ON_ONCE didn't trigger on boot. - Stefan Prechtel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
2007/3/20, Thomas Gleixner [EMAIL PROTECTED]: On Mon, 2007-03-19 at 22:51 +0100, Stefan Prechtel wrote: 2007/3/19, Thomas Gleixner [EMAIL PROTECTED]: On Mon, 2007-03-19 at 21:35 +0100, Stefan Prechtel wrote: CPU0 CPU1 0: 28289 0 local-APIC-edge-fasteio timer ... LOC: 28237 28236 after a read: (I hope that is this what you want :-) CPU0 CPU1 0: 30344 0 local-APIC-edge-fasteio timer ... LOC: 30292 30291 Is this with AC plugged in ? If yes, please provide the same numbers for battery mode. Yes. And here is the output for battery mode (2.6.20): CPU0 CPU1 0: 292153 0 local-APIC-edge-fasteio timer LOC: 292114 292113 CPU0 CPU1 0: 293263 0 local-APIC-edge-fasteio timer LOC: 293224 293223 Hmm. Can you please apply the following patch on top of 2.6.20 and check, if the WARN_ON_ONCE triggers when you boot w/o AC plugged ? Thanks, tglx Good morning! The WARN_ON / WARN_ON_ONCE didn't trigger on boot. - Stefan Prechtel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
2007/3/19, Thomas Gleixner <[EMAIL PROTECTED]>:
On Mon, 2007-03-19 at 21:35 +0100, Stefan Prechtel wrote:
>CPU0 CPU1
> 0: 28289 0 local-APIC-edge-fasteio timer
> ...
> LOC: 28237 28236
>
> after a read: (I hope that is this what you want :-)
>CPU0 CPU1
> 0: 30344 0 local-APIC-edge-fasteio timer
> ...
> LOC: 30292 30291
Is this with AC plugged in ? If yes, please provide the same numbers for
battery mode.
Yes. And here is the output for battery mode (2.6.20):
CPU0 CPU1
0: 292153 0 local-APIC-edge-fasteio timer
LOC: 292114 292113
CPU0 CPU1
0: 293263 0 local-APIC-edge-fasteio timer
LOC: 293224 293223
What's the output of
cat /proc/acpi/processor/C000/power
for 2.6.20 and 2.6.21-rc4-latest-git with and w/o AC ?
2.6.20 / 2.6.21: (both the same)
battery / ac (both the same)
# cat /proc/acpi/processor/C000/power
active state:C1
max_cstate: C8
bus master activity:
maximum allowed latency: 2000 usec
states:
*C1: type[C1] promotion[--] demotion[--] latency[000] usage[
] duration[]
# cat /proc/acpi/processor/C001/power
active state:C1
max_cstate: C8
bus master activity:
maximum allowed latency: 2000 usec
states:
*C1: type[C1] promotion[--] demotion[--] latency[000] usage[
] duration[]
Can you also please upload a bootlog with and without AC of 2.6.20 to
bugzilla ?
Yes, one moment please. I will upload files..
Thanks,
tglx
Thanks too ;)
- Stefan Prechtel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
2007/3/19, Thomas Gleixner <[EMAIL PROTECTED]>: > Here is the output of /proc/interrupts on 2.6.20: >CPU0 CPU1 > 0: 7089 0 local-APIC-edge-fasteio timer > Can you provide the numbers for LOC too ? 0: 29801420 29793520IO-APIC-edge timer ... LOC: 119180305 119180039 And please do a sleep 10; between two reads, so I can see the deltas. Ah sorry. I forgot it.. CPU0 CPU1 0: 28289 0 local-APIC-edge-fasteio timer ... LOC: 28237 28236 after a read: (I hope that is this what you want :-) CPU0 CPU1 0: 30344 0 local-APIC-edge-fasteio timer ... LOC: 30292 30291 - Stefan Prechtel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
2007/3/19, Thomas Gleixner <[EMAIL PROTECTED]>: We have a broadcast mechanism for this, which gets activated from ACPI, but the broadcast mechanism is not activated: [3.798000] Clock Event Device: pit [3.798000] tick_broadcast_mask: Can you please boot with 2.6.20 or earlier and check the output of /proc/interrupts ? IRQ#0 and the LOC (local APIC timer) Interrupts should increment in the same frequency. tglx Here is the output of /proc/interrupts on 2.6.20: CPU0 CPU1 0: 7089 0 local-APIC-edge-fasteio timer and this on 2.6.21-rc*: CPU0 CPU1 0:255 0 local-APIC-edge-fasteoi timer on 2.6.21-rc* the number "255" doesn't change. But if it is ACPI relevant, shouldn't it boot with acpi=off? I've tried with acpi=off and noapic but only with nolapic it started. And the content of /proc/acpi/processor/C000/power shows only one c-state; shouldn't it show more C-states? (please correct me if I'm wrong) # cat /proc/acpi/processor/C000/power active state:C1 max_cstate: C8 bus master activity: maximum allowed latency: 2000 usec states: *C1: type[C1] promotion[--] demotion[--] latency[000] usage[] duration[0000] Regards, Stefan Prechtel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
(Bugzilla) Does booting w/ clocksource=acpi_pm avoid the problem? No, it doesn't. I hope it's ok that I added your email to CC. 2007/3/19, Stefan Prechtel <[EMAIL PROTECTED]>: Hi! If the ac-cable is plugged in, I can start my Notebook (HP nx6325) without any problems. On battery the kernel hanging around and it takes "hours" to boot the kernel and the system is *very* slow. For example an init-skript takes very long until it's started. I did a git-bisect and found out that this is the first bad commit: commit e9e2cdb412412326c4827fc78ba27f410d837e6e Author: Thomas Gleixner <[EMAIL PROTECTED]> Date: Fri Feb 16 01:28:04 2007 -0800 [PATCH] clockevents: i386 drivers Add clockevent drivers for i386: lapic (local) and PIT/HPET (global). Update the timer IRQ to call into the PIT/HPET driver's event handler and the lapic-timer IRQ to call into the lapic clockevent driver. The assignement of timer functionality is delegated to the core framework code and replaces the compile and runtime evalution in do_timer_interrupt_hook() Use the clockevents broadcast support and implement the lapic_broadcast function for ACPI. No changes to existing functionality. So I tried to boot with nolapic on battery and with this option the kernel (and system) starts as it should. If you need more information, I will send it to you. Regards, Stefan Prechtel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
You can find the files here: http://bugzilla.kernel.org/show_bug.cgi?id=8235 Regards, Stefan Prechtel 2007/3/19, Thomas Gleixner <[EMAIL PROTECTED]>: On Mon, 2007-03-19 at 18:36 +0100, Thomas Gleixner wrote: Oh, a bootlog with ac plugged in would be great too. Also can you please enable CONFIG_SYSRQ and hit SysRq-Q once, when the slowness kicks in. Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
Hi! If the ac-cable is plugged in, I can start my Notebook (HP nx6325) without any problems. On battery the kernel hanging around and it takes "hours" to boot the kernel and the system is *very* slow. For example an init-skript takes very long until it's started. I did a git-bisect and found out that this is the first bad commit: commit e9e2cdb412412326c4827fc78ba27f410d837e6e Author: Thomas Gleixner <[EMAIL PROTECTED]> Date: Fri Feb 16 01:28:04 2007 -0800 [PATCH] clockevents: i386 drivers Add clockevent drivers for i386: lapic (local) and PIT/HPET (global). Update the timer IRQ to call into the PIT/HPET driver's event handler and the lapic-timer IRQ to call into the lapic clockevent driver. The assignement of timer functionality is delegated to the core framework code and replaces the compile and runtime evalution in do_timer_interrupt_hook() Use the clockevents broadcast support and implement the lapic_broadcast function for ACPI. No changes to existing functionality. So I tried to boot with nolapic on battery and with this option the kernel (and system) starts as it should. If you need more information, I will send it to you. Regards, Stefan Prechtel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
Hi! If the ac-cable is plugged in, I can start my Notebook (HP nx6325) without any problems. On battery the kernel hanging around and it takes hours to boot the kernel and the system is *very* slow. For example an init-skript takes very long until it's started. I did a git-bisect and found out that this is the first bad commit: commit e9e2cdb412412326c4827fc78ba27f410d837e6e Author: Thomas Gleixner [EMAIL PROTECTED] Date: Fri Feb 16 01:28:04 2007 -0800 [PATCH] clockevents: i386 drivers Add clockevent drivers for i386: lapic (local) and PIT/HPET (global). Update the timer IRQ to call into the PIT/HPET driver's event handler and the lapic-timer IRQ to call into the lapic clockevent driver. The assignement of timer functionality is delegated to the core framework code and replaces the compile and runtime evalution in do_timer_interrupt_hook() Use the clockevents broadcast support and implement the lapic_broadcast function for ACPI. No changes to existing functionality. So I tried to boot with nolapic on battery and with this option the kernel (and system) starts as it should. If you need more information, I will send it to you. Regards, Stefan Prechtel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
You can find the files here: http://bugzilla.kernel.org/show_bug.cgi?id=8235 Regards, Stefan Prechtel 2007/3/19, Thomas Gleixner [EMAIL PROTECTED]: On Mon, 2007-03-19 at 18:36 +0100, Thomas Gleixner wrote: Oh, a bootlog with ac plugged in would be great too. Also can you please enable CONFIG_SYSRQ and hit SysRq-Q once, when the slowness kicks in. Thanks, tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
(Bugzilla) Does booting w/ clocksource=acpi_pm avoid the problem? No, it doesn't. I hope it's ok that I added your email to CC. 2007/3/19, Stefan Prechtel [EMAIL PROTECTED]: Hi! If the ac-cable is plugged in, I can start my Notebook (HP nx6325) without any problems. On battery the kernel hanging around and it takes hours to boot the kernel and the system is *very* slow. For example an init-skript takes very long until it's started. I did a git-bisect and found out that this is the first bad commit: commit e9e2cdb412412326c4827fc78ba27f410d837e6e Author: Thomas Gleixner [EMAIL PROTECTED] Date: Fri Feb 16 01:28:04 2007 -0800 [PATCH] clockevents: i386 drivers Add clockevent drivers for i386: lapic (local) and PIT/HPET (global). Update the timer IRQ to call into the PIT/HPET driver's event handler and the lapic-timer IRQ to call into the lapic clockevent driver. The assignement of timer functionality is delegated to the core framework code and replaces the compile and runtime evalution in do_timer_interrupt_hook() Use the clockevents broadcast support and implement the lapic_broadcast function for ACPI. No changes to existing functionality. So I tried to boot with nolapic on battery and with this option the kernel (and system) starts as it should. If you need more information, I will send it to you. Regards, Stefan Prechtel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
2007/3/19, Thomas Gleixner [EMAIL PROTECTED]: We have a broadcast mechanism for this, which gets activated from ACPI, but the broadcast mechanism is not activated: [3.798000] Clock Event Device: pit [3.798000] tick_broadcast_mask: Can you please boot with 2.6.20 or earlier and check the output of /proc/interrupts ? IRQ#0 and the LOC (local APIC timer) Interrupts should increment in the same frequency. tglx Here is the output of /proc/interrupts on 2.6.20: CPU0 CPU1 0: 7089 0 local-APIC-edge-fasteio timer and this on 2.6.21-rc*: CPU0 CPU1 0:255 0 local-APIC-edge-fasteoi timer on 2.6.21-rc* the number 255 doesn't change. But if it is ACPI relevant, shouldn't it boot with acpi=off? I've tried with acpi=off and noapic but only with nolapic it started. And the content of /proc/acpi/processor/C000/power shows only one c-state; shouldn't it show more C-states? (please correct me if I'm wrong) # cat /proc/acpi/processor/C000/power active state:C1 max_cstate: C8 bus master activity: maximum allowed latency: 2000 usec states: *C1: type[C1] promotion[--] demotion[--] latency[000] usage[] duration[] Regards, Stefan Prechtel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
2007/3/19, Thomas Gleixner [EMAIL PROTECTED]: Here is the output of /proc/interrupts on 2.6.20: CPU0 CPU1 0: 7089 0 local-APIC-edge-fasteio timer Can you provide the numbers for LOC too ? 0: 29801420 29793520IO-APIC-edge timer ... LOC: 119180305 119180039 And please do a sleep 10; between two reads, so I can see the deltas. Ah sorry. I forgot it.. CPU0 CPU1 0: 28289 0 local-APIC-edge-fasteio timer ... LOC: 28237 28236 after a read: (I hope that is this what you want :-) CPU0 CPU1 0: 30344 0 local-APIC-edge-fasteio timer ... LOC: 30292 30291 - Stefan Prechtel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG lapic: Can't boot on battery (2.6.21-rc{1,2,3,4})
2007/3/19, Thomas Gleixner [EMAIL PROTECTED]: On Mon, 2007-03-19 at 21:35 +0100, Stefan Prechtel wrote: CPU0 CPU1 0: 28289 0 local-APIC-edge-fasteio timer ... LOC: 28237 28236 after a read: (I hope that is this what you want :-) CPU0 CPU1 0: 30344 0 local-APIC-edge-fasteio timer ... LOC: 30292 30291 Is this with AC plugged in ? If yes, please provide the same numbers for battery mode. Yes. And here is the output for battery mode (2.6.20): CPU0 CPU1 0: 292153 0 local-APIC-edge-fasteio timer LOC: 292114 292113 CPU0 CPU1 0: 293263 0 local-APIC-edge-fasteio timer LOC: 293224 293223 What's the output of cat /proc/acpi/processor/C000/power for 2.6.20 and 2.6.21-rc4-latest-git with and w/o AC ? 2.6.20 / 2.6.21: (both the same) battery / ac (both the same) # cat /proc/acpi/processor/C000/power active state:C1 max_cstate: C8 bus master activity: maximum allowed latency: 2000 usec states: *C1: type[C1] promotion[--] demotion[--] latency[000] usage[ ] duration[] # cat /proc/acpi/processor/C001/power active state:C1 max_cstate: C8 bus master activity: maximum allowed latency: 2000 usec states: *C1: type[C1] promotion[--] demotion[--] latency[000] usage[ ] duration[] Can you also please upload a bootlog with and without AC of 2.6.20 to bugzilla ? Yes, one moment please. I will upload files.. Thanks, tglx Thanks too ;) - Stefan Prechtel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
