From: Thomas Gleixner <tglx@linutronix.de>
To: Andrew Morton <akpm@osdl.org>
Cc: Ingo Molnar <mingo@elte.hu>, teunis <teunis@wintersgift.com>,
linux-kernel@vger.kernel.org, Dmitry Torokhov <dtor@mail.ru>,
john stultz <johnstul@us.ibm.com>, Len Brown <lenb@kernel.org>
Subject: Re: various laptop nagles - any suggestions? (note: 2.6.19-rc2-mm1 but applies to multiple kernels)
Date: Sun, 22 Oct 2006 23:22:39 +0200 [thread overview]
Message-ID: <1161552160.22373.17.camel@localhost.localdomain> (raw)
In-Reply-To: <1161424147.5274.400.camel@localhost.localdomain>
On Sat, 2006-10-21 at 11:49 +0200, Thomas Gleixner wrote:
> [ 11.515305] calibrating APIC timer ...
> [ 11.618612] ..... tt1-tt2 831283
> [ 11.618614] ..... mult: 35701101
> [ 11.618616] ..... calibration result: 532021
> [ 11.618619] ..... CPU clock speed is 1995.0325 MHz.
> [ 11.618622] ..... host bus clock speed is 133.0021 MHz.
>
> That looks reasonable. It really boils down to the lapic not working
> when going idle.
This LAPIC business is weird. I found two boxen, where the LAPIC timer
calibration is wrong by factor 1.8 and 2.3 on every third/fifth boot.
Unsurprisingly one is a VAIO with a CoreDuo inside, which claims to have
a 4.6GHz CPU and 390MHz bus speed occasionally. This problem seems to be
independent of the "lapic stops on C2" one.
I have a patch ready, which should detect both problems, but having
acpi_processor as a module is painful, as we might enable the C2 states
way after we decided to use the LAPIC timer and switched over to
highres/dyntick mode. I need to find a way to back out from
highres/dyntick mode gracefully in that case except we can agree to make
the acpi_processor bits built-in only or at least make the Kconfig
tristate depending on experimental. Len ?
tglx
next prev parent reply other threads:[~2006-10-22 21:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-19 16:05 various laptop nagles - any suggestions? (note: 2.6.19-rc2-mm1 but applies to multiple kernels) teunis
2006-10-20 2:41 ` Andrew Morton
2006-10-20 16:30 ` teunis
2006-10-20 18:07 ` Andrew Morton
2006-10-20 18:13 ` Thomas Gleixner
2006-10-20 18:26 ` Andrew Morton
2006-10-20 18:37 ` Thomas Gleixner
2006-10-20 18:46 ` Thomas Gleixner
2006-10-20 19:15 ` Andrew Morton
2006-10-20 20:37 ` Ingo Molnar
2006-10-20 20:54 ` Andrew Morton
2006-10-20 20:56 ` Ingo Molnar
2006-10-21 1:25 ` Andrew Morton
2006-10-21 9:49 ` Thomas Gleixner
2006-10-22 21:22 ` Thomas Gleixner [this message]
2006-11-08 7:19 ` Andrew Morton
2006-11-08 22:28 ` Thomas Gleixner
2006-10-21 14:52 ` Arjan van de Ven
2006-10-20 19:13 ` Dmitry Torokhov
2006-10-20 22:26 ` teunis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1161552160.22373.17.camel@localhost.localdomain \
--to=tglx@linutronix.de \
--cc=akpm@osdl.org \
--cc=dtor@mail.ru \
--cc=johnstul@us.ibm.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=teunis@wintersgift.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.