linux-kernel - Re: [stable] Boot failure with 2.6.27.46 on Xeon E5620 (Westmere EP)

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, 18 Nov 2010 16:24:40 -0500
From:	"S.Çağlar Onur" 
	<caglar@...Princeton.EDU>
To:	Youquan Song <youquan.song@...ux.intel.com>
Cc:	Suresh Siddha <suresh.b.siddha@...el.com>,
	Greg KH <greg@...ah.com>,
	"stable@...nel.org" <stable@...nel.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Song, Youquan" <youquan.song@...el.com>
Subject: Re: [stable] Boot failure with 2.6.27.46 on Xeon E5620 (Westmere EP)

Hi Youquan & Greg,


On May 26, 2010, at 9:23 AM, Youquan Song wrote:

>>> I can't think of any known issues in 2.6.27 that can lead to this kind
>>> of boot failure on WSM-EP. Caglar, It will be nice if you can do git
>>> bisect between working and non-working kernels.
>> 
>> Sure, I'll try to boot those with plain 2.6.27 to see but please note that it's going to be little time consuming. For each one I have to create a custom boot image for them to download and test (a.k.a. don't expect to hear from me soon :))
> 
> Hi Caglar,
> 
> What's the microcode version? Get by "dmesg | grep microcode" if you
> success boot other version of kernel.
> Can you try to disable C-state(C6) in BIOS before your boot 2.6.27?

First of all I'm really sorry that it took really long time to reply this mail as I was waiting Dell to send a loaner machine to us. This morning I've got the hardware and following patch solved the boot problem that I was observing, Greg could you consider adding that to 2.6.27-stable tree?

commit a0bf284bfedd6dc95bbee7ebf5ccf3b5f753a008
Author: Len Brown <len.brown@...el.com>
Date:   Fri May 15 01:29:31 2009 -0400

    ACPI: Idle C-states disabled by max_cstate should not disable the TSC
    
    Processor idle power states C2 and C3 stop the TSC on many machines.
    Linux recognizes this situation and marks the TSC as unstable:
    
    Marking TSC unstable due to TSC halts in idle
    
    But if those same machines are booted with "processor.max_cstate=1",
    then there is no need to validate C2 and C3, and no need to
    disable the TSC, which can be reliably used as a clocksource.
    
    Signed-off-by: Len Brown <len.brown@...el.com>
    Acked-by: Thomas Gleixner <tglx@...utronix.de>

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index e39a40a..e65476f 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -582,7 +582,7 @@ static int acpi_processor_power_verify(struct acpi_processor *pr)
 
        pr->power.timer_broadcast_on_state = INT_MAX;
 
-       for (i = 1; i < ACPI_PROCESSOR_MAX_POWER; i++) {
+       for (i = 1; i < ACPI_PROCESSOR_MAX_POWER && i <= max_cstate; i++) {
                struct acpi_processor_cx *cx = &pr->power.states[i];
 
                switch (cx->type) {


> Thanks
> -Youquan


Best,
--
S.Çağlar Onur <caglar@...princeton.edu>

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