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:	Wed, 05 Nov 2008 08:48:12 +0800
From:	Zhao Yakui <yakui.zhao@...el.com>
To:	Greg KH <gregkh@...e.de>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"stable@...nel.org" <stable@...nel.org>,
	Justin Forbes <jmforbes@...uxtx.org>,
	Zwane Mwaikambo <zwane@....linux.org.uk>,
	Theodore Ts'o <tytso@....edu>,
	Randy Dunlap <rdunlap@...otime.net>,
	Dave Jones <davej@...hat.com>,
	Chuck Wolber <chuckw@...ntumlinux.com>,
	Chris Wedgwood <reviews@...cw.f00f.org>,
	Michael Krufky <mkrufky@...uxtv.org>,
	Chuck Ebbert <cebbert@...hat.com>,
	Domenico Andreoli <cavokz@...il.com>, Willy Tarreau <w@....eu>,
	Rodrigo Rubira Branco <rbranco@...checkpoint.com>,
	Jake Edge <jake@....net>, Eugene Teo <eteo@...hat.com>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"alan@...rguk.ukuu.org.uk" <alan@...rguk.ukuu.org.uk>,
	"Brown, Len" <len.brown@...el.com>
Subject: Re: [patch 51/57] ACPI: Ingore the RESET_REG_SUP bit when using
	ACPI reset mechanism

On Wed, 2008-11-05 at 07:33 +0800, Greg KH wrote:
> 2.6.27-stable review patch.  If anyone has any objections, please let us know.
Please don't apply this patch.And this causes the reboot regression on
AMD chipset. (Bug11942)
    Now the default reboot type is changed from BOOT_KBD to BOOT_ACPI.
      
On the AMD box there exists the definition of RESET_REG &RESET_VALUE,
which is identical to the definition in Intel Chipset. After the
RESET_REG_SUP is ignored, the AMD box can't be rebooted by writing the
RESET_VALUE to RESET_REG I/O port.

Thanks.
   Yakui
    
> 
> ------------------
> From: Zhao Yakui <yakui.zhao@...el.com>
> 
> Subject: [patch 51/57] ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism
> 
> commit 8fd145917fb62368a9b80db59562c20576238f5a upstream
> 
> ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism
> 
> According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates
> whether the ACPI reboot mechanism is supported.
> 
> However, some boxes have this bit clear, have a valid
> ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only
> mechanism that works for them after S3.
> 
> This suggests that other operating systems may not be checking
> the RESET_REG_SUP bit, and are using other means to decide
> whether to use the ACPI reboot mechanism or not.
> 
> Here we stop checking RESET_REG_SUP.
> Instead, When acpi reboot is requested,
> only the reset_register is checked. If the following
> conditions are met, it indicates that the reset register is supported.
> 	a. reset_register is not zero
> 	b. the access width is eight
> 	c. the bit_offset is zero
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=7299
> http://bugzilla.kernel.org/show_bug.cgi?id=1148
> 
> Signed-off-by: Zhao Yakui <yakui.zhao@...el.com>
> Signed-off-by: Len Brown <len.brown@...el.com>
> Cc: Chuck Ebbert <cebbert@...hat.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
> 
> ---
>  drivers/acpi/reboot.c |   25 ++++++++++++++++++++++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> --- a/drivers/acpi/reboot.c
> +++ b/drivers/acpi/reboot.c
> @@ -15,9 +15,28 @@ void acpi_reboot(void)
>  
>  	rr = &acpi_gbl_FADT.reset_register;
>  
> -	/* Is the reset register supported? */
> -	if (!(acpi_gbl_FADT.flags & ACPI_FADT_RESET_REGISTER) ||
> -	    rr->bit_width != 8 || rr->bit_offset != 0)
> +	/*
> +	 * Is the ACPI reset register supported?
> +	 *
> +	 * According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates
> +	 * whether the ACPI reset mechanism is supported.
> +	 *
> +	 * However, some boxes have this bit clear, yet a valid
> +	 * ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only
> +	 * mechanism that works for them after S3.
> +	 *
> +	 * This suggests that other operating systems may not be checking
> +	 * the RESET_REG_SUP bit, and are using other means to decide
> +	 * whether to use the ACPI reboot mechanism or not.
> +	 *
> +	 * So when acpi reboot is requested,
> +	 * only the reset_register is checked. If the following
> +	 * conditions are met, it indicates that the reset register is supported.
> +	 * 	a. reset_register is not zero
> +	 * 	b. the access width is eight
> +	 * 	c. the bit_offset is zero
> +	 */
> +	if (!(rr->address) || rr->bit_width != 8 || rr->bit_offset != 0)
>  		return;
>  
>  	reset_value = acpi_gbl_FADT.reset_value;
> 

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