linux-kernel - RE: [PATCH] acpi: Fall back to manually changing SCI

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: <57DF5FDC2DC0634FA2A310BC5B81A68D01DC9F1850@AUSX7MCPC108.AMER.DELL.COM>
Date:	Tue, 20 Apr 2010 12:31:52 -0500
From:	<Rezwanul_Kabir@...l.com>
To:	<achiang@...onical.com>, <mjg@...hat.com>
CC:	<linux-kernel@...r.kernel.org>, <linux-acpi@...r.kernel.org>,
	<lenb@...nel.org>
Subject: RE: [PATCH] acpi: Fall back to manually changing SCI_EN

Agree with getting Matthew's patch to fall back on force setting SCI_EN bit. I have discovered this issue recently with New Gen Dell systems where the systems were suspending right the first time around and then resorted to rebooting ( instead of resuming ) the second time. Also, the system would come with SCI interrupt disabled the first time around.
 I worked with the BIOS teams to get this fixed in the latest BIOS revs but just as Alex pointed out Matthew's approach seems to be the default bahaviour in the "Other OS". The problem may be more widespread than the limited set of blacklisted platforms..

Thanks..
   --rez
 

Rezwanul Kabir
Dell Inc.
512-725-0766
 

>-----Original Message-----
>From: linux-acpi-owner@...r.kernel.org 
>[mailto:linux-acpi-owner@...r.kernel.org] On Behalf Of Alex Chiang
>Sent: Tuesday, April 20, 2010 10:00 AM
>To: Matthew Garrett
>Cc: linux-kernel@...r.kernel.org; linux-acpi@...r.kernel.org; 
>lenb@...nel.org
>Subject: Re: [PATCH] acpi: Fall back to manually changing SCI_EN
>
>* Matthew Garrett <mjg@...hat.com>:
>> The ACPI spec tells us that the ACPI SCI_EN bit is under hardware 
>> control and shouldn't be touched by the OS. It seems that 
>the Leading 
>> Other OS ignores this and some machines expect this 
>behaviour. We have 
>> a blacklist for these, but given that we're able to detect 
>the failure 
>> case and the alternative to breaking the spec is letting the machine 
>> crash and burn, let's try falling back when we know the 
>alternative is 
>> a mostly-dead machine.
>
>Yes, we got a hint from a Lenovo BIOS developer:
>
>	A SCI_EN bit had not been set at S3 resume post. It
>	should be set as ACPI defines. It seems that Windows OS
>	sets SCI_EN bit by itself after S3 resume....
>
>So I believe that Matthew's approach is reasonably safe and correct.
>
>Acked-by: Alex Chiang <achiang@...onical.com>
>
>/ac
>--
>To unsubscribe from this list: send the line "unsubscribe 
>linux-acpi" in the body of a message to 
>majordomo@...r.kernel.org More majordomo info at  
>http://vger.kernel.org/majordomo-info.html
>--
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/