EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ingo Molnar]

(Cc:-ed EFI and ACPI folks.)

* tip-bot for Jian-Hong Pan <tipbot@zytor.com> wrote:

> Commit-ID:  0082517fa4bce073e7cf542633439f26538a14cc
> Gitweb:     https://git.kernel.org/tip/0082517fa4bce073e7cf542633439f26538a14cc
> Author:     Jian-Hong Pan <jian-hong@endlessm.com>
> AuthorDate: Fri, 12 Apr 2019 16:01:53 +0800
> Committer:  Ingo Molnar <mingo@kernel.org>
> CommitDate: Tue, 16 Apr 2019 10:01:24 +0200
> 
> x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T
> 
> Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
> shutdown process, but then it hangs in BIOS POST with a black screen.
> 
> The problem is intermittent - at some points it has appeared related to
> Secure Boot settings or different kernel builds, but ultimately we have
> not been able to identify the exact conditions that trigger the issue to
> come and go.
> 
> Besides, the EFI mode cannot be disabled in the BIOS of this model.
> 
> However, after extensive testing, we observe that using the EFI reboot
> method reliably avoids the issue in all cases.
> 
> So add a boot time quirk to use EFI reboot on such systems.
> 
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> Signed-off-by: Daniel Drake <drake@endlessm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Matt Fleming <matt@codeblueprint.co.uk>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: linux-efi@vger.kernel.org
> Cc: linux@endlessm.com
> Link: http://lkml.kernel.org/r/20190412080152.3718-1-jian-hong@endlessm.com
> [ Fix !CONFIG_EFI build failure, clarify the code and the changelog a bit. ]
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> ---
>  arch/x86/kernel/reboot.c | 21 +++++++++++++++++++++
>  include/linux/efi.h      |  7 ++++++-
>  2 files changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
> index 725624b6c0c0..8fd3cedd9acc 100644
> --- a/arch/x86/kernel/reboot.c
> +++ b/arch/x86/kernel/reboot.c
> @@ -81,6 +81,19 @@ static int __init set_bios_reboot(const struct dmi_system_id *d)
>  	return 0;
>  }
>  
> +/*
> + * Some machines don't handle the default ACPI reboot method and
> + * require the EFI reboot method:
> + */
> +static int __init set_efi_reboot(const struct dmi_system_id *d)
> +{
> +	if (reboot_type != BOOT_EFI && !efi_runtime_disabled()) {
> +		reboot_type = BOOT_EFI;
> +		pr_info("%s series board detected. Selecting EFI-method for reboot.\n", d->ident);
> +	}
> +	return 0;
> +}
> +
>  void __noreturn machine_real_restart(unsigned int type)
>  {
>  	local_irq_disable();
> @@ -166,6 +179,14 @@ static const struct dmi_system_id reboot_dmi_table[] __initconst = {
>  			DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
>  		},
>  	},
> +	{	/* Handle reboot issue on Acer TravelMate X514-51T */
> +		.callback = set_efi_reboot,
> +		.ident = "Acer TravelMate X514-51T",
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
> +			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate X514-51T"),
> +		},
> +	},
>  
>  	/* Apple */
>  	{	/* Handle problems with rebooting on Apple MacBook5 */
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 54357a258b35..6ebc2098cfe1 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -1611,7 +1611,12 @@ efi_status_t efi_setup_gop(efi_system_table_t *sys_table_arg,
>  			   struct screen_info *si, efi_guid_t *proto,
>  			   unsigned long size);
>  
> -bool efi_runtime_disabled(void);
> +#ifdef CONFIG_EFI
> +extern bool efi_runtime_disabled(void);
> +#else
> +static inline bool efi_runtime_disabled(void) { return true; }
> +#endif
> +

1)

Small build fix:

I added the efi.h bit to make it build on !CONFIG_EFI. Turns out 
efi_runtime_disabled() was already used in !CONFIG_EFI code, but its 
usage was masked by efi_reboot_required():

        if (!rv && efi_reboot_required() && !efi_runtime_disabled())


2)

I wanted to get a second opinion from the EFI folks for this whole 
concept. On x86 we default to ACPI reboot on modern systems, and we 
default to EFI reboot on modern EFI systems, via the 
efi_reboot_required() method which keys off on acpi_gbl_reduced_hardware 
to create a barrier for older ACPI systems.

It appears that Acer TravelMate X514-51T systems get marked as 
'acpi_gbl_reduced_hardware' which enables ACPI-reboot, but they require 
EFI-reboot.

Should we perhaps re-think the boundary between EFI-reboot and 
ACPI-reboot systems? I.e. if the EFI runtime is enabled, shouldn't we 
just use the EFI reboot method?

What does Windows do (which is really the standard test desktop PC makers 
use) - do they use the EFI reboot method unconditionally, or do they have 
more complex quirks as well?

Anyway, I applied the patch because it solves a spurious reboot hang bug 
on these systems, but wanted to raise this whole EFI reboot vs. ACPI 
reboot issue, as quirks are generally not overly precise in identifying 
the true scope of problems.

Thanks,

	Ingo

EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ingo Molnar]

(Cc:-ed EFI and ACPI folks.)

* tip-bot for Jian-Hong Pan <tipbot@zytor.com> wrote:

