lkml.org 
[lkml]   [2008]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)
On Tue, 7 Oct 2008, Andi Kleen wrote:

> > Hmm, working around Linux problems in the BIOS is a new and truly odd
> > concept to me.
>
> Except perhaps for the cheapest consumer parts and many laptops Linux is
> definitely on the radar now for many BIOS developers.

That's not my point.

> > It's not that we are unresponsive or do not take
> > responsibility for our bugs, is it?
>
> These workarounds are not for mainline kernels but for specific
> distribution releases (as in "fixes SLES/RHEL x.y" instead of
> "fixes 2.6.xy")

I am happy to fix any bugs I introduced myself (as much as one can be
happy about mistakes once they have discovered they made them that is) and
certainly have a look into other Linux bugs by request of any vendor of a
Linux distribution made on behalf of a hardware manufacturer.

OTOH I do not feel responsible even a little bit for someone else's bugs
like those of BIOS developers. Though I will certainly consider providing
them with any assistance needed to get things related to Linux resolved in
a best possible way if they ask nicely.

> Even when the distributors update their kernels the old releases
> do not go away are still used and the workarounds get in.

It is not unreasonable to require a version of a distribution that is
current at the time a piece of hardware has been released. Hardware
vendors only support certain versions of certain operating systems if any
at all and Linux makes no difference here. Except from the bureaucracy
needed, or actually the lack of, to get something we have done wrong
rectified. The community may support anything beyond that of course, like
running Linux 1.2.13 on that brand new server.

> > Well, perhaps, but the thermal trip point phenomenon seems unique to this
> > family of systems. The other aspects of the problem do not really matter
> > anymore as we seem to have addressed them robustly enough now.
>
> When you need DMI entries you clearly haven't.

You can't just break a piece of hardware randomly (setting the thermal
trip points based on an interrupt mask of an I/O APIC input is certainly
beyond the ACPI spec), hide its documentation and still demand it to be
supported correctly, possibly hurting all the other good equipment.
Sorry -- you have to draw a line somewhere. Others seem to agree as
otherwise we wouldn't have DMI matching in the first place. The same
applies to PCI quirks. And command line arguments to activate workarounds
are worse yet, but we do have them too. We wouldn't need any of these if
all the hardware was built to the relevant specs.

Maciej


\
 
 \ /
  Last update: 2008-10-07 03:37    [W:0.110 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site