Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-31 Thread Grzegorz Chwesewicz
On Fri, 30 Mar 2007 00:05:39 +0200, Andi Kleen wrote On Thursday 29 March 2007 23:16, Linus Torvalds wrote: On Thu, 29 Mar 2007, Andi Kleen wrote: Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. I think this

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-30 Thread Grzegorz Chwesewicz
On Fri, 30 Mar 2007 00:05:39 +0200, Andi Kleen wrote On Thursday 29 March 2007 23:16, Linus Torvalds wrote: On Thu, 29 Mar 2007, Andi Kleen wrote: Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. I think this

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-29 Thread Andi Kleen
Len Brown [EMAIL PROTECTED] writes: On an Intel processor, it seems that the safe and simple route is if the system exports C2 or deeper, don't use the LAPIC timer. (which is what 2.6.21-rc5 is doing as of this moment) We may be able to white-list some systems over time. On AMD it is the

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-29 Thread Andi Kleen
Linus Torvalds [EMAIL PROTECTED] writes: On Tue, 27 Mar 2007, Len Brown wrote: I think the only fool-proof way to do this automatically is to Why not just take the known-good CPUID signature? I didn't think we could reliably distingush mobile cpus with C2+ versus desktop CPUs without

RE: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-29 Thread Langsdorf, Mark
If we really care about using the LAPIC timer on systems with deeper than C1 support, the only alternative seems to be to test if it actually works or not at boot and run-time. Otherwise, we wait for future hardware with guaranteed not to break under any (BIOS) conditions ships, and

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-29 Thread Andi Kleen
Langsdorf, Mark [EMAIL PROTECTED] writes: If we really care about using the LAPIC timer on systems with deeper than C1 support, the only alternative seems to be to test if it actually works or not at boot and run-time. Otherwise, we wait for future hardware with guaranteed not to

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-29 Thread Mark Langsdorf
Andi Kleen wrote: Langsdorf, Mark [EMAIL PROTECTED] writes: If we really care about using the LAPIC timer on systems with deeper than C1 support, the only alternative seems to be to test if it actually works or not at boot and run-time. Otherwise, we wait for future hardware with guaranteed

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-29 Thread Andi Kleen
Reviewed but not tested. Needs to be wrapped in an AMD specific call. Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. Would be good if someone with a Turion laptop, especially the HP nx6325 could test it with CONFIG_NO_HZ

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-29 Thread Linus Torvalds
On Thu, 29 Mar 2007, Andi Kleen wrote: Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. I think this looks better than what we have now, but it would look even better if the core CPUID stuff was in

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-29 Thread Grzegorz Chwesewicz
On Thu, 29 Mar 2007 22:49:37 +0200, Andi Kleen wrote Reviewed but not tested. Needs to be wrapped in an AMD specific call. Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. Would be good if someone with a Turion laptop,

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-29 Thread Andreas Mohr
Hi, On Thu, Mar 29, 2007 at 02:16:54PM -0700, Linus Torvalds wrote: On Thu, 29 Mar 2007, Andi Kleen wrote: Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. I think this looks better than what we have now, but it

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-29 Thread Grzegorz Chwesewicz
On Thu, 29 Mar 2007 23:43:28 +0200, Grzegorz Chwesewicz wrote On Thu, 29 Mar 2007 22:49:37 +0200, Andi Kleen wrote Reviewed but not tested. Needs to be wrapped in an AMD specific call. Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-29 Thread Linus Torvalds
On Thu, 29 Mar 2007, Andreas Mohr wrote: Please don't, this would break the interface logically. X86_FEATURE_xxx usually denotes a *feature*, not a feature (Micro$oft speak for bug ;). Sure, we could make it positive instead, and I agree it would make code nicer to read. Thus, how

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-29 Thread Andi Kleen
On Thursday 29 March 2007 23:45, Andreas Mohr wrote: Hi, On Thu, Mar 29, 2007 at 02:16:54PM -0700, Linus Torvalds wrote: On Thu, 29 Mar 2007, Andi Kleen wrote: Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box.

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-29 Thread Andi Kleen
On Thursday 29 March 2007 23:16, Linus Torvalds wrote: On Thu, 29 Mar 2007, Andi Kleen wrote: Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. I think this looks better than what we have now, but it would look even

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-27 Thread Len Brown
On Monday 26 March 2007 09:52, Thomas Gleixner wrote: On Mon, 2007-03-26 at 12:31 +, Pavel Machek wrote: + lapic_timer_c2_ok [IA-32,APIC] trust the local apic timer in + C2 power state. + I still twist my brain how to autodetect that in a safe way, which would

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-27 Thread Linus Torvalds
On Tue, 27 Mar 2007, Len Brown wrote: I think the only fool-proof way to do this automatically is to Why not just take the known-good CPUID signature? Screw firmware or ACPI tables. They're going to be occasionally wrong. If we know that Core 2, version X has a good local APIC timer, we

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-27 Thread Len Brown
On Tuesday 27 March 2007 17:34, Linus Torvalds wrote: On Tue, 27 Mar 2007, Len Brown wrote: I think the only fool-proof way to do this automatically is to Why not just take the known-good CPUID signature? Screw firmware or ACPI tables. They're going to be occasionally wrong. If we

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-27 Thread Len Brown
On Tuesday 27 March 2007 18:16, Len Brown wrote: On Tuesday 27 March 2007 17:34, Linus Torvalds wrote: On Tue, 27 Mar 2007, Len Brown wrote: I think the only fool-proof way to do this automatically is to Why not just take the known-good CPUID signature? Screw firmware or ACPI

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-26 Thread Pavel Machek
Hi! It turned out that it is almost impossible to trust ACPI, BIOS Co. regarding the C states. This was the reason to switch the local apic timer off in C2 state already. OTOH there are sane and well behaving systems, which get punished by that decision. Allow the user to confirm that the

Re: [PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-26 Thread Thomas Gleixner
On Mon, 2007-03-26 at 12:31 +, Pavel Machek wrote: + lapic_timer_c2_ok [IA-32,APIC] trust the local apic timer in + C2 power state. + Could you add comment saying that this is always ok on non-broken systems? That way perhaps it can be added to

[PATCH] i386: add command line option local_apic_timer_c2_ok

2007-03-23 Thread Thomas Gleixner
On Fri, 2007-03-23 at 12:56 +0100, Thomas Gleixner wrote: We should revert that patch and add a trust_lapic_timer_in_c2 commandline option instead. So we are on the safe side. Here is a patch which applies after reverting 25496caec111481161e7f06bbfa12a533c43cc6f It turned out that it is