linux-kernel - Re: 2.6.22-rc1-mm1 Implementing fan/thermal control in userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070528105851.GE18807@elf.ucw.cz>
Date:	Mon, 28 May 2007 12:58:51 +0200
From:	Pavel Machek <pavel@....cz>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Thomas Renninger <trenn@...e.de>, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org
Subject: Re: 2.6.22-rc1-mm1 Implementing fan/thermal control in userspace - Was: [cannot change thermal trip points]

Hi!

> > > 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.
> > 
> > ...and suggested workaround is to drive fans directly from userspace,
> > which not only violates the specs and has all the problems with
> > desynchronized state, but ALSO FAILS TO WORK IN PRACTICE.
> 
> I don't think that's obviously true. 11.3.2 of the 3.0 spec states:

> "A package consisting of references to all active cooling devices that 
> should be engaged when the associated active cooling threshold (_ACx) is 
> exceeded." 

We'd need:

a) way to tell acpi not to control fans any more

b) in kernel watchdog so that acpi starts controlling fans after oom
killer

c) way to control passive cooling from userspace.

Not something doable for 2.6.22.  


> > > 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.
> > 
> > Not sure why you try to scare people with 'hardware damage'. HP XE3
> > bios already _was_ damaging hardware (it cooked the hard drive using
> > cpu as a heater), and no acpi magic can damage correctly working
> > machine.
> 
> Given that this presumably didn't occur under Windows, I think it would
> be significantly better to figure out why and then fix that. 

It would happily occur under Windows. You just needed to load machine
in a way that cpu stayed ~80C.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/