Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753840AbYGYLTw (ORCPT ); Fri, 25 Jul 2008 07:19:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754618AbYGYLTS (ORCPT ); Fri, 25 Jul 2008 07:19:18 -0400 Received: from cantor.suse.de ([195.135.220.2]:40468 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754080AbYGYLTQ (ORCPT ); Fri, 25 Jul 2008 07:19:16 -0400 From: Thomas Renninger Organization: SUSE Linux - Novell To: Len Brown Subject: Re: ACPI OSI disaster on latest HP laptops - critical temperature shutdown Date: Fri, 25 Jul 2008 13:19:11 +0200 User-Agent: KMail/1.9.9 Cc: Arjan van de Ven , "linux-acpi" , "Moore, Robert" , Linux Kernel Mailing List , Andi Kleen , Christian Kornacker References: <200807241727.41715.trenn@suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807251319.12786.trenn@suse.de> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3244 Lines: 79 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/