lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 12 Nov 2009 16:30:15 -0800
From:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To:	Justin Piszcz <jpiszcz@...idpixels.com>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	john stultz <johnstul@...ibm.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.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]

>-----Original Message-----
>From: Justin Piszcz [mailto:jpiszcz@...idpixels.com] 
>Sent: Thursday, November 12, 2009 4:21 PM
>To: Pallipadi, Venkatesh
>Cc: Thomas Gleixner; john stultz; lkml; Arjan van de Ven
>Subject: RE: 2.6.31.4: WARNING: at arch/x86/kernel/hpet.c:390 
>hpet_next_event+0x70/0x80() [occurs when ACPI_PROCESSOR=y]
>
>
>
>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@...idpixels.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.
>

Yes. To get the Turbo boost, ACPI_CPUFREQ and cpufreq governor
to request the highest frequency. There is a chance that default
is the highest frequency, without those drivers. But, C-states
support and idle cores going to deep C-state greatly increase
the chances of turbo boost and C-state part will not work without
processor.ko.

Thanks,
Venki --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