From: Justin Piszcz <jpiszcz@lucidpixels.com>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
john stultz <johnstul@us.ibm.com>,
lkml <linux-kernel@vger.kernel.org>,
Arjan van de Ven <arjan@infradead.org>
Subject: RE: 2.6.31.4: WARNING: at arch/x86/kernel/hpet.c:390 hpet_next_event+0x70/0x80() [occurs when ACPI_PROCESSOR=y]
Date: Thu, 12 Nov 2009 19:20:39 -0500 (EST) [thread overview]
Message-ID: <alpine.DEB.2.00.0911121916590.31209@p34.internal.lan> (raw)
In-Reply-To: <7E82351C108FA840AB1866AC776AEC467647ABBD@orsmsx505.amr.corp.intel.com>
On Thu, 12 Nov 2009, Pallipadi, Venkatesh wrote:
>
>> On Fri, 13 Nov 2009, Thomas Gleixner wrote:
>>
>>> On Thu, 12 Nov 2009, john stultz wrote:
>>>
>>>> Forgot to CC lkml, re-adding.
>>>
>>> Added more CCs
>>>
>>>> On Thu, 2009-11-12 at 18:25 -0500, Justin Piszcz wrote:
>>>>> On Thu, 12 Nov 2009, john stultz wrote:
>>>>>> On Thu, Nov 12, 2009 at 8:33 AM, Justin Piszcz
>> <jpiszcz@lucidpixels.com> wrote:
>>>>>>> On Thu, 12 Nov 2009, Justin Piszcz wrote:
>>>>>>>> On Wed, 11 Nov 2009, Justin Piszcz wrote:
>>>>>>>> Again, the problem:
>>>>>>>> [ 3.318770] cpuidle: using governor ladder
>>>>>>>> [ 3.321556] ------------[ cut here ]------------
>>>>>>>> [ 3.321560] WARNING: at arch/x86/kernel/hpet.c:390
>>>>>>>> hpet_next_event+0x70/0x80()
>>>>>>>> [ 3.321561] Hardware name:
>>>>>>>> [ 3.321562] Modules linked in:
>>>>>>>> [ 3.321564] Pid: 0, comm: swapper Not tainted 2.6.31.5 #17
>>>>>>>> [ 3.321565] Call Trace:
>>>>>>>> [ 3.321567] [<ffffffff81042f00>] ? hpet_next_event+0x70/0x80
>>>>>>>> [ 3.321568] [<ffffffff81042f00>] ? hpet_next_event+0x70/0x80
>>>>>>>> [ 3.321571] [<ffffffff81056724>] ?
>> warn_slowpath_common+0x74/0xd0
>>>>>>>> [ 3.321573] [<ffffffff81042f00>] ? hpet_next_event+0x70/0x80
>>>>>>>> [ 3.321576] [<ffffffff81077696>] ?
>> tick_dev_program_event+0x36/0xb0
>>>>>>>> [ 3.321578] [<ffffffff81077079>] ?
>>>>>>>> tick_broadcast_oneshot_control+0x119/0x120
>>>>>>>> [ 3.321579] [<ffffffff8107683d>] ? tick_notify+0x22d/0x420
>>>>>>>> [ 3.321581] [<ffffffff8106fe37>] ?
>> notifier_call_chain+0x37/0x70
>>>>>>>> [ 3.321583] [<ffffffff8107612b>] ?
>> clockevents_notify+0x2b/0x90
>>>>>>>> [ 3.321586] [<ffffffff81244848>] ?
>> acpi_idle_enter_bm+0x15f/0x2d3
>>>>>>>> [ 3.321587] [<ffffffff812446de>] ?
>> acpi_idle_enter_c1+0xf1/0xfc
>>>>>>>> [ 3.321590] [<ffffffff812e6d7a>] ?
>> cpuidle_idle_call+0xba/0x120
>>>>>>>> [ 3.321593] [<ffffffff8102b832>] ? cpu_idle+0x62/0xc0
>>>>>>>> [ 3.321596] ---[ end trace cac202f11005305c ]---
>>>>>>>> [ 3.553852] cpuidle: using governor menu
>>>>>>>
>>>> Huh. That's sort of crazy. It almost seems as though you
>> have two offset
>>>> HPET timers at one timer location that are switching back and forth.
>>>> Looks like either very busted hardware, or something new the kernel
>>>> doesn't expect.
>>>>
>>>>> When I do not load processor.ko though, the error does not occur?
>
> Yes. Yes. This is a hardware errata. I have a patch to workaround this and
> waiting on the errata description to get published..
When will the patch be publicly available?
>
> processor.ko part may be a red-herring as we do not use hpet when deep
> C-states are not enabled and hence we won't go through this code path.
Can you clarify something in relation to C-states? Without processor.ko
(along with ACPI_CPUFREQ etc) loaded, turbo boost will not be enabled,
correct (the CPU will not be able to change stages)?
Processor.ko loaded (even w/ the bug) = bzip2 of 2.6.31.tar = 40 seconds.
Processor.ko not loaded = bzip2 of 2.6.31.tar = 50 seconds.
Thanks.
>
> Thanks,
> Venki
>
next prev parent reply other threads:[~2009-11-13 0:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-08 14:35 2.6.31.4: WARNING: at arch/x86/kernel/hpet.c:390 hpet_next_event+0x70/0x80() Justin Piszcz
2009-11-11 19:50 ` Dave Jones
2009-11-11 21:32 ` 2.6.31.4: WARNING: at arch/x86/kernel/hpet.c:390 hpet_next_event+0x70/0x80() [occurs when ACPI_PROCESSOR=y] Justin Piszcz
2009-11-12 16:26 ` Justin Piszcz
2009-11-12 16:33 ` Justin Piszcz
2009-11-12 23:39 ` Justin Piszcz
[not found] ` <1f1b08da0911121513l32d47b4x8b9722ad3440ceb6@mail.gmail.com>
[not found] ` <alpine.DEB.2.00.0911121824290.2852@p34.internal.lan>
2009-11-12 23:40 ` john stultz
2009-11-12 23:45 ` Justin Piszcz
2009-11-12 23:49 ` john stultz
2009-11-12 23:53 ` Justin Piszcz
2009-11-12 23:53 ` Thomas Gleixner
2009-11-12 23:56 ` Justin Piszcz
2009-11-13 0:18 ` Pallipadi, Venkatesh
2009-11-13 0:20 ` Justin Piszcz [this message]
2009-11-13 0:30 ` Pallipadi, Venkatesh
2009-11-13 9:38 ` Thomas Gleixner
2009-11-13 18:32 ` Pallipadi, Venkatesh
2009-11-13 18:43 ` Justin Piszcz
2009-11-14 1:12 ` Pallipadi, Venkatesh
2009-11-14 8:48 ` Justin Piszcz
2009-11-17 11:45 ` Justin Piszcz
2009-11-17 21:37 ` Pallipadi, Venkatesh
2009-11-17 22:53 ` Justin Piszcz
2009-11-19 22:08 ` Pallipadi, Venkatesh
2009-11-19 23:12 ` Justin Piszcz
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=alpine.DEB.2.00.0911121916590.31209@p34.internal.lan \
--to=jpiszcz@lucidpixels.com \
--cc=arjan@infradead.org \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®