> Commit-ID:  0082517fa4bce073e7cf542633439f26538a14cc
> Gitweb:     https://git.kernel.org/tip/0082517fa4bce073e7cf542633439f26538a14cc
> Author:     Jian-Hong Pan <jian-hong@endlessm.com>
> AuthorDate: Fri, 12 Apr 2019 16:01:53 +0800
> Committer:  Ingo Molnar <mingo@kernel.org>
> CommitDate: Tue, 16 Apr 2019 10:01:24 +0200
> 
> x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T
> 
> Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
> shutdown process, but then it hangs in BIOS POST with a black screen.
> 
> The problem is intermittent - at some points it has appeared related to
> Secure Boot settings or different kernel builds, but ultimately we have
> not been able to identify the exact conditions that trigger the issue to
> come and go.
> 
> Besides, the EFI mode cannot be disabled in the BIOS of this model.
> 
> However, after extensive testing, we observe that using the EFI reboot
> method reliably avoids the issue in all cases.
> 
> So add a boot time quirk to use EFI reboot on such systems.
> 
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> Signed-off-by: Daniel Drake <drake@endlessm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Matt Fleming <matt@codeblueprint.co.uk>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: linux-efi@vger.kernel.org
> Cc: linux@endlessm.com
> Link: http://lkml.kernel.org/r/20190412080152.3718-1-jian-hong@endlessm.com
> [ Fix !CONFIG_EFI build failure, clarify the code and the changelog a bit. ]
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> ---
>  arch/x86/kernel/reboot.c | 21 +++++++++++++++++++++
>  include/linux/efi.h      |  7 ++++++-
>  2 files changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
> index 725624b6c0c0..8fd3cedd9acc 100644
> --- a/arch/x86/kernel/reboot.c
> +++ b/arch/x86/kernel/reboot.c
> @@ -81,6 +81,19 @@ static int __init set_bios_reboot(const struct dmi_system_id *d)
>  	return 0;
>  }
>  
> +/*
> + * Some machines don't handle the default ACPI reboot method and
> + * require the EFI reboot method:
> + */
> +static int __init set_efi_reboot(const struct dmi_system_id *d)
> +{
> +	if (reboot_type != BOOT_EFI && !efi_runtime_disabled()) {
> +		reboot_type = BOOT_EFI;
> +		pr_info("%s series board detected. Selecting EFI-method for reboot.\n", d->ident);
> +	}
> +	return 0;
> +}
> +
>  void __noreturn machine_real_restart(unsigned int type)
>  {
>  	local_irq_disable();
> @@ -166,6 +179,14 @@ static const struct dmi_system_id reboot_dmi_table[] __initconst = {
>  			DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
>  		},
>  	},
> +	{	/* Handle reboot issue on Acer TravelMate X514-51T */
> +		.callback = set_efi_reboot,
> +		.ident = "Acer TravelMate X514-51T",
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
> +			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate X514-51T"),
> +		},
> +	},
>  
>  	/* Apple */
>  	{	/* Handle problems with rebooting on Apple MacBook5 */
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 54357a258b35..6ebc2098cfe1 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -1611,7 +1611,12 @@ efi_status_t efi_setup_gop(efi_system_table_t *sys_table_arg,
>  			   struct screen_info *si, efi_guid_t *proto,
>  			   unsigned long size);
>  
> -bool efi_runtime_disabled(void);
> +#ifdef CONFIG_EFI
> +extern bool efi_runtime_disabled(void);
> +#else
> +static inline bool efi_runtime_disabled(void) { return true; }
> +#endif
> +

1)

Small build fix:

I added the efi.h bit to make it build on !CONFIG_EFI. Turns out 
efi_runtime_disabled() was already used in !CONFIG_EFI code, but its 
usage was masked by efi_reboot_required():

        if (!rv && efi_reboot_required() && !efi_runtime_disabled())


2)

I wanted to get a second opinion from the EFI folks for this whole 
concept. On x86 we default to ACPI reboot on modern systems, and we 
default to EFI reboot on modern EFI systems, via the 
efi_reboot_required() method which keys off on acpi_gbl_reduced_hardware 
to create a barrier for older ACPI systems.

It appears that Acer TravelMate X514-51T systems get marked as 
'acpi_gbl_reduced_hardware' which enables ACPI-reboot, but they require 
EFI-reboot.

Should we perhaps re-think the boundary between EFI-reboot and 
ACPI-reboot systems? I.e. if the EFI runtime is enabled, shouldn't we 
just use the EFI reboot method?

What does Windows do (which is really the standard test desktop PC makers 
use) - do they use the EFI reboot method unconditionally, or do they have 
more complex quirks as well?

Anyway, I applied the patch because it solves a spurious reboot hang bug 
on these systems, but wanted to raise this whole EFI reboot vs. ACPI 
reboot issue, as quirks are generally not overly precise in identifying 
the true scope of problems.

Thanks,

	Ingo

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Daniel Drake]

On Tue, Apr 16, 2019 at 4:20 PM Ingo Molnar <mingo@kernel.org> wrote:
> I wanted to get a second opinion from the EFI folks for this whole
> concept. On x86 we default to ACPI reboot on modern systems, and we
> default to EFI reboot on modern EFI systems, via the
> efi_reboot_required() method which keys off on acpi_gbl_reduced_hardware
> to create a barrier for older ACPI systems.

So if acpi_gbl_reduced_hardware is set, we are on a "modern EFI
system", and EFI reboot is used.

> It appears that Acer TravelMate X514-51T systems get marked as
> 'acpi_gbl_reduced_hardware' which enables ACPI-reboot, but they require
> EFI-reboot.

We will double check, but in this case I believe the system is *not*
marked as reduced hardware, which is why ACPI reboot is used.

> Should we perhaps re-think the boundary between EFI-reboot and
> ACPI-reboot systems? I.e. if the EFI runtime is enabled, shouldn't we
> just use the EFI reboot method?

I agree this is a good question.

