Message-Id: <200807251319.12786.trenn@suse.de>
Date:	Fri, 25 Jul 2008 13:19:11 +0200
From:	Thomas Renninger <trenn@...e.de>
To:	Len Brown <lenb@...nel.org>
Cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	"linux-acpi" <linux-acpi@...r.kernel.org>,
	"Moore, Robert" <robert.moore@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Christian Kornacker <ckornacker@...e.de>
Subject: Re: ACPI OSI disaster on latest HP laptops - critical temperature shutdown

On Friday 25 July 2008 02:04:32 Len Brown wrote:
> Thomas,
>
> re: OSI(Windows...)
>
> Linux will continue to claim OSI compatibility with Windows
> until the day when the majority of Linux systems
> have passed a Linux compatibility test rather than
> a Windows compatibility test.
And to try that out we need the acpi_osi=windows_false boot
param I sent recently. So will you accept that one?

Also we need this documented.
Will you accept a Documentation/acpi/known_osi_vendor_hooks.txt
file. Like that we get an idea of what kind of features come
in through which Windows version and more important, what kind of
ugly Windows bug workarounds exist (the latter will probably be more).

> Re: OSI(Linux)
>
> I've looked at O(100) DSDT's that look at OSI(Linux),
> and all but serveral systems from two vendors do it by mistake.
> They simply copied it from the bugged Intel reference code.
>
> OSI(Linux) will _never_ be restored to Linux, ever.
But it should not have been removed without announcing it half a
year before. It silently moved distributions and vendors into a
situation where they cannot support Linux and Windows with
the same BIOS anymore.

_OSI is mainly not used for interfaces/features in
reality (as you stated in the other mail), but to workaround very
specific Windows version bugs.

While the mainline kernel stays transparent to _OSI you
advise distributions to exactly not do that and provide e.g.
a "SLE 11" or "RHEL X" _OSI string to be able to
support the system on Linux and Windows, is that correct?
Or do you advise them to provide two separate BIOSes?
The last option, "do not implement Windows version bug
fixes" we cannot influence.
I do not see more options with the current implementation.

> re: the HP BIOS bug at hand.
>
> Linux deletes the entire thermal zone when we see this.
OpenSUSE 11.0 (2.6.25) and SLES10-SP2 (2.6.16) shut down when
the thermal driver is loaded. Probably every kernel in every
distribution out there currently is doing that.
> (arguably, we could have just disabled the CRT
> and kept the rest of the thermal zone).
> If HP cared about testing Linux on this laptop
> and had tools such that they could actually
> test Linux compatiblity, it would be pretty clear
> from user-space that their thermal zone was missing.

Len, this is not about the thermal zone, it is just
a real-world example of something I told you will happen
if Linux stays _OSI transparent with Windows.

This is about that they have to provide a BIOS hot-fix for
VISTA or VISTA SP and thus breaking Linux because there
is no way to distinguish anymore.
Windows 2007 likely will have that fixed and they provide
a sane _CRT trip point again.
This is an example of Windows versions workarounds that could
get much more complex, like initializing HW differently or
whatever.
_OSI is used by vendors as a convenient possibility to
adjust/workaround Windows bugs in their BIOSes, without
the need to pay Millions to Microsoft to fix their things.


          Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists