linux-kernel - Re: CONFIG_NO_HZ: missed ticks, stall (keyb IRQ required) [2.6.18-rc4-mm1]

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:	Mon, 6 Nov 2006 21:58:25 +0100
From:	Andreas Mohr <andi@...x01.fht-esslingen.de>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Andreas Mohr <andi@...x01.fht-esslingen.de>,
	Ingo Molnar <mingo@...e.hu>, len.brown@...el.com,
	linux-kernel@...r.kernel.org
Subject: Re: CONFIG_NO_HZ: missed ticks, stall (keyb IRQ required) [2.6.18-rc4-mm1]

Hi,

On Mon, Nov 06, 2006 at 05:20:32PM +0100, Thomas Gleixner wrote:
> On Fri, 2006-11-03 at 01:06 +0100, Andreas Mohr wrote:
> > ACPI: lapic on CPU 0 stops in C2[C2]
> 
> > How probable is it that the APIC timer got killed due to mis-programming
> > in Linux versus VIA chipset design garbage probability? I.e. do you think
> > there's a chance to fix C2 malfunction by going into the innards of
> > VIA chipsets operation?
> > How useful would it be to simply disable C2 operation (but not C1)
> > in CONFIG_NO_HZ mode after's been determined to kill APIC timer?:
> 
> No, we better disable local apic timer in that case. What happens if you
> boot your machine with ACPI disabled ?

Oh, interesting. Why??

Anyway, acpi=off works perfectly fine (still running -rc4-mm1-dynticks4),
as does setting
	max_cstate = ACPI_STATE_C1;
in acpi_processor_power_init()!
(currently writing this mail with this hack ;)

So why not simply do
	max_cstate = ACPI_STATE_C1;
in case acpi_timer_check_state():

+/*
+ * Some BIOS implementations switch to C3 in the published C2 state. This seems
+ * to be a common problem on AMD boxen.
+ */

yells?
This definitely *is* the problem with my AMD Athlon BIOS, it seems...

Or is it an advantage to switch off lapic in case of C2 brokenness since
that will enable us to still safely drive C2 with dynticks despite those
BIOS bugs or what?
(if I managed to draw the right conclusions about your lapic statement,
that is...)

BTW, my GUI with dynticks seems quite a lot quicker than without.
Or is that a placebo? I don't think it is...

Thanks!

Andreas Mohr
-
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/