We also previously hit a similar issue for shutdown on Acer laptops
which is still unresolved.
https://marc.info/?l=linux-acpi&m=148857214431346&w=2

Daniel

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Daniel Drake]

On Tue, Apr 16, 2019 at 4:20 PM Ingo Molnar <mingo@kernel.org> wrote:
> I wanted to get a second opinion from the EFI folks for this whole
> concept. On x86 we default to ACPI reboot on modern systems, and we
> default to EFI reboot on modern EFI systems, via the
> efi_reboot_required() method which keys off on acpi_gbl_reduced_hardware
> to create a barrier for older ACPI systems.

So if acpi_gbl_reduced_hardware is set, we are on a "modern EFI
system", and EFI reboot is used.

> It appears that Acer TravelMate X514-51T systems get marked as
> 'acpi_gbl_reduced_hardware' which enables ACPI-reboot, but they require
> EFI-reboot.

We will double check, but in this case I believe the system is *not*
marked as reduced hardware, which is why ACPI reboot is used.

> Should we perhaps re-think the boundary between EFI-reboot and
> ACPI-reboot systems? I.e. if the EFI runtime is enabled, shouldn't we
> just use the EFI reboot method?

I agree this is a good question.

We also previously hit a similar issue for shutdown on Acer laptops
which is still unresolved.
https://marc.info/?l=linux-acpi&m=148857214431346&w=2

Daniel

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ingo Molnar]

* Daniel Drake <drake@endlessm.com> wrote:

> On Tue, Apr 16, 2019 at 4:20 PM Ingo Molnar <mingo@kernel.org> wrote:
> > I wanted to get a second opinion from the EFI folks for this whole
> > concept. On x86 we default to ACPI reboot on modern systems, and we
> > default to EFI reboot on modern EFI systems, via the
> > efi_reboot_required() method which keys off on acpi_gbl_reduced_hardware
> > to create a barrier for older ACPI systems.
> 
> So if acpi_gbl_reduced_hardware is set, we are on a "modern EFI
> system", and EFI reboot is used.
> 
> > It appears that Acer TravelMate X514-51T systems get marked as
> > 'acpi_gbl_reduced_hardware' which enables ACPI-reboot, but they require
> > EFI-reboot.
> 
> We will double check, but in this case I believe the system is *not*
> marked as reduced hardware, which is why ACPI reboot is used.

Ok, so acpi_gbl_reduced_hardware is set when the ... 'reduced hardware' 
bit is set:

        acpi_gbl_reduced_hardware = FALSE;
        if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) {
                acpi_gbl_reduced_hardware = TRUE;
        }


which is described as:

 #define ACPI_FADT_HW_REDUCED        (1<<20)     /* 20: [V5] ACPI hardware is not implemented (ACPI 5.0) */

That seems counter-intuitive to me: if no full ACPI hardware is 
implemented then we should assume reduced ACPI functionality, i.e. if the 
EFI runtime is otherwise available we should default to it.

> > Should we perhaps re-think the boundary between EFI-reboot and
> > ACPI-reboot systems? I.e. if the EFI runtime is enabled, shouldn't we
> > just use the EFI reboot method?
> 
> I agree this is a good question.
> 
> We also previously hit a similar issue for shutdown on Acer laptops
> which is still unresolved.
> https://marc.info/?l=linux-acpi&m=148857214431346&w=2

Yeah.

Feel free to send a patch that makes EFI reboot the default one under 
these circumstances, we could put it into tip:x86/platform or so, and let 
it get tested for another kernel cycle. If it's problem-free we could 
push that upstream. (Famous last words.)

(This won't affect the ACER notebook quirk in tip:x86/urgent, which is 
the short-term solution and the -stable tag.)

Thanks,

	Ingo

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ingo Molnar]

* Daniel Drake <drake@endlessm.com> wrote:

> On Tue, Apr 16, 2019 at 4:20 PM Ingo Molnar <mingo@kernel.org> wrote:
> > I wanted to get a second opinion from the EFI folks for this whole
> > concept. On x86 we default to ACPI reboot on modern systems, and we
> > default to EFI reboot on modern EFI systems, via the
> > efi_reboot_required() method which keys off on acpi_gbl_reduced_hardware
> > to create a barrier for older ACPI systems.
> 
> So if acpi_gbl_reduced_hardware is set, we are on a "modern EFI
> system", and EFI reboot is used.
> 
> > It appears that Acer TravelMate X514-51T systems get marked as
> > 'acpi_gbl_reduced_hardware' which enables ACPI-reboot, but they require
> > EFI-reboot.
> 
> We will double check, but in this case I believe the system is *not*
> marked as reduced hardware, which is why ACPI reboot is used.

Ok, so acpi_gbl_reduced_hardware is set when the ... 'reduced hardware' 
bit is set:

        acpi_gbl_reduced_hardware = FALSE;
        if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) {
                acpi_gbl_reduced_hardware = TRUE;
        }


which is described as:

 #define ACPI_FADT_HW_REDUCED        (1<<20)     /* 20: [V5] ACPI hardware is not implemented (ACPI 5.0) */

That seems counter-intuitive to me: if no full ACPI hardware is 
implemented then we should assume reduced ACPI functionality, i.e. if the 
EFI runtime is otherwise available we should default to it.

> > Should we perhaps re-think the boundary between EFI-reboot and
> > ACPI-reboot systems? I.e. if the EFI runtime is enabled, shouldn't we
> > just use the EFI reboot method?
> 
> I agree this is a good question.
> 
> We also previously hit a similar issue for shutdown on Acer laptops
> which is still unresolved.
> https://marc.info/?l=linux-acpi&m=148857214431346&w=2

Yeah.

Feel free to send a patch that makes EFI reboot the default one under 
these circumstances, we could put it into tip:x86/platform or so, and let 
it get tested for another kernel cycle. If it's problem-free we could 
push that upstream. (Famous last words.)

(This won't affect the ACER notebook quirk in tip:x86/urgent, which is 
the short-term solution and the -stable tag.)

Thanks,

	Ingo

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Daniel Drake]

On Wed, Apr 17, 2019 at 2:16 PM Ingo Molnar <mingo@kernel.org> wrote:
> Ok, so acpi_gbl_reduced_hardware is set when the ... 'reduced hardware'
> bit is set:
>
>         acpi_gbl_reduced_hardware = FALSE;
>         if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) {
>                 acpi_gbl_reduced_hardware = TRUE;
>         }
>
>
> which is described as:
>
>  #define ACPI_FADT_HW_REDUCED        (1<<20)     /* 20: [V5] ACPI hardware is not implemented (ACPI 5.0) */
>
> That seems counter-intuitive to me: if no full ACPI hardware is
> implemented then we should assume reduced ACPI functionality, i.e. if the
> EFI runtime is otherwise available we should default to it.

It's a bit confusing, but my loose understanding is that previous
versions of the ACPI spec required system implementors to implement
the whole thing; but that's increasingly impractical today, e.g. with
ARM systems coming along, which do not gel well with some of the
historical x86-rooted design aspects that spilled over into ACPI. The
V5 spec introduces reduced mode as an opt-in new feature, but for
compatibility with pre-V5 implementations it needs to consider "full
hardware" mode as the default.

> Feel free to send a patch that makes EFI reboot the default one under
> these circumstances,

Just to check, you mean: EFI reboot (and shutdown) become the default
methods when the machine is booted in EFI mode, and EFI stuff has not
been disabled with a kernel parameter?
Even when running in full hardware ACPI mode.

Thanks
Daniel

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Daniel Drake]

On Wed, Apr 17, 2019 at 2:16 PM Ingo Molnar <mingo@kernel.org> wrote:
> Ok, so acpi_gbl_reduced_hardware is set when the ... 'reduced hardware'
> bit is set:
>
>         acpi_gbl_reduced_hardware = FALSE;
>         if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) {
>                 acpi_gbl_reduced_hardware = TRUE;
>         }
>
>
> which is described as:
>
>  #define ACPI_FADT_HW_REDUCED        (1<<20)     /* 20: [V5] ACPI hardware is not implemented (ACPI 5.0) */
>
> That seems counter-intuitive to me: if no full ACPI hardware is
> implemented then we should assume reduced ACPI functionality, i.e. if the
> EFI runtime is otherwise available we should default to it.

It's a bit confusing, but my loose understanding is that previous
versions of the ACPI spec required system implementors to implement
the whole thing; but that's increasingly impractical today, e.g. with
ARM systems coming along, which do not gel well with some of the
historical x86-rooted design aspects that spilled over into ACPI. The
V5 spec introduces reduced mode as an opt-in new feature, but for
compatibility with pre-V5 implementations it needs to consider "full
hardware" mode as the default.

> Feel free to send a patch that makes EFI reboot the default one under
> these circumstances,

Just to check, you mean: EFI reboot (and shutdown) become the default
methods when the machine is booted in EFI mode, and EFI stuff has not
been disabled with a kernel parameter?
Even when running in full hardware ACPI mode.

Thanks
Daniel

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[hpa]

On April 17, 2019 5:38:41 AM PDT, Daniel Drake <drake@endlessm.com> wrote:
>On Wed, Apr 17, 2019 at 2:16 PM Ingo Molnar <mingo@kernel.org> wrote:
>> Ok, so acpi_gbl_reduced_hardware is set when the ... 'reduced
>hardware'
>> bit is set:
>>
>>         acpi_gbl_reduced_hardware = FALSE;
>>         if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) {
>>                 acpi_gbl_reduced_hardware = TRUE;
>>         }
>>
>>
>> which is described as:
>>
>>  #define ACPI_FADT_HW_REDUCED        (1<<20)     /* 20: [V5] ACPI
>hardware is not implemented (ACPI 5.0) */
>>
>> That seems counter-intuitive to me: if no full ACPI hardware is
>> implemented then we should assume reduced ACPI functionality, i.e. if
>the
>> EFI runtime is otherwise available we should default to it.
>
>It's a bit confusing, but my loose understanding is that previous
>versions of the ACPI spec required system implementors to implement
>the whole thing; but that's increasingly impractical today, e.g. with
>ARM systems coming along, which do not gel well with some of the
>historical x86-rooted design aspects that spilled over into ACPI. The
>V5 spec introduces reduced mode as an opt-in new feature, but for
>compatibility with pre-V5 implementations it needs to consider "full
>hardware" mode as the default.
>
>> Feel free to send a patch that makes EFI reboot the default one under
>> these circumstances,
>
>Just to check, you mean: EFI reboot (and shutdown) become the default
>methods when the machine is booted in EFI mode, and EFI stuff has not
>been disabled with a kernel parameter?
>Even when running in full hardware ACPI mode.
>
>Thanks
>Daniel

This, I believe, is known to not work.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[hpa]

On April 17, 2019 5:38:41 AM PDT, Daniel Drake <drake@endlessm.com> wrote:
>On Wed, Apr 17, 2019 at 2:16 PM Ingo Molnar <mingo@kernel.org> wrote:
>> Ok, so acpi_gbl_reduced_hardware is set when the ... 'reduced
>hardware'
>> bit is set:
>>
>>         acpi_gbl_reduced_hardware = FALSE;
>>         if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) {
>>                 acpi_gbl_reduced_hardware = TRUE;
>>         }
>>
>>
>> which is described as:
>>
>>  #define ACPI_FADT_HW_REDUCED        (1<<20)     /* 20: [V5] ACPI
>hardware is not implemented (ACPI 5.0) */
>>
>> That seems counter-intuitive to me: if no full ACPI hardware is
>> implemented then we should assume reduced ACPI functionality, i.e. if
>the
>> EFI runtime is otherwise available we should default to it.
>
>It's a bit confusing, but my loose understanding is that previous
>versions of the ACPI spec required system implementors to implement
>the whole thing; but that's increasingly impractical today, e.g. with
>ARM systems coming along, which do not gel well with some of the
>historical x86-rooted design aspects that spilled over into ACPI. The
>V5 spec introduces reduced mode as an opt-in new feature, but for
>compatibility with pre-V5 implementations it needs to consider "full
>hardware" mode as the default.
>
>> Feel free to send a patch that makes EFI reboot the default one under
>> these circumstances,
>
>Just to check, you mean: EFI reboot (and shutdown) become the default
>methods when the machine is booted in EFI mode, and EFI stuff has not
>been disabled with a kernel parameter?
>Even when running in full hardware ACPI mode.
>
>Thanks
>Daniel

This, I believe, is known to not work.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ard Biesheuvel]

On Wed, 17 Apr 2019 at 08:16, <hpa@zytor.com> wrote:
>
> On April 17, 2019 5:38:41 AM PDT, Daniel Drake <drake@endlessm.com> wrote:
> >On Wed, Apr 17, 2019 at 2:16 PM Ingo Molnar <mingo@kernel.org> wrote:
> >> Ok, so acpi_gbl_reduced_hardware is set when the ... 'reduced
> >hardware'
> >> bit is set:
> >>
> >>         acpi_gbl_reduced_hardware = FALSE;
> >>         if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) {
> >>                 acpi_gbl_reduced_hardware = TRUE;
> >>         }
> >>
> >>
> >> which is described as:
> >>
> >>  #define ACPI_FADT_HW_REDUCED        (1<<20)     /* 20: [V5] ACPI
> >hardware is not implemented (ACPI 5.0) */
> >>
> >> That seems counter-intuitive to me: if no full ACPI hardware is
> >> implemented then we should assume reduced ACPI functionality, i.e. if
> >the
> >> EFI runtime is otherwise available we should default to it.
> >
> >It's a bit confusing, but my loose understanding is that previous
> >versions of the ACPI spec required system implementors to implement
> >the whole thing; but that's increasingly impractical today, e.g. with
> >ARM systems coming along, which do not gel well with some of the
> >historical x86-rooted design aspects that spilled over into ACPI. The
> >V5 spec introduces reduced mode as an opt-in new feature, but for
> >compatibility with pre-V5 implementations it needs to consider "full
> >hardware" mode as the default.
> >
> >> Feel free to send a patch that makes EFI reboot the default one under
> >> these circumstances,
> >
> >Just to check, you mean: EFI reboot (and shutdown) become the default
> >methods when the machine is booted in EFI mode, and EFI stuff has not
> >been disabled with a kernel parameter?
> >Even when running in full hardware ACPI mode.
> >
> >Thanks
> >Daniel
>
> This, I believe, is known to not work.

It definitely used to be the case that EFI reboot was unreliable, but
I don't know the details. I have added Sai to cc, he may be able to
provide a bit more context here, since he added the code to deal with
page faults during EFI runtime service invocations (which was inspired
by a EFI reboot issue IIRC). That feature may have improved the
situation, but I am not confident at all that it fixes all systems.

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ard Biesheuvel]

On Wed, 17 Apr 2019 at 08:16, <hpa@zytor.com> wrote:
>
> On April 17, 2019 5:38:41 AM PDT, Daniel Drake <drake@endlessm.com> wrote:
> >On Wed, Apr 17, 2019 at 2:16 PM Ingo Molnar <mingo@kernel.org> wrote:
> >> Ok, so acpi_gbl_reduced_hardware is set when the ... 'reduced
> >hardware'
> >> bit is set:
> >>
> >>         acpi_gbl_reduced_hardware = FALSE;
> >>         if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) {
> >>                 acpi_gbl_reduced_hardware = TRUE;
> >>         }
> >>
> >>
> >> which is described as:
> >>
> >>  #define ACPI_FADT_HW_REDUCED        (1<<20)     /* 20: [V5] ACPI
> >hardware is not implemented (ACPI 5.0) */
> >>
> >> That seems counter-intuitive to me: if no full ACPI hardware is
> >> implemented then we should assume reduced ACPI functionality, i.e. if
> >the
> >> EFI runtime is otherwise available we should default to it.
> >
> >It's a bit confusing, but my loose understanding is that previous
> >versions of the ACPI spec required system implementors to implement
> >the whole thing; but that's increasingly impractical today, e.g. with
> >ARM systems coming along, which do not gel well with some of the
> >historical x86-rooted design aspects that spilled over into ACPI. The
> >V5 spec introduces reduced mode as an opt-in new feature, but for
> >compatibility with pre-V5 implementations it needs to consider "full
> >hardware" mode as the default.
> >
> >> Feel free to send a patch that makes EFI reboot the default one under
> >> these circumstances,
> >
> >Just to check, you mean: EFI reboot (and shutdown) become the default
> >methods when the machine is booted in EFI mode, and EFI stuff has not
> >been disabled with a kernel parameter?
> >Even when running in full hardware ACPI mode.
> >
> >Thanks
> >Daniel
>
> This, I believe, is known to not work.

It definitely used to be the case that EFI reboot was unreliable, but
I don't know the details. I have added Sai to cc, he may be able to
provide a bit more context here, since he added the code to deal with
page faults during EFI runtime service invocations (which was inspired
by a EFI reboot issue IIRC). That feature may have improved the
situation, but I am not confident at all that it fixes all systems.

RE: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Prakhya, Sai Praneeth]

> > >> That seems counter-intuitive to me: if no full ACPI hardware is
> > >> implemented then we should assume reduced ACPI functionality, i.e.
> > >> if
> > >the
> > >> EFI runtime is otherwise available we should default to it.
> > >
> > >It's a bit confusing, but my loose understanding is that previous
> > >versions of the ACPI spec required system implementors to implement
> > >the whole thing; but that's increasingly impractical today, e.g. with
> > >ARM systems coming along, which do not gel well with some of the
> > >historical x86-rooted design aspects that spilled over into ACPI. The
> > >V5 spec introduces reduced mode as an opt-in new feature, but for
> > >compatibility with pre-V5 implementations it needs to consider "full
> > >hardware" mode as the default.
> > >
> > >> Feel free to send a patch that makes EFI reboot the default one
> > >> under these circumstances,
> > >
> > >Just to check, you mean: EFI reboot (and shutdown) become the default
> > >methods when the machine is booted in EFI mode, and EFI stuff has not
> > >been disabled with a kernel parameter?
> > >Even when running in full hardware ACPI mode.
> > >
> > >Thanks
> > >Daniel
> >
> > This, I believe, is known to not work.
> 
> It definitely used to be the case that EFI reboot was unreliable, but I don't know
> the details.

Sorry! Ard.
I don't have the enough historical knowledge to state that EFI reboot is unreliable 
on most of the x86 systems but I did come across two systems that had buggy implementation 
of EFI reboot and hence I have added code to deal with EFI runtime services that cause page faults.

I will ask around internally to check if it is a good idea to make EFI reboot the default method 
when the machine is booted in EFI mode.

> I have added Sai to cc, he may be able to provide a bit more context
> here, since he added the code to deal with page faults during EFI runtime service
> invocations (which was inspired by a EFI reboot issue IIRC). That feature may
> have improved the situation, but I am not confident at all that it fixes all
> systems.

I believe, the code I added should improve the situation but I am hesitant to say that it fixes 
*all* the systems because the code addresses only one type of bug namely EFI Reboot accessing 
illegal memory and I have no idea about other buggy implementations.

Regards,
Sai

RE: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Prakhya, Sai Praneeth]

> > >> That seems counter-intuitive to me: if no full ACPI hardware is
> > >> implemented then we should assume reduced ACPI functionality, i.e.
> > >> if
> > >the
> > >> EFI runtime is otherwise available we should default to it.
> > >
> > >It's a bit confusing, but my loose understanding is that previous
> > >versions of the ACPI spec required system implementors to implement
> > >the whole thing; but that's increasingly impractical today, e.g. with
> > >ARM systems coming along, which do not gel well with some of the
> > >historical x86-rooted design aspects that spilled over into ACPI. The
> > >V5 spec introduces reduced mode as an opt-in new feature, but for
> > >compatibility with pre-V5 implementations it needs to consider "full
> > >hardware" mode as the default.
> > >
> > >> Feel free to send a patch that makes EFI reboot the default one
> > >> under these circumstances,
> > >
> > >Just to check, you mean: EFI reboot (and shutdown) become the default
> > >methods when the machine is booted in EFI mode, and EFI stuff has not
> > >been disabled with a kernel parameter?
> > >Even when running in full hardware ACPI mode.
> > >
> > >Thanks
> > >Daniel
> >
> > This, I believe, is known to not work.
> 
> It definitely used to be the case that EFI reboot was unreliable, but I don't know
> the details.

Sorry! Ard.
I don't have the enough historical knowledge to state that EFI reboot is unreliable 
on most of the x86 systems but I did come across two systems that had buggy implementation 
of EFI reboot and hence I have added code to deal with EFI runtime services that cause page faults.

I will ask around internally to check if it is a good idea to make EFI reboot the default method 
when the machine is booted in EFI mode.

> I have added Sai to cc, he may be able to provide a bit more context
> here, since he added the code to deal with page faults during EFI runtime service
> invocations (which was inspired by a EFI reboot issue IIRC). That feature may
> have improved the situation, but I am not confident at all that it fixes all
> systems.

I believe, the code I added should improve the situation but I am hesitant to say that it fixes 
*all* the systems because the code addresses only one type of bug namely EFI Reboot accessing 
illegal memory and I have no idea about other buggy implementations.

Regards,
Sai

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ingo Molnar]

* Prakhya, Sai Praneeth <sai.praneeth.prakhya@intel.com> wrote:

> I will ask around internally to check if it is a good idea to make EFI 
> reboot the default method when the machine is booted in EFI mode.

Or whether there's some robust signature that indicates "modern EFI 
system where EFI reboot is the primary method"?

Major EFI version or ACPI version or such?

Thanks,

	Ingo

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ingo Molnar]

* Prakhya, Sai Praneeth <sai.praneeth.prakhya@intel.com> wrote:

> I will ask around internally to check if it is a good idea to make EFI 
> reboot the default method when the machine is booted in EFI mode.

Or whether there's some robust signature that indicates "modern EFI 
system where EFI reboot is the primary method"?

Major EFI version or ACPI version or such?

Thanks,

	Ingo

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ard Biesheuvel]

On Wed, 17 Apr 2019 at 11:23, Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Prakhya, Sai Praneeth <sai.praneeth.prakhya@intel.com> wrote:
>
> > I will ask around internally to check if it is a good idea to make EFI
> > reboot the default method when the machine is booted in EFI mode.
>
> Or whether there's some robust signature that indicates "modern EFI
> system where EFI reboot is the primary method"?
>
> Major EFI version or ACPI version or such?
>

I am actually at Microsoft right now, and I managed to get
clarification on how Windows deals with this: Windows will attempt to
use ACPI reboot first, and will only attempt to use anything else if
that fails. EFI reset is actually its least preferred option, and so
it is highly likely that it is untested on most of the shipping x86
hardware if any of the other methods work.

So let's not touch this.

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ard Biesheuvel]

On Wed, 17 Apr 2019 at 11:23, Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Prakhya, Sai Praneeth <sai.praneeth.prakhya@intel.com> wrote:
>
> > I will ask around internally to check if it is a good idea to make EFI
> > reboot the default method when the machine is booted in EFI mode.
>
> Or whether there's some robust signature that indicates "modern EFI
> system where EFI reboot is the primary method"?
>
> Major EFI version or ACPI version or such?
>

I am actually at Microsoft right now, and I managed to get
clarification on how Windows deals with this: Windows will attempt to
use ACPI reboot first, and will only attempt to use anything else if
that fails. EFI reset is actually its least preferred option, and so
it is highly likely that it is untested on most of the shipping x86
hardware if any of the other methods work.

So let's not touch this.

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ingo Molnar]

* Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> On Wed, 17 Apr 2019 at 11:23, Ingo Molnar <mingo@kernel.org> wrote:
> >
> >
> > * Prakhya, Sai Praneeth <sai.praneeth.prakhya@intel.com> wrote:
> >
> > > I will ask around internally to check if it is a good idea to make EFI
> > > reboot the default method when the machine is booted in EFI mode.
> >
> > Or whether there's some robust signature that indicates "modern EFI
> > system where EFI reboot is the primary method"?
> >
> > Major EFI version or ACPI version or such?
> >
> 
> I am actually at Microsoft right now, and I managed to get
> clarification on how Windows deals with this: Windows will attempt to
> use ACPI reboot first, and will only attempt to use anything else if
> that fails. EFI reset is actually its least preferred option, and so
> it is highly likely that it is untested on most of the shipping x86
> hardware if any of the other methods work.
> 
> So let's not touch this.

Agreed and that's really useful information, thanks!

	Ingo

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ingo Molnar]

* Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> On Wed, 17 Apr 2019 at 11:23, Ingo Molnar <mingo@kernel.org> wrote:
> >
> >
> > * Prakhya, Sai Praneeth <sai.praneeth.prakhya@intel.com> wrote:
> >
> > > I will ask around internally to check if it is a good idea to make EFI
> > > reboot the default method when the machine is booted in EFI mode.
> >
> > Or whether there's some robust signature that indicates "modern EFI
> > system where EFI reboot is the primary method"?
> >
> > Major EFI version or ACPI version or such?
> >
> 
> I am actually at Microsoft right now, and I managed to get
> clarification on how Windows deals with this: Windows will attempt to
> use ACPI reboot first, and will only attempt to use anything else if
> that fails. EFI reset is actually its least preferred option, and so
> it is highly likely that it is untested on most of the shipping x86
> hardware if any of the other methods work.
> 
> So let's not touch this.

Agreed and that's really useful information, thanks!

	Ingo

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ingo Molnar]

* hpa@zytor.com <hpa@zytor.com> wrote:

> > Just to check, you mean: EFI reboot (and shutdown) become the default
> > methods when the machine is booted in EFI mode, and EFI stuff has not
> > been disabled with a kernel parameter?
> > Even when running in full hardware ACPI mode.

No, I still think "early" EFI is historically better with ACPI reboot.

But can we find a firmware flag perhaps that will *not* result in EFI 
reboot being turned off?

> This, I believe, is known to not work.

Yeah, I bet so.

My problem is that the code appears to have the wrong assumptions:

 /*
  * For most modern platforms the preferred method of powering off is via
  * ACPI. However, there are some that are known to require the use of
  * EFI runtime services and for which ACPI does not work at all.
  *
  * Using EFI is a last resort, to be used only if no other option
  * exists.
  */
 bool efi_reboot_required(void)
 {
         if (!acpi_gbl_reduced_hardware)
                 return false;

         efi_reboot_quirk_mode = EFI_RESET_WARM;
         return true;
 }


At minimum the comment is stale: "modern" platforms, *especially* when 
the only bootup method is EFI, as in the ACER laptop case, I think the 
preferred reboot method is absolutely an EFI reboot - and it's probably 
what Windows uses too.

The question is, is acpi_gbl_reduced_hardware false on the Acer 
TravelMate X514-51T? I think it has to be, for the quirk to make sense - 
if it's true then efi_reboot_required() would set the reboot method to 
EFI.

I.e. we seem to have a new category of systems that are advertising 
themselves as 'full ACPI compliant', which are NOT old EFI systems, but 
modern EFI systems.

Is there some good way to detect these - such as ACPI version or 
something?

Thanks,

	Ingo

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[Ingo Molnar]

* hpa@zytor.com <hpa@zytor.com> wrote:

> > Just to check, you mean: EFI reboot (and shutdown) become the default
> > methods when the machine is booted in EFI mode, and EFI stuff has not
> > been disabled with a kernel parameter?
> > Even when running in full hardware ACPI mode.

No, I still think "early" EFI is historically better with ACPI reboot.

But can we find a firmware flag perhaps that will *not* result in EFI 
reboot being turned off?

> This, I believe, is known to not work.

Yeah, I bet so.

My problem is that the code appears to have the wrong assumptions:

 /*
  * For most modern platforms the preferred method of powering off is via
  * ACPI. However, there are some that are known to require the use of
  * EFI runtime services and for which ACPI does not work at all.
  *
  * Using EFI is a last resort, to be used only if no other option
  * exists.
  */
 bool efi_reboot_required(void)
 {
         if (!acpi_gbl_reduced_hardware)
                 return false;

         efi_reboot_quirk_mode = EFI_RESET_WARM;
         return true;
 }


At minimum the comment is stale: "modern" platforms, *especially* when 
the only bootup method is EFI, as in the ACER laptop case, I think the 
preferred reboot method is absolutely an EFI reboot - and it's probably 
what Windows uses too.

The question is, is acpi_gbl_reduced_hardware false on the Acer 
TravelMate X514-51T? I think it has to be, for the quirk to make sense - 
if it's true then efi_reboot_required() would set the reboot method to 
EFI.

I.e. we seem to have a new category of systems that are advertising 
themselves as 'full ACPI compliant', which are NOT old EFI systems, but 
modern EFI systems.

Is there some good way to detect these - such as ACPI version or 
something?

Thanks,

	Ingo

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[hpa]

On April 17, 2019 9:37:29 AM PDT, Ingo Molnar <mingo@kernel.org> wrote:
>
>* hpa@zytor.com <hpa@zytor.com> wrote:
>
>> > Just to check, you mean: EFI reboot (and shutdown) become the
>default
>> > methods when the machine is booted in EFI mode, and EFI stuff has
>not
>> > been disabled with a kernel parameter?
>> > Even when running in full hardware ACPI mode.
>
>No, I still think "early" EFI is historically better with ACPI reboot.
>
>But can we find a firmware flag perhaps that will *not* result in EFI 
>reboot being turned off?
>
>> This, I believe, is known to not work.
>
>Yeah, I bet so.
>
>My problem is that the code appears to have the wrong assumptions:
>
> /*
>* For most modern platforms the preferred method of powering off is via
>  * ACPI. However, there are some that are known to require the use of
>  * EFI runtime services and for which ACPI does not work at all.
>  *
>  * Using EFI is a last resort, to be used only if no other option
>  * exists.
>  */
> bool efi_reboot_required(void)
> {
>         if (!acpi_gbl_reduced_hardware)
>                 return false;
>
>         efi_reboot_quirk_mode = EFI_RESET_WARM;
>         return true;
> }
>
>
>At minimum the comment is stale: "modern" platforms, *especially* when 
>the only bootup method is EFI, as in the ACER laptop case, I think the 
>preferred reboot method is absolutely an EFI reboot - and it's probably
>
>what Windows uses too.
>
>The question is, is acpi_gbl_reduced_hardware false on the Acer 
>TravelMate X514-51T? I think it has to be, for the quirk to make sense
>- 
>if it's true then efi_reboot_required() would set the reboot method to 
>EFI.
>
>I.e. we seem to have a new category of systems that are advertising 
>themselves as 'full ACPI compliant', which are NOT old EFI systems, but
>
>modern EFI systems.
>
>Is there some good way to detect these - such as ACPI version or 
>something?
>
>Thanks,
>
>	Ingo

That is exactly what the reduced hardware flag is supposed to indicate. As far as what Windows does, the are only two ways to find out: testing somehow, or these days Microsoft might actually answer if we ask nicely.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

[hpa]

On April 17, 2019 9:37:29 AM PDT, Ingo Molnar <mingo@kernel.org> wrote:
>
>* hpa@zytor.com <hpa@zytor.com> wrote:
>
>> > Just to check, you mean: EFI reboot (and shutdown) become the
>default
>> > methods when the machine is booted in EFI mode, and EFI stuff has
>not
>> > been disabled with a kernel parameter?
>> > Even when running in full hardware ACPI mode.
>
>No, I still think "early" EFI is historically better with ACPI reboot.
>
>But can we find a firmware flag perhaps that will *not* result in EFI 
>reboot being turned off?
>
>> This, I believe, is known to not work.
>
>Yeah, I bet so.
>
>My problem is that the code appears to have the wrong assumptions:
>
> /*
>* For most modern platforms the preferred method of powering off is via
>  * ACPI. However, there are some that are known to require the use of
>  * EFI runtime services and for which ACPI does not work at all.
>  *
>  * Using EFI is a last resort, to be used only if no other option
>  * exists.
>  */
> bool efi_reboot_required(void)
> {
>         if (!acpi_gbl_reduced_hardware)
>                 return false;
>
>         efi_reboot_quirk_mode = EFI_RESET_WARM;
>         return true;
> }
>
>
>At minimum the comment is stale: "modern" platforms, *especially* when 
>the only bootup method is EFI, as in the ACER laptop case, I think the 
>preferred reboot method is absolutely an EFI reboot - and it's probably
>
>what Windows uses too.
>
>The question is, is acpi_gbl_reduced_hardware false on the Acer 
>TravelMate X514-51T? I think it has to be, for the quirk to make sense
>- 
>if it's true then efi_reboot_required() would set the reboot method to 
>EFI.
>
>I.e. we seem to have a new category of systems that are advertising 
>themselves as 'full ACPI compliant', which are NOT old EFI systems, but
>
>modern EFI systems.
>
>Is there some good way to detect these - such as ACPI version or 
>something?
>
>Thanks,
>
>	Ingo

That is exactly what the reduced hardware flag is supposed to indicate. As far as what Windows does, the are only two ways to find out: testing somehow, or these days Microsoft might actually answer if we ask nicely.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.