linux-kernel - Re: latest -git: WARNING: at arch/x86/kernel/ipi.c:123 send_IPI_mask

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: <20080825195029.GA27030@redhat.com>
Date:	Mon, 25 Aug 2008 15:50:31 -0400
From:	Dave Jones <davej@...hat.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Vegard Nossum <vegard.nossum@...il.com>,
	"H. Peter Anvin" <hpa@...nel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: latest -git: WARNING: at arch/x86/kernel/ipi.c:123
	send_IPI_mask_bitmask+0xc3/0xe0()

On Mon, Aug 25, 2008 at 09:39:26PM +0200, Andi Kleen wrote:
 > On Mon, Aug 25, 2008 at 02:54:51PM -0400, Dave Jones wrote:
 > > On Mon, Aug 25, 2008 at 08:36:11PM +0200, Andi Kleen wrote:
 > >  > > Probably because you're using p4-clockmod, and it's crap.
 > >  > 
 > >  > Really should really bite the bullet and just remove it. People 
 > >  > run in this all the time and I bet you can count the people who
 > >  > actually use it consciously and usefully with one hand.
 > >  > 
 > >  > Or at least only make it run when the user set a "I_REALLY_KNOW_WHAT_I_AM_DOING"
 > >  > option explicitely.
 > > 
 > > We can't really remove it until ACPI processor driver has a better
 > > response than 'thermal event, argh!, shut down'.
 > 
 > It only does that when the critical trip point is reached (which
 > basically means that the BIOS tells it -- "I'm on fire"). What else should 
 > it do in your opinion when this happens?

On some systems (for which there aren't BIOS updates) the trip points are
set too low.  If we get a thermal event that was caused by temporary
increased workload, temperature will drop off again when that workload
is complete.

For sustained workloads we'd get additional thermal events, at which
time we make a decision "ok, we've throttled as far as we can, and
things are still going badly, power off".

In the event of a failed fan or similar, shutting down is obviously
the right thing to do, and we'd get further thermal events after
throttling which would allow us to do so.

	Dave

-- 
http://www.codemonkey.org.uk
--
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/