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.
> >
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.
> >
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 loo
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
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,
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 s
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,
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
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 arch/i386/kernel/cpu/a
> 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
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
"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 guarant
> > 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,
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 w
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 th
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?
> >
> > Scre
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.
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
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, w
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 linux
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 th
21 matches
Mail list logo
