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.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119
Signed-off-by: Jian-Hong Pan <[email protected]>
Signed-off-by: Daniel Drake <[email protected]>
---
v2:
- Add the EFI runtime state checking in set_efi_reboot function for the
quirk.
- Refine the printing information by writing "EFI" in the string
directly.
arch/x86/kernel/reboot.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 725624b6c0c0..07111b8c41dd 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 require the "reboot=e" commandline options
+ */
+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 reboots.\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 */
--
2.20.1
Commit-ID: 5767575c1211e8958e5dd80d6542998b519c8478
Gitweb: https://git.kernel.org/tip/5767575c1211e8958e5dd80d6542998b519c8478
Author: Jian-Hong Pan <[email protected]>
AuthorDate: Fri, 12 Apr 2019 16:01:53 +0800
Committer: Ingo Molnar <[email protected]>
CommitDate: Tue, 16 Apr 2019 09:49:16 +0200
x86/reboot: 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 <[email protected]>
Signed-off-by: Daniel Drake <[email protected]>
Cc: Ard Biesheuvel <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Matt Fleming <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
[ Small clarification edits to the code and changelog. ]
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/reboot.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
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 */
Commit-ID: 0082517fa4bce073e7cf542633439f26538a14cc
Gitweb: https://git.kernel.org/tip/0082517fa4bce073e7cf542633439f26538a14cc
Author: Jian-Hong Pan <[email protected]>
AuthorDate: Fri, 12 Apr 2019 16:01:53 +0800
Committer: Ingo Molnar <[email protected]>
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 <[email protected]>
Signed-off-by: Daniel Drake <[email protected]>
Cc: Ard Biesheuvel <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Matt Fleming <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
[ Fix !CONFIG_EFI build failure, clarify the code and the changelog a bit. ]
Signed-off-by: Ingo Molnar <[email protected]>
---
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
+
extern void efi_call_virt_check_flags(unsigned long flags, const char *call);
extern unsigned long efi_call_virt_save_flags(void);
(Cc:-ed EFI and ACPI folks.)
* tip-bot for Jian-Hong Pan <[email protected]> wrote:
> Commit-ID: 0082517fa4bce073e7cf542633439f26538a14cc
> Gitweb: https://git.kernel.org/tip/0082517fa4bce073e7cf542633439f26538a14cc
> Author: Jian-Hong Pan <[email protected]>
> AuthorDate: Fri, 12 Apr 2019 16:01:53 +0800
> Committer: Ingo Molnar <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Daniel Drake <[email protected]>
> Cc: Ard Biesheuvel <[email protected]>
> Cc: Borislav Petkov <[email protected]>
> Cc: Linus Torvalds <[email protected]>
> Cc: Matt Fleming <[email protected]>
> Cc: Peter Zijlstra <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Link: http://lkml.kernel.org/r/[email protected]
> [ Fix !CONFIG_EFI build failure, clarify the code and the changelog a bit. ]
> Signed-off-by: Ingo Molnar <[email protected]>
> ---
> 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
On Tue, Apr 16, 2019 at 4:20 PM Ingo Molnar <[email protected]> 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
* Daniel Drake <[email protected]> wrote:
> On Tue, Apr 16, 2019 at 4:20 PM Ingo Molnar <[email protected]> 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
On Wed, Apr 17, 2019 at 2:16 PM Ingo Molnar <[email protected]> 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
On April 17, 2019 5:38:41 AM PDT, Daniel Drake <[email protected]> wrote:
>On Wed, Apr 17, 2019 at 2:16 PM Ingo Molnar <[email protected]> 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.
On Wed, 17 Apr 2019 at 08:16, <[email protected]> wrote:
>
> On April 17, 2019 5:38:41 AM PDT, Daniel Drake <[email protected]> wrote:
> >On Wed, Apr 17, 2019 at 2:16 PM Ingo Molnar <[email protected]> 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.
* [email protected] <[email protected]> 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
On April 17, 2019 9:37:29 AM PDT, Ingo Molnar <[email protected]> wrote:
>
>* [email protected] <[email protected]> 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.
> > >> 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
* Prakhya, Sai Praneeth <[email protected]> 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
On Wed, 17 Apr 2019 at 11:23, Ingo Molnar <[email protected]> wrote:
>
>
> * Prakhya, Sai Praneeth <[email protected]> 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.
* Ard Biesheuvel <[email protected]> wrote:
> On Wed, 17 Apr 2019 at 11:23, Ingo Molnar <[email protected]> wrote:
> >
> >
> > * Prakhya, Sai Praneeth <[email protected]> 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