linux-kernel - Re: odd lockdep messages

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]

Message-ID: <4B95EE4C.3020606@kernel.org>
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/