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:	Tue, 09 Mar 2010 15:44:28 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Valdis.Kletnieks@...edu
CC:	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: odd lockdep messages

Hello,

On 03/09/2010 03:27 PM, Valdis.Kletnieks@...edu wrote:
> Doesn't seem to make a difference, sorry.
> 
> For what it's worth, adding the iwlwifi-5000-2.ucode to the builtin firmware
> list fixed the two BUG: messages related to the firmware load.  Not sure if
> that tells you anything or not.
> 
> However, I still have left:
> 
> [    0.997904] Monitor-Mwait will be used to enter C-1 state
> [    0.998045] Monitor-Mwait will be used to enter C-2 state
> [    0.998184] Monitor-Mwait will be used to enter C-3 state
> [    0.998300] Marking TSC unstable due to TSC halts in idle
> [    0.998476] Switching to clocksource hpet
> [    1.030681] BUG: key ffff88011c8c1d00 not in .data!
> [    1.030787] BUG: key ffff88011c8c1d48 not in .data!
> [    1.035288] thermal LNXTHERM:01: registered as thermal_zone0
> [    1.035405] ACPI: Thermal Zone [THM] (54 C)
> [    1.041622] Real Time Clock Driver v1.12b
> [    1.041955] Linux agpgart interface v0.103
> [    1.042266] Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
> 
> I'll stick a 'WAR_ON(1)' next to that BUG printk so we get an idea where it's
> happening, probably be morning before that happens though...

Hmm... the original percpu address check wasn't correct but wasn't too
far off either so it wouldn't be surprising nothing triggered it.
Yeap, stack trace should tell us where the address is coming from.

Thanks.

-- 
tejun
--
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