RE: Linux* is not supported on the Intel(R) Desktop Board DP55KG - Kernel still hangs upon reboot.
Christian Hofstaedtler
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
--
christian hofstaedtler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Justin Piszcz
On Sun, 3 Jan 2010, Christian Hofstaedtler wrote:
> 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
>
> --
> 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
For the HPET [2] issues, from what I understand it is nothing to be
worried about.
There is also a USB issue (will not work correctly with iPods/or UPS) the
only work-around there is to buy a USB card.
You can read that here:
http://communities.intel.com/message/76837#76837
Summary:
1. Use reboot append line in lilo/grub.
2. Do not worry about it (is what I am told, its normal)
3. Buy a USB PCI(-e) card if you want to use USB for anything beyond a
keyboard/mouse.
Justin.
Arjan van de Ven
Justin Piszcz <jpi...@lucidpixels.com> wrote:
>
>
> On Sun, 3 Jan 2010, Christian Hofstaedtler wrote:
>
> > 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
> >
> > --
> > 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
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
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
Christian Hofstaedtler
* Arjan van de Ven <ar...@infradead.org> [100104 00:00]:
> On Sun, 3 Jan 2010 16:40:38 -0500 (EST)
> Justin Piszcz <jpi...@lucidpixels.com> wrote:
> > On Sun, 3 Jan 2010, Christian Hofstaedtler wrote:
> > > 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
> > >
> >
> > Hello Christian,
> >
> > 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...
I guess it'd make more sense to fix it in the boards firmware, /if/ this is
possible. (I'm wondering what other OSes do in this regard.)
Here is the DMI data, anyway:
$ pwd
/sys/devices/virtual/dmi/id
$ cat board_name
DP55KG
$ cat board_vendor
Intel Corporation
$ cat board_version
AAE47218-403
$ cat product_name
$ cat sys_vendor
$ cat bios_date
10/28/2009
$ cat bios_vendor
Intel Corp.
$ cat bios_version
KGIBX10J.86A.3878.2009.1028.1049
I think I saw a patch for this floating around, but I'm not sure if this made
it into some branch.
Christian
--
christian hofstaedtler
Yuhong Bao
> 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
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.
Yuhong Bao
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141665/direct/01/--
David John
>
>> 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
>
> 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.
Christian Hofstaedtler
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 <c...@zeha.at>
---
arch/x86/kernel/reboot.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 1545bc0..b7fcf59 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -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"),
+ },
+ },
{ }
};
--
1.6.4.4
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.
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.
commit 2cb758c617833c18c533e1c4c31167e59d092235
Author: Len Brown <len....@intel.com>
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 <len....@intel.com>
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index d2d1ce8..4c53aeb 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -32,7 +32,7 @@ EXPORT_SYMBOL(pm_power_off);
static const struct desc_ptr no_idt = {};
static int reboot_mode;
-enum reboot_type reboot_type = BOOT_KBD;
+enum reboot_type reboot_type = BOOT_ACPI;
int reboot_force;
#if defined(CONFIG_X86_32) && defined(CONFIG_SMP)
H. Peter Anvin
>
> 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?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
Len Brown
> > 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".
thanks,
Len Brown, Intel Open Source Technology Center
Arjan van de Ven
"H. Peter Anvin" <h...@zytor.com> wrote:
> On 01/04/2010 09:15 AM, Len Brown wrote:
> >
> > 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?
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
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
Robert Hancock
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..
H. Peter Anvin
>
> 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..
Using a DMI cutoff year in the mid-2000's seems like it would make sense.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
Matthew Garrett
> 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
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.
--
Matthew Garrett | mj...@srcf.ucam.org
Alan Cox
> kbd reboot, it is not IBM PC compatible.
Most modern PC systems are not "IBM PC compatible" in various respects.
Defaulting to ACPI reboot is fine as it can fall back to non ACPI reboot
if there is no ACPI or ACPI doesn't provide the needed info for the
system in question
Pavel Machek
> commit 2cb758c617833c18c533e1c4c31167e59d092235
> Author: Len Brown <len....@intel.com>
> 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 <len....@intel.com>
Nak.
> @@ -32,7 +32,7 @@ EXPORT_SYMBOL(pm_power_off);
>
> static const struct desc_ptr no_idt = {};
> static int reboot_mode;
> -enum reboot_type reboot_type = BOOT_KBD;
> +enum reboot_type reboot_type = BOOT_ACPI;
> int reboot_force;
>
KBD is present on all PCs, not so with acpi. If machine can't handle
kbd reboot, it is not IBM PC compatible.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Len Brown
> 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.
Andrey Borzenkov's Toshiba Portege 4000 failed to reset with ACPI,
which is why we reverted ACPI reset as default in 2008.
Toshiba shipped the Portege 4000 in 2002 running with Windows 2000,
suggesting that Windows 2000 does not use ACPI reset -- at least
not always.
When debugging the reset failure in:
http://bugzilla.kernel.org/show_bug.cgi?id=11942
Yakui Zhao found that Windows XP writes the ACPI reset register
no matter if the FADT says it is valid or not:
http://lkml.indiana.edu/hypermail/linux/kernel/0811.0/02272.html
At the end of the day, we decided that Linux should honor that bit,
but what we learned is that Windows XP apparently uses ACPI reset by
default.
So it is likely that our DMI exception lists will be minimized
by using legacy reset for W2K generation and before; and
using ACPI reset for Windows XP generation and after.
As Robert Hancock corrected me, XP is _OSI(Windows 2001).
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...
So I'm more comfortable with DMI, and any year after
Windows 2000 is gone is probably reasonable, say 2003.
I have no doubt that no matter what we do, we will
end up with some exceptions on a blacklist, the goal
is simply to minimize those lists.
cheers,
Len Brown, Intel Open Source Technology Center
ps.
For CONFIG_ACPI_BLACKLIST_YEAR we chose not to strive
for consensus on a hard-coded year, but made it a config option.
I'm not a fan of more config options, but that one allowed
us to avoid thrashing about what year ACPI should kick in
and defer that to the distros. I think it has probably
served its purpose now, as Fedora for the last few years
has shipped with this option disabled -- enabling ACPI
on all systems that present an ACPI BIOS.
Matthew Garrett
> 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.
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.
> 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.
--
Matthew Garrett | mj...@srcf.ucam.org
Len Brown
> > 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.
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.
> > 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?
thanks,
-Len
Matthew Garrett
> I've looked at _OSI use in over a hundred DSDTs and never
> seen run-time re-configuration of reset support.
The point isn't that the firmware changes its behaviour - the point is
that the OS does.
> 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.
And if ACPI_RESET is set but untested (because 2000 never used 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?
Potentially, yes. But since such a machine would clearly expect to be
treated as "Windows Future", we'd be running it in an untested
configuration anyway.
--
Matthew Garrett | mj...@srcf.ucam.org
H. Peter Anvin
>>
>> 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?
-hpa
Robert Hancock
Well, the use of such OSI calls to indicate the BIOS supports
OS-specific features is explicitly recommended by Microsoft, i.e. see
the document linked at
http://www.microsoft.com/whdc/system/pnppwr/powermgmt/WinACPI_OSI.mspx :
"Place the routine that identifies the operating system in an _INI
method under the \_SB scope so that _OSI can run as early as possible.
This placement is important because the operating system makes features
available based on the string argument to the _OSI method."
Also from http://www.microsoft.com/taiwan/whdc/archive/BIOSAML.mspx :
"By passing the string "Windows 2001" into the _OSI method, the BIOS
indicates to the operating system that the BIOS is aware of and
compatible with the ACPI implementation and feature set of Windows XP."
They don't explicitly say how to do it, but the implication is that one
should use the sort of method I've seen in various BIOSes, where it
starts with checking _OSI on the newest Windows version and tries all
known older Windows versions, and stops when it finds the first one that
succeeds..
Len Brown
> String") as "new enough", whereas _OSI("Windows 2000") is ignored?
Sound reasoning, but I think that parsing the _OSI strings presented
by the BIOS so that the OS can deving whether it is a Windows XP
box or newer is more complicated than this problem merits.
I recommend that we compare DMI date with 2003 and go from there.
If we find that doesn't work, we can apply additional cleverness.
-Len Brown
Intel Open Source Technology Center
--
Yuhong Bao
>>> 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
>>
>> 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.
Except that they are, and what frustrates me is that some of the Linux developers involved in working around these bugs work at Intel in the first place, the same vendor that makes the motherboards with the buggy BIOSes! For example, Arjan from Intel is CCed right there!
Yuhong Bao
_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3--