Add DMI quirk for Intel DP55KG mainboard
in [Kernel]
|
Prev: Linux* is not supported on the Intel(R) Desktop Board DP55KG - Kernel still hangs upon reboot.
Next: drm: add KGDB/KDB support Add support for KDB entry/exit.
From: Matthew Garrett on 6 Jan 2010 14:40 On Wed, Jan 06, 2010 at 02:26:44PM -0500, Len Brown wrote: > 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 | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Len Brown on 6 Jan 2010 15:30 > > 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 6 Jan 2010 15:40 On Wed, Jan 06, 2010 at 03:22:30PM -0500, Len Brown wrote: > 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 | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 6 Jan 2010 16:40 On 01/06/2010 12:22 PM, Len Brown wrote: >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 6 Jan 2010 20:20
On 01/06/2010 02:22 PM, Len Brown wrote: >>> 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. > > 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? 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.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |