From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Thomas Renninger <trenn@suse.de>
Cc: "Alan Cox" <alan@lxorguk.ukuu.org.uk>,
"Adrian Schröter" <adrian@suse.de>,
"Knut Petersen" <Knut_Petersen@t-online.de>,
linux-kernel@vger.kernel.org, "Andrew Morton" <akpm@osdl.org>,
pavel@ucw.cz, lenb@kernel.org, "Zhang, Rui" <rui.zhang@intel.com>,
"Jean Delvare" <khali@linux-fr.org>,
"Alexey Starikovskiy" <aystarik@gmail.com>
Subject: Re: 2.6.22 regression: thermal trip points
Date: Thu, 2 Aug 2007 12:56:31 +0100 [thread overview]
Message-ID: <20070802115631.GA29735@srcf.ucam.org> (raw)
In-Reply-To: <1186055100.18821.494.camel@queen.suse.de>
On Thu, Aug 02, 2007 at 01:45:00PM +0200, Thomas Renninger wrote:
> On Thu, 2007-08-02 at 12:13 +0100, Matthew Garrett wrote:
> > I strongly suspect that the vast majority[1] of hardware that "needs"
> > the trip points changing works perfectly well under Windows, so it's
> > likely to be papering over bugs in the kernel. It'd be nice if we fixed
> > those rather than encouraging people to poke stuff into /proc,
> Some arguments against that:
> - You cannot tell a customer: Wait for the kernel in half a year.
> This is the time it at least needs until a laptop got sold, the
> problem is found, a patch is written and checked in and finally
> hits the distribution.
We have to do so frequently. New hardware often exposes bugs in the
kernel.
> - You can also not backport fixes as ACPI patches mostly have the
> potential to break other machines/BIOSes
> - There also exist the policy to not fix up/workaround totally broken
> AML BIOS implementations
The policy has been to attempt to be bug-compatible with Windows
whenever possible for some time now.
> - We do not need to and never will be able to copy or do the same
> Windows is doing
Given that many vendors still only test against Windows, that's exactly
what we need to do.
> > especially when doing so is guaranteed to break in really confusing ways
> > with a lot of hardware. The firmware can reset the trip points at
> > essentially arbitrary times and is well within its rights to expect the
> > OS to actually pay attention to them.
> What the hell is so wrong with:
>
> Let the user override the trip points. If he does so, ignore
> thermal trip point updates from BIOS. Don't care for hysteresis
> BIOS implementations (these are the BIOS trip point updates).
No, that's not the only reason for notifications. Alteration in hardware
state may also force a recalculation of trip point (adding a battery to
a bay rather than a DVD drive may require the platform to be kept at a
lower temperature)
> If user changes them, it's his fault, he doesn't need to...
> Make sure that trip points can only be lowered, compared to the
> initially fetched one from BIOS.
Surely people want this functionality so that they can raise trip
points?
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2007-08-02 11:56 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-02 8:40 2.6.22 regression: thermal trip points Knut Petersen
2007-08-02 8:52 ` Andrew Morton
2007-08-02 10:48 ` Andi Kleen
2007-08-02 11:00 ` Alan Cox
2007-08-02 12:05 ` Andi Kleen
2007-08-02 13:04 ` Alan Cox
2007-08-02 13:16 ` Andi Kleen
2007-08-02 15:57 ` Pavel Machek
2007-08-02 18:38 ` Andi Kleen
2007-08-02 18:40 ` Matthew Garrett
2007-08-03 11:16 ` Thomas Renninger
2007-08-03 18:59 ` Len Brown
2007-08-06 9:55 ` Pavel Machek
2007-08-07 18:58 ` Len Brown
2007-08-07 21:49 ` Pavel Machek
2007-08-13 12:30 ` Pavel Machek
2007-08-02 15:55 ` Pavel Machek
2007-08-02 9:42 ` Thomas Renninger
2007-08-02 9:45 ` Adrian Schröter
2007-08-02 9:58 ` Thomas Renninger
2007-08-02 11:02 ` Alan Cox
2007-08-02 11:13 ` Matthew Garrett
2007-08-02 11:45 ` Thomas Renninger
2007-08-02 11:56 ` Matthew Garrett [this message]
2007-08-02 12:42 ` Thomas Renninger
2007-08-02 12:55 ` Matthew Garrett
2007-08-02 11:59 ` Alan Cox
2007-08-02 11:57 ` Matthew Garrett
2007-08-02 12:06 ` Thomas Renninger
2007-08-02 12:15 ` Matthew Garrett
2007-08-02 12:35 ` Thomas Renninger
2007-08-02 12:47 ` Matthew Garrett
2007-08-02 21:56 ` Len Brown
2007-08-02 21:56 ` Len Brown
2007-08-02 11:32 ` Knut Petersen
2007-08-02 12:06 ` Andi Kleen
2007-08-02 13:06 ` Alan Cox
2007-08-02 16:07 ` Pavel Machek
2007-08-02 19:25 ` Krzysztof Halasa
2007-08-02 21:56 ` Len Brown
2007-08-02 21:56 ` Len Brown
2007-08-03 11:43 ` Renato S. Yamane
2007-08-03 18:35 ` Len Brown
2007-08-03 12:53 ` Knut Petersen
2007-08-03 18:30 ` Len Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070802115631.GA29735@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=Knut_Petersen@t-online.de \
--cc=adrian@suse.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=aystarik@gmail.com \
--cc=khali@linux-fr.org \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rui.zhang@intel.com \
--cc=trenn@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.