Linux* is not supported on the Intel(R) Desktop Board DP55KG - Kernel still hangs upon reboot.

Hi,

In regard to the DP55KG board having reboot [1] and HPET [2] issues, have you seen any fixes (from Intel?) for these problems?

I now own such a board and see the same stuff on a distro-patched 2.6.31.6.

Thanks,
Christian

[1] http://thread.gmane.org/gmane.linux.kernel/903161/
[2] http://thread.gmane.org/gmane.linux.kernel/913374

Signature · 1 line

christian hofstaedtler

Quoted 5 lines · Christian Hofstaedtler

Hi,

In regard to the DP55KG board having reboot [1] and HPET [2] issues, have you seen any fixes (from Intel?) for these problems?

Quoted 12 lines

I now own such a board and see the same stuff on a distro-patched 2.6.31.6.

Thanks,
Christian

[1] http://thread.gmane.org/gmane.linux.kernel/903161/
[2] http://thread.gmane.org/gmane.linux.kernel/913374

Signature · 1 line

christian hofstaedtler

Hello Christian,

The work around for the reboot [1] issue is append this to your kernel boot options in lilo/grub:

reboot=a

Quoted 18 lines · On Sun, 3 Jan 2010 16:40:38 -0500 (EST) Justin Piszcz…

Quoted 5 lines · Christian Hofstaedtler

Hi,

In regard to the DP55KG board having reboot [1] and HPET [2] issues, have you seen any fixes (from Intel?) for these problems?

Quoted 9 lines

I now own such a board and see the same stuff on a distro-patched 2.6.31.6.

Thanks,
Christian

[1] http://thread.gmane.org/gmane.linux.kernel/903161/
[2] http://thread.gmane.org/gmane.linux.kernel/913374

Hello Christian,

Quoted 4 lines

The work around for the reboot [1] issue is append this to your kernel boot options in lilo/grub:

reboot=a

btw this can be automated... just needs a DMI quirk. someone needs to get dmidecode output and add it to the existing table of reboot= quirks...

btw this can be automated... just needs a DMI quirk. someone needs to get dmidecode output and add it to the existing table of reboot= quirks...

--
Arjan van de Ven Intel Open Source Technology Centre

Quoted 7 lines

btw this can be automated... just needs a DMI quirk. someone needs to get dmidecode output and add it to the existing table of reboot= quirks...

Quoted 2 lines

--
Arjan van de Ven Intel Open Source Technology Centre

Note BTW that this is one of Intel's own motherboards!
In fact, I also have read about Intel's own DG45FC board having EHCI handoff trouble with Linux.

Quoted 5 lines

Quoted 5 lines

btw this can be automated... just needs a DMI quirk. someone needs to get dmidecode output and add it to the existing table of reboot= quirks...

Quoted 6 lines

Quoted 2 lines

--
Arjan van de Ven Intel Open Source Technology Centre

Note BTW that this is one of Intel's own motherboards!
In fact, I also have read about Intel's own DG45FC board having EHCI handoff trouble with Linux.

Yes, but the BIOS is probably not done by Intel.

From: Christian Hofstaedtler <[email protected]>

The Intel DP55KG mainboard cannot reboot using the keyboard controller, but ACPI works fine. Auto-select ACPI for this board.

Signed-off-by Christian Hofstaedtler <[email protected]>

---
 arch/x86/kernel/reboot.c |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

arch/x86/kernel/reboot.c +21 -0

index 1545bc0..b7fcf59 100644
@@ -427,6 +427,19 @@ static int __init set_pci_reboot(const struct dmi_system_id *d)
 	return 0;
 }
 
+/*
+ * Some Intel mainboards need reboot=a to actually reboot
+ */
+static int __init set_acpi_reboot(const struct dmi_system_id *d)
+{
+	if (reboot_type != BOOT_ACPI) {
+		reboot_type = BOOT_ACPI;
+		printk(KERN_INFO "%s hardware detected. "
+		       "Selecting ACPI-method for reboots.\n", d->ident);
+	}
+	return 0;
+}
+
 static struct dmi_system_id __initdata pci_reboot_dmi_table[] = {
 	{	/* Handle problems with rebooting on Apple MacBook5 */
 		.callback = set_pci_reboot,

@@ -452,6 +465,14 @@ static struct dmi_system_id __initdata pci_reboot_dmi_table[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "Macmini3,1"),
 		},
 	},
+	{	/* Handle problems with rebooting on Intel DP55KG mainboard */
+		.callback = set_acpi_reboot,
+		.ident = "Intel DP55KG Mainboard",
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "Intel Corporation"),
+			DMI_MATCH(DMI_BOARD_NAME, "DP55KG"),
+		},
+	},
 	{ }
 };
 

Signature · 1 line

1.6.4.4

I believe that Venki is sending a patch to make all recent motherboards use acpi reset by default; and I'd rather see that kind of patch than this one.

I've had the patch below patch in acpi-test, and thus linus-next, and -mm since Nov 2008 to change the default for
all systems w/ no issues.

Quoted 8 lines

I believe that Venki is sending a patch to make all recent motherboards use acpi reset by default; and I'd rather see that kind of patch than this one.

I've had the patch below patch in acpi-test, and thus linus-next, and -mm since Nov 2008 to change the default for
all systems w/ no issues.

Maybe I'm misremembering, but didn't we have to pull this patch after it hit mainstream the last time?

Quoted 11 lines

Quoted 8 lines

I believe that Venki is sending a patch to make all recent motherboards use acpi reset by default; and I'd rather see that kind of patch than this one.

I've had the patch below patch in acpi-test, and thus linus-next, and -mm since Nov 2008 to change the default for
all systems w/ no issues.

Maybe I'm misremembering, but didn't we have to pull this patch after it hit mainstream the last time?

c7ffa6c26277b403920e2255d10df849bd613380
"x86: default to reboot via ACPI"

set ACPI as the default in 2.6.28-rc1

8d00450d296dedec9ada38d43b83e79cca6fd5a3
Revert "x86: default to reboot via ACPI"

pulled it in v2.6.28-rc4

The original patch was justified by VMX support, and the revert was in response to Andrey Borzenkov's DMI patch to usee BIOS reset on his Toshiba Porgege 4000:

http://lkml.org/lkml/2008/10/31/242

The Toshiba Portege 4000 shipped in early 2002.

The patch to restore ACPI reset to default has been in Linux-next (with occasional drops) since the day it was dropped from 2.6.28-rc4.

As we have an existence proof, I have no doubt that using ACPI reset by default will un-earth some regressions. However, my guess is that the DMI list of old machines that will fail with ACPI reset will be smaller than by the DMI list of brand-new machines that will fail without ACPI reset.

We couuld use a DMI year cut-off as we do with ACPI itself CONFIG_ACPI_BLACKLIST_YEAR, though that doesn't work on systems that don't have DMI... If I were to propose a year, I'd say 2006 and newer, since XP was "Windows 2006".

Think you mean 2001, Vista was 2006..

I'm assuming that Windows is using ACPI reset these days, so presumably that's what we should be doing by default, and blacklisting machines where that doesn't work, rather than the reverse..

Newer hardware is assumed to no longer reboot succesfully using the keyboard controller, but needs to use ACPI instead.
To not cause problems with older hardware, only hardware with a BIOS date 2006 or newer is considered for this choice.

Also unifiy reboot_type selection code.

arch/x86/kernel/reboot.c +4 -0

+	}
+	/* 0? Likely a buggy new BIOS */
+	if (year == 0) {
+		printk(KERN_ERR "reboot: DMI BIOS year==0, "

Quoted 7 lines · Christian Hofstaedtler

Newer hardware is assumed to no longer reboot succesfully using the keyboard controller, but needs to use ACPI instead.
To not cause problems with older hardware, only hardware with a BIOS date 2006 or newer is considered for this choice.

Also unifiy reboot_type selection code.

Quoted 4 lines

arch/x86/kernel/reboot.c +4 -0

+	}
+	/* 0? Likely a buggy new BIOS */
+	if (year == 0) {
+		printk(KERN_ERR "reboot: DMI BIOS year==0, "

arch/x86/kernel/reboot.c static struct dmi_system_id __initdata pci_reboot_dmi_table[] = { · line 477

Quoted 10 lines

arch/x86/kernel/reboot.c +10 -0

+			"assuming ACPI-reboot-capable machine\n");
+		return 1;
+	}
+        /* 2006 was decided as the cut-off year. */
+	if (year < 2006) {
+		return 0;
+	}
+	return 1;
+}
+

Why assume it is a buggy *new* BIOS rather than a buggy *old* BIOS?

Quoted 2 lines

Why assume it is a buggy *new* BIOS rather than a buggy *old* BIOS?

Well, this is the same as with CONFIG_ACPI_BLACKLIST_YEAR. But yeah, I've also thought about it, but then *I* really don't know how many such broken BIOSes are there in the wild. And how many of them are new enough.

Also, I think we could push the year even more up, say, to 2009. On the assumption that such new hardware which can't do BOOT_KBD is only being produced now (late 2009). Better err on the safe side?

Also, I think we could push the year even more up, say, to 2009. On the assumption that such new hardware which can't do BOOT_KBD is only being produced now (late 2009). Better err on the safe side?

Newer hardware is assumed to no longer reboot succesfully using the keyboard controller, but needs to use ACPI instead.
To not cause problems with older hardware, only hardware with a BIOS date 2006 or newer is considered for this choice. Broken BIOSes reporting a BIOS date of 0 are not specially considered, and therefore get the KBD reboot behaviour.

Also unifiy reboot_type selection code.

Newer hardware is assumed to no longer reboot succesfully using the keyboard controller, but needs to use ACPI instead.
To not cause problems with older hardware, only hardware with a BIOS date 2006 or newer is considered for this choice. Broken BIOSes reporting a BIOS date of 0 are not specially considered, and therefore get the KBD reboot behaviour.

Also unifiy reboot_type selection code.

Signed-off-by Christian Hofstaedtler <[email protected]>

Newer hardware is assumed to no longer reboot succesfully using the keyboard controller, but needs to use ACPI instead.
To not cause problems with older hardware, only hardware with a BIOS date 2006 or newer is considered for this choice. Broken BIOSes reporting a BIOS date of 0 are not specially considered, and therefore get the KBD reboot behaviour.

Also unifiy reboot_type selection code.

Signed-off-by Christian Hofstaedtler <[email protected]>

---
 arch/x86/include/asm/emergency-restart.h |    1 +
 arch/x86/kernel/reboot.c                 |   65 ++++++++++++++++++++++++------
 2 files changed, 53 insertions(+), 13 deletions(-)

Unify x86_32-only and x86_32+x86_64 reboot quirks selection functions, so the code path is a bit easier to understand and gets a predefined execution order.

arch/x86/kernel/reboot.c +5 -1

-static struct dmi_system_id __initdata reboot_dmi_table[] = {
+/*
+ * This table only gets used on x86_32, so only use with
+ * set_bios_reboot.
+ */
+static struct dmi_system_id __initdata reboot_dmi_table_x86_32[] = {
 	{	/* Handle problems with rebooting on Dell E520's */
 		.callback = set_bios_reboot,
 		.ident = "Dell E520",

On Thu, 7 Jan 2010, Christian Hofstaedtler wrote:

Thanks for writing this patch Christian,
it is something that has been unsettled for a long time and it will be great to close the issue.

Quoted 8 lines

Newer hardware is assumed to no longer reboot succesfully using the keyboard controller, but needs to use ACPI instead.
To not cause problems with older hardware, only hardware with a BIOS date 2006 or newer is considered for this choice. Broken BIOSes reporting a BIOS date of 0 are not specially considered, and therefore get the KBD reboot behaviour.

Also unifiy reboot_type selection code.

Please split the patch in two patches:

1. cleanup w/o policy change
2. policy change w/o cleanup

better if the policy change is #2, so if we need to revert it we don't have to revert the cleanup too.

Quoted 7 lines

Signed-off-by Christian Hofstaedtler <[email protected]>

---
 arch/x86/include/asm/emergency-restart.h |    1 +
 arch/x86/kernel/reboot.c                 |   65 ++++++++++++++++++++++++------
 2 files changed, 53 insertions(+), 13 deletions(-)

arch/x86/kernel/reboot.c static struct dmi_system_id __initdata pci_reboot_dmi_table[] = { · line 464

Quoted 9 lines

arch/x86/kernel/reboot.c +9 -0

+/* See if the Hardware is new enough to support ACPI reboots. */
+static int __init reboot_acpi_likey_supported(void)
+{
+        int year;
+
+	/* Doesn't exist? Likely an old system */
+	if (!dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL)) {
+		return 0;
+	}

I think it may be better to simply return 1 in this case.

While we have seen dmi_get_date() fail in practice on "modern" machines, if CONFIG_ACPI_BLACKLIST_YEAR is set, we will already punish users by disabling ACPI and making them invoke acpi=force.

So the effect of this check is to disable ACPI-reset
on systems where the user has likely already invoked acpi=force -- which seems somewhat counter-intuitive.

arch/x86/kernel/reboot.c static struct dmi_system_id __initdata pci_reboot_dmi_table[] = { · line 468

Quoted 4 lines

arch/x86/kernel/reboot.c +4 -0

+        /* 2006 was decided as the cut-off year. */
+	if (year < 2006) {
+		return 0;
+	}

I'd rather see 2003.
If we run into trouble, it is a 1-liner to move it forward. But I think we'll probably do fine with anything newer than 2001.

thanks,
Len Brown, Intel Open Source Technolgy Center

Quoted 5 lines · Len Brown

I believe that Venki is sending a patch to make all recent motherboards use acpi reset by default; and I'd rather see that kind of patch than this one.

Quoted 4 lines

I've had the patch below patch in acpi-test, and thus linus-next, and -mm since Nov 2008 to change the default for
all systems w/ no issues.

Maybe I'm misremembering, but didn't we have to pull this patch after it hit mainstream the last time?

can we do it based on the dmi/acpi year?
Eg for all 2008 and later machines or something, while leaving the older ones as is

Quoted 1 line

can we do it based on the dmi/acpi year?

I think a saner model would be to use a similar method to Windows - that is, change behaviour based on the OSI calls that the firmware makes. If the firmware supports Vista, it's probably safe to use the ACPI reboot method.

But...
using _OSI is not "a similar method to Windows". The BIOS does not need to invoke _OSI to determine if it should expose a properly functioning ACPI reset or not. Windows XP simply demanded it, and the box failed WHQL if it did not work.

Further, there is no _guarantee_ that a BIOS will invoke _OSI at all, let alone a _rule_ for what _OSI() strings the BIOS will choose to query to trigger its Windows specific compatibility hooks -- even if common practice is for a desktop BIOS to evaluate _OSI strings in sequence up throught he most recent version of Windows it knows about...

Quoted 5 lines

using _OSI is not "a similar method to Windows". The BIOS does not need to invoke _OSI to determine if it should expose a properly functioning ACPI reset or not. Windows XP simply demanded it, and the box failed WHQL if it did not work.

http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/WinACPI_OSI.docx
was what I was referring to:

"By using the _OSI method, ASL writers can easily determine the version of the ACPI interfaces that the host operating system supports. This versioning method provides a solution for creating firmware that can support future operating systems and enable the operating system to change behavior based on the requested interface levels."

We know that this is used for deciding whether or not to block system IO accesses, but it wouldn't surprise me if it's also used to determine other functionality like whether or not the ACPI interface is used for rebooting.

Quoted 7 lines

Further, there is no _guarantee_ that a BIOS will invoke _OSI at all, let alone a _rule_ for what _OSI() strings the BIOS will choose to query to trigger its Windows specific compatibility hooks -- even if common practice is for a desktop BIOS to evaluate _OSI strings in sequence up throught he most recent version of Windows it knows about...

It's effectively guaranteed if the system is validated with Windows.

I've looked at _OSI use in over a hundred DSDTs and never seen run-time re-configuration of reset support.

I do not think the BIOS has a run-time decision to make here. If a box is designed to support Windows XP and newer, it is likely that ACPI_RESET is simply valid and XP blindly uses it. If reset fails, the box doesn't pass WHQL and the box is fixed. If W2K is run on that box, ACPI_RESET is still valid, just that W2K chooses to not write to it.

We can't rely on blind use of _OSI to mean "new enough", since it was supported back in W2K era. That means we have to parse the OSI strings. But what happens when a BIOS writer decides to evaluate _OSI("Windows Future") without evaluating any of the old strings we know about? We would disable ACPI reset on such a future box?

Quoted 2 lines

It's effectively guaranteed if the system is validated with Windows.

today's common industry practice != future guarantee

We can't rely on blind use of _OSI to mean "new enough", since it was supported back in W2K era. That means we have to parse the OSI strings. But what happens when a BIOS writer decides to evaluate _OSI("Windows Future") without evaluating any of the old strings we know about? We would disable ACPI reset on such a future box?

What about using _OSI() with a *blacklist*, i.e. treat _OSI("Unknown String") as "new enough", whereas _OSI("Windows 2000") is ignored?

Quoted 15 lines

Quoted 5 lines

using _OSI is not "a similar method to Windows". The BIOS does not need to invoke _OSI to determine if it should expose a properly functioning ACPI reset or not. Windows XP simply demanded it, and the box failed WHQL if it did not work.

http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/WinACPI_OSI.docx
was what I was referring to:

"By using the _OSI method, ASL writers can easily determine the version of the ACPI interfaces that the host operating system supports. This versioning method provides a solution for creating firmware that can support future operating systems and enable the operating system to change behavior based on the requested interface levels."

Quoted 4 lines

We know that this is used for deciding whether or not to block system IO accesses, but it wouldn't surprise me if it's also used to determine other functionality like whether or not the ACPI interface is used for rebooting.

I've looked at _OSI use in over a hundred DSDTs and never seen run-time re-configuration of reset support.

I do not think the BIOS has a run-time decision to make here. If a box is designed to support Windows XP and newer, it is likely that ACPI_RESET is simply valid and XP blindly uses it. If reset fails, the box doesn't pass WHQL and the box is fixed. If W2K is run on that box, ACPI_RESET is still valid, just that W2K chooses to not write to it.

Quoted 9 lines

Quoted 7 lines

Further, there is no _guarantee_ that a BIOS will invoke _OSI at all, let alone a _rule_ for what _OSI() strings the BIOS will choose to query to trigger its Windows specific compatibility hooks -- even if common practice is for a desktop BIOS to evaluate _OSI strings in sequence up throught he most recent version of Windows it knows about...

It's effectively guaranteed if the system is validated with Windows.

today's common industry practice != future guarantee

We can't rely on blind use of _OSI to mean "new enough", since it was supported back in W2K era. That means we have to parse the OSI strings. But what happens when a BIOS writer decides to evaluate _OSI("Windows Future") without evaluating any of the old strings we know about? We would disable ACPI reset on such a future box?

commit 2cb758c617833c18c533e1c4c31167e59d092235

Author: Len Brown <[email protected]>
Date:   Thu Nov 6 22:43:21 2008 -0500

x86, ACPI: default to reboot via ACPI (again)

We've run into systems which do not reboot properly without using the ACPI reset mechanism. So lets try this in linux-next for a while and see how many existing machines stop rebooting because they can't handle ACPI reboot.

Signed-off-by Len Brown <[email protected]>

KBD is present on all PCs, not so with acpi. If machine can't handle kbd reboot, it is not IBM PC compatible.