linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: tianyu.lan@intel.com, Matthew Garrett <mjg@redhat.com>
Cc: hpa@zytor.com, x86@kernel.org, holt@sgi.com,
	davej@fedoraproject.org, lenb@kernel.org, rjw@rjwysocki.net,
	awilliam@redhat.com, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] x86/ACPI: Make Sony Vaio Z1 series to use "reboot=pci" default
Date: Fri, 25 Oct 2013 12:53:52 +0200	[thread overview]
Message-ID: <20131025105352.GA5419@gmail.com> (raw)
In-Reply-To: <1382597377-26797-1-git-send-email-tianyu.lan@intel.com>


* 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!

Thanks,

	Ingo

  reply	other threads:[~2013-10-25 10:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-24  6:49 [PATCH] x86/ACPI: Make Sony Vaio Z1 series to use "reboot=pci" default tianyu.lan
2013-10-25 10:53 ` Ingo Molnar [this message]
2013-10-25 12:44   ` Dave Jones
2013-10-25 12:48     ` H. Peter Anvin
2013-10-25 12:54       ` Linus Torvalds
2013-10-25 16:47   ` Adam Williamson
2013-10-25 17:16     ` Linus Torvalds
2013-10-25 17:43       ` Adam Williamson
2013-10-25 19:44         ` Rafael J. Wysocki
2013-10-26  1:27       ` Adam Williamson
2013-10-26  2:20         ` Adam Williamson
2013-10-26  3:17           ` Dave Jones
2013-10-26  7:22             ` Adam Williamson
2013-10-26  9:15               ` Ingo Molnar
2013-10-26 17:08                 ` Adam Williamson
2013-10-26 20:00                   ` Linus Torvalds
2013-10-27  7:06                 ` Adam Williamson
2013-11-01 14:02                   ` Joerg Roedel
2013-11-18 23:43                     ` Adam Williamson
2013-11-19  7:03                       ` Ingo Molnar
2013-10-26 12:58   ` Lan Tianyu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131025105352.GA5419@gmail.com \
    --to=mingo@kernel.org \
    --cc=awilliam@redhat.com \
    --cc=davej@fedoraproject.org \
    --cc=holt@sgi.com \
    --cc=hpa@zytor.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg@redhat.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=tianyu.lan@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).