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.
I think this
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.
I think this
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
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 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
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
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
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
> 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
"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
> > 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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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.
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
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?
> >
> >
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,
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,
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
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 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
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
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
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
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
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
42 matches
Mail list logo
