linux-kernel - Re: [PATCH] x86/ACPI: Make Sony Vaio Z1 series to use "reboot=pci" default

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: <526BBC87.4000301@intel.com>
Date:	Sat, 26 Oct 2013 20:58:47 +0800
From:	Lan Tianyu <tianyu.lan@...el.com>
To:	Ingo Molnar <mingo@...nel.org>
CC:	Matthew Garrett <mjg@...hat.com>, hpa@...or.com, x86@...nel.org,
	holt@....com, davej@...oraproject.org, lenb@...nel.org,
	rjw@...ysocki.net, awilliam@...hat.com, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] x86/ACPI: Make Sony Vaio Z1 series to use "reboot=pci"
 default

On 10/25/2013 06:53 PM, Ingo Molnar wrote:
>
> * tianyu.lan@...el.com <tianyu.lan@...el.com> wrote:
>
>> From: Lan Tianyu <tianyu.lan@...el.com>
>>
>> Sony Vaio Z1 series require "reboot=pci" for reboot and power off.
>> This patch is to add them machines to quirk table and set pci reboot
>> default.
>>
>> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=61721
>> Reported-and-tested-by: Adam Williamson <awilliam@...hat.com>
>> Signed-off-by: Lan Tianyu <tianyu.lan@...el.com>
>> ---
>>   arch/x86/kernel/reboot.c |    8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
>> index 7e920bf..083ade7 100644
>> --- a/arch/x86/kernel/reboot.c
>> +++ b/arch/x86/kernel/reboot.c
>> @@ -382,6 +382,14 @@ static struct dmi_system_id __initdata reboot_dmi_table[] = {
>>   			DMI_MATCH(DMI_PRODUCT_NAME, "C6100"),
>>   		},
>>   	},
>> +	{	/* Handle problems with rebooting on Sony Vaio Z1 series*/
>> +		.callback = set_pci_reboot,
>> +		.ident = "Sony Vaio Z1",
>> +		.matches = {
>> +		DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
>> +		DMI_MATCH(DMI_PRODUCT_NAME, "VPCZ1"),
>> +		},
>> +	},
>
> This is becoming somewhat endemic - do we know _why_ the ACPI reboot
> method does not work?
>
> We reworked the x86 reboot sequence 2.5 years agom, in:
>
>   commit 660e34cebf0a11d54f2d5dd8838607452355f321
>   Author: Matthew Garrett <mjg@...hat.com>
>   Date:   Mon Apr 4 13:55:05 2011 -0400
>
>      x86: Reorder reboot method preferences
>
>      We have a never ending stream of 'reboot quirks' for new boxes
>      that will not reboot properly under Linux (they will hang on
>      reboot).
>
>      The reason is widespread 'Windows compatible' assumption of modern
>      x86 hardware, which expects the following reboot sequence:
>
>       - hitting the ACPI reboot vector (if available)
>       - trying the keyboard controller
>       - hitting the ACPI reboot vector again
>       - then giving the keyboard controller one last go
>
>      This sequence expectation gets more and more embedded in modern
>      hardware, which often lacks a keyboard controller and may even
>      lock up if the legacy io ports are hit - and which hardware is
>      often not tested with Linux during development.
>
>      The end result is that reboot works under Windows-alike OSs but not
>      under Linux.
>
>      Rework our reboot process to meet this hardware externality a little
>      better and match this assumption of newer x86 hardware.
>
>      In addition to the ACPI,kbd,ACPI,kbd sequence we'll still fall
>      through to attempting a legacy triple fault if nothing else
>      works - and keep trying that and the kbd reset.
>
>      [...]
>
> Do we know why reboot apparently works quickly enough on Windows on
> this laptop, but not under Linux? Does Windows use the ACPI reboot
> method? If yes, does it use a different pattern?
>
> Is it all perhaps virtualization or IRQ routing related?
>
> I.e. we really need a real analysis here, not just a quirk!

Sorry about this. Will do some analyses.

>
> Thanks,
>
> 	Ingo
>

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