Rebooting on the Dell E5420 often hangs with the keyboard method,
but is reliable via the PCI method.
Signed-off-by: Daniel J Blueman <[email protected]>
---
arch/x86/kernel/reboot.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 08c44b0..b16032d 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -411,6 +411,14 @@ static struct dmi_system_id __initdata pci_reboot_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "iMac9,1"),
},
},
+ {
+ .callback = set_pci_reboot,
+ .ident = "Dell Latitude E5420",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E5420"),
+ },
+ },
{ }
};
--
1.7.4.1
On 13 May 2011 10:44, H. Peter Anvin <[email protected]> wrote:
> Daniel J Blueman <[email protected]> wrote:
>> Rebooting on the Dell E5420 often hangs with the keyboard method, but is
>> reliable via the PCI method. Signed-off-by: Daniel J Blueman
>> <[email protected]> --- arch/x86/kernel/reboot.c | 8 ++++++++ 1 files
>> changed, 8 insertions(+), 0 deletions(-) diff --git
>> a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c index 08c44b0..b16032d
>> 100644 --- a/arch/x86/kernel/reboot.c +++ b/arch/x86/kernel/reboot.c @@
>> -411,6 +411,14 @@ static struct dmi_system_id __initdata
>> pci_reboot_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "iMac9,1"), }, }, + {
>> + .callback = set_pci_reboot, + .ident = "Dell Latitude E5420", + .matches =
>> { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME,
>> "Latitude E5420"), + }, + }, { } }; -- 1.7.4.1
> How does it work with ACPI?
All other reboot methods including ACPI are unreliable and seem to
demonstrate the same failure probability; PCI is the only reliable
method alas.
I guess the ACPI reboot method is the supported 'official' vector (and
is what Windows uses [1]), so there must be some other constraints
preventing it work as expected, unless the ACPI tables delivered to
Linux are broken, would you say?
Daniel
[1] http://comments.gmane.org/gmane.linux.kernel/1122388
--
Daniel J Blueman
Hi hpa, Thomas, Ingo,
On 13 May 2011 11:16, Daniel J Blueman <[email protected]> wrote:
> On 13 May 2011 10:44, H. Peter Anvin <[email protected]> wrote:
>> Daniel J Blueman <[email protected]> wrote:
>>> Rebooting on the Dell E5420 often hangs with the keyboard method, but is
>>> reliable via the PCI method. Signed-off-by: Daniel J Blueman
>>> <[email protected]> --- arch/x86/kernel/reboot.c | 8 ++++++++ 1 files
>>> changed, 8 insertions(+), 0 deletions(-) diff --git
>>> a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c index 08c44b0..b16032d
>>> 100644 --- a/arch/x86/kernel/reboot.c +++ b/arch/x86/kernel/reboot.c @@
>>> -411,6 +411,14 @@ static struct dmi_system_id __initdata
>>> pci_reboot_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "iMac9,1"), }, }, + {
>>> + .callback = set_pci_reboot, + .ident = "Dell Latitude E5420", + .matches =
>>> { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME,
>>> "Latitude E5420"), + }, + }, { } }; -- 1.7.4.1
>
>> How does it work with ACPI?
>
> All other reboot methods including ACPI are unreliable and seem to
> demonstrate the same failure probability; PCI is the only reliable
> method alas.
>
> I guess the ACPI reboot method is the supported 'official' vector (and
> is what Windows uses [1]), so there must be some other constraints
> preventing it work as expected, unless the ACPI tables delivered to
> Linux are broken, would you say?
>
> Daniel
>
> [1] http://comments.gmane.org/gmane.linux.kernel/1122388
Without this patch, rebooting is like Russian roulette; with quite a
few of these laptops in the field, perhaps it is better to enable the
quirk unless you think there may be an issue in the kernel preventing
correct behaviour that I could debug?
On the other hand, Dell may later fix the BIOS AML (seen with the
excellent fwts) just as the cure for cancer is found. If they do, I'll
buy whiskey too.
Thanks,
Daniel
--
Daniel J Blueman
On 05/30/2011 07:43 AM, Daniel J Blueman wrote:
>
> Without this patch, rebooting is like Russian roulette; with quite a
> few of these laptops in the field, perhaps it is better to enable the
> quirk unless you think there may be an issue in the kernel preventing
> correct behaviour that I could debug?
>
> On the other hand, Dell may later fix the BIOS AML (seen with the
> excellent fwts) just as the cure for cancer is found. If they do, I'll
> buy whiskey too.
>
Enabling the quirk is the right thing; however, if ACPI worked I'd have
preferred it since we just switched to ACPI as the default.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 31 May 2011 00:31, H. Peter Anvin <[email protected]> wrote:
> On 05/30/2011 07:43 AM, Daniel J Blueman wrote:
>>
>> Without this patch, rebooting is like Russian roulette; with quite a
>> few of these laptops in the field, perhaps it is better to enable the
>> quirk unless you think there may be an issue in the kernel preventing
>> correct behaviour that I could debug?
>>
>> On the other hand, Dell may later fix the BIOS AML (seen with the
>> excellent fwts) just as the cure for cancer is found. If they do, I'll
>> buy whiskey too.
> Enabling the quirk is the right thing; however, if ACPI worked I'd have
> preferred it since we just switched to ACPI as the default.
Indeed - the new and default ACPI reboot method works perfectly in
3.0-rc1, whereas with 2.6.39, it didn't, so no further need for this
patch then.
Thanks again,
Daniel
--
Daniel J Blueman
On 05/30/2011 09:52 AM, Daniel J Blueman wrote:
> On 31 May 2011 00:31, H. Peter Anvin <[email protected]> wrote:
>> On 05/30/2011 07:43 AM, Daniel J Blueman wrote:
>>>
>>> Without this patch, rebooting is like Russian roulette; with quite a
>>> few of these laptops in the field, perhaps it is better to enable the
>>> quirk unless you think there may be an issue in the kernel preventing
>>> correct behaviour that I could debug?
>>>
>>> On the other hand, Dell may later fix the BIOS AML (seen with the
>>> excellent fwts) just as the cure for cancer is found. If they do, I'll
>>> buy whiskey too.
>
>> Enabling the quirk is the right thing; however, if ACPI worked I'd have
>> preferred it since we just switched to ACPI as the default.
>
> Indeed - the new and default ACPI reboot method works perfectly in
> 3.0-rc1, whereas with 2.6.39, it didn't, so no further need for this
> patch then.
Oh, okay. Dropping the patch, then.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Tue, May 31, 2011 at 12:52:15AM +0800, Daniel J Blueman wrote:
> On 31 May 2011 00:31, H. Peter Anvin <[email protected]> wrote:
> > Enabling the quirk is the right thing; however, if ACPI worked I'd have
> > preferred it since we just switched to ACPI as the default.
>
> Indeed - the new and default ACPI reboot method works perfectly in
> 3.0-rc1, whereas with 2.6.39, it didn't, so no further need for this
> patch then.
It's not entirely equivalent to the way the ACPI reboot method worked in
previous kernels, so it should work better.
--
Matthew Garrett | [email protected]