lkml.org 
[lkml]   [2013]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@intel.com <tianyu.lan@intel.com> wrote:
>
>> From: Lan Tianyu <tianyu.lan@intel.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@redhat.com>
>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.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@redhat.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
>



\
 
 \ /
  Last update: 2013-10-26 15:41    [W:0.120 / U:0.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site