| 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
| ||
|
Date: Mon, 21 May 2007 14:10:48 +0200 From: Pavel Machek <pavel@....cz> To: Len Brown <lenb@...nel.org> Cc: trenn@...e.de, Chuck Ebbert <cebbert@...hat.com>, len.brown@...el.com, Maciej Rutecki <maciej.rutecki@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org, torvalds@...ux-foundation.org Subject: Re: 2.6.22-rc1-mm1 [cannot change thermal trip points] Hi! > > > No, writing trip-points is neither a fix, nor it is reasonable. > > > It is a workaround at best, and it is a dangerous and mis-leading hack. > > Yes it is a workaround for critical ACPI bugs like that or similar: > > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/22336 > > Thanks for pointing that out -- it is a great example > of how powerful mis-information can be. > > The fact that the trip-points are writable has obscured, > rather than clarified, the actual causes of the failures. > No less than 4 people in that bug report declared that > cleaning the dust out of their fan fixed the root cause. > A bunch more said that the issues went away when they > stopped using ubuntu's user-space power save daemon. > > There are a couple more with broken active fan control -- > which also gets obscured rather than clarified by > over-riding trip points. > > And finally, there are probably some with clean fans > that are working properly, but are thermally challenged > systems. I'll venture that Windows is NOT modifying or disabling > the critical trip point to work around this issue. > I'll venture that their thermal throttling is working > and ours may not be. > > perhaps it was the recently fixed mod_timer() bug in thermal.c, > or perhaps it is one that we don't know about yet... > > > It's also convenient to e.g. lower passive trip point to avoid fan > > noise. > > nope, the OS can't reliably override the processor passive trip point. > That is what _SCP and cooling_mode are for. Yes, it is reliable if you turn on thermal polling. > The reason is that the BIOS can send us a trip-point changed event at any time, > the kernel will evaluate _PSV, and wipe out the modified OS version. > > if you want to change the state of the fans, > then poke /proc/acpi/fan/ directly. Heh, you suggest this? It is even less functional than current solution -- which works okay as long as you keep thermal polling working. > > It's there for a long time, why is this "a dangerous and mis-leading > > hack." now? > > It has been dangerous and misleading since the day it went in. > If the user doesn't enable polling, then they are effectively > writing random numbers that have absolutely no effect on > the operation of the system, and hiding the numbers that > do control the operation of the system. You are misstating the situation. With thermal polling, it is pretty much okay, and it is certainly better than "ride fans manually" hack you suggested. > For folks with the reverse problem -- active cooling where the > fans kick in early than they'd like, they should just turn off > the fans via /proc/acpi/fan and not mess with the trip points at > all. No. Manually turning off fans is even worse hack. 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/
Powered by blists - more mailing lists