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: 43+ 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 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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox