On Thu, 2007-05-24 at 15:36 +0100, Matthew Garrett wrote:> On Thu, May 24, 2007 at 04:16:53PM +0200, Thomas Renninger wrote:> > > I doubt it is impossible, would you mind sharing your knowledge why you> > think it is impossible or point to some related discussion, pls.> > Because, as Len has pointed out, you end up with two different ideas > about what the trip points are - the kernel's and the hardware's. That > works fine until some event in the firmware either forcibly > resynchronises the two or makes assumptions about the spec-compliance of > the interpreter.

Not sure what exactly you'd like to do in userspace, maybe you can be abit more precise here: a) Doing whole thermal management in userspace, reading temp, writing fan and cpufreq_max_freq, shutting down machine,... b) Workaround not switching on fans by double checking fan/temperature by a userspace daemon and try to finally trigger the switch by writing to /proc/acpi/fan/state (or corresponding /sys,..)

IMO we need a some kind of fan watchdog like Henrique describedrecently, maybe this could be put in userspace not sure.Currently the fan can runs out of sync easily if the fan state ischanged behind the OSs back.

> > Yes, trip points are overridden by BIOS on HPs and what is the problem?> > The workaround won't work for them, but it still does on others> > (mainly on ThinkPads which have passive tp at about 89 C and critical on> > 91 C).> > You don't know whether the workaround will work or notHmm, I don't get the point. If it works it's great, if not you have aproblem anyway and can at least test a workaround.> until you've > performed a full audit of the platform firmware, which is going to > potentially change between BIOS versions. It's entirely legal for the > firmware to behave in this way, and even beneficial under various > circumstances.But that's exactly what all these workarounds are for. You pass them ifyou have a buggy BIOS. You wait for new BIOSes and hope that you can getrid of the workaround...

> > I could imagine an implementation for this, that e.g. critical...active9> > get module parameters. BIOS updates for trip points get ignored as soon> > as one is set and you can only decrease a value. Nothing bad can happen> > and it will make some people happy (yes it's hacky, violates the specs> > and so on..., but some more people have a working machine). Will this> > (or similar) get accepted?> > The interface would need to be more complicated than that if you wanted > to be able to implement hysteresis, and there's the potential for > hardware damage if paramaters are set inappropriately. Even then, > there's no easy way of programatically determining whether it would work > on any given hardware.

The fact that 3 people complained rather fast for a patch in rc1-mm1,looks like this is a workaround that is needed. I personally advised twoguys to use it with their ThinkPad in the summer and they are happy withit.

I'd also like to have this a bit extended: be able to just modifypassive trip point.IMO this is a very powerful feature allowing people a fanless system aslong as they have a cpufreq capable processor.

The idea having this in userspace is interesting. But as said rathercomplicated to implement. The hysteresis implementation for passivecooling works fine in kernel and is field tested, it should get used.

The problem with the ACPI spec is that it's rather complicated. This isIMO mainly for a BIOS developer point of view for what I can say.Therefore it's rather seldom picked up by BIOS vendors.However for the kernel it's easy (to fake, to do) and it's working fine,so why not making use of it?

IMO we should even provide a passive trip point (initially unused) whenthere is no one defined by BIOS.

I agree that it's hard to find the temperature to not let the fan kickin automatically. But it's really easy then for everyone to: - get a fanless system - workaround critical shutdownsand all this is safe in respect to HW damage.

IMO this is an area where we can easily behave better than M$ does.

Maybe my first mails were a bit offending, don't know, we should getthis back to an objective discussion.

I especially like to have some comments from Len, before doing any workfor nothing (or before giving up): - Would such a passive trip point override be acceptable in any way (be it in userspace, kernel space or in whatever form -> to be discussed) - Would such a workaround as I described in my mail before be acceptable - If done in userspace, how should it look like exactly