Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thu 2007-05-31 22:46:11, Len Brown wrote: > On Monday 21 May 2007 08:11, Pavel Machek wrote: > > On Thu 2007-05-17 18:42:43, Len Brown wrote: > > > > Something similar happened to me on XE3, yes. > > > > > > > > (Actual values were different; BIOS specified critical temperature at > > > > cca 95C, but hw killed the power at cca 83C. Setting critical trip > > > > point at 80C made the problem go away.) > > > > > > Great, please file a bug and include the acpidump from the XE3 > > > and we'll fix it, rather than supporting a bogus (manual) workaround for > > > it. > > > > It is few years since I do not have that XE3 machine. > > > > > Of course if your system is running at 80*C and the hardware shuts > > > off at 83*C, you may have a broken fan, or one clogged with dust... > > > > It _did_ have broken fan. It also had broken trip points. > > Thanks for clarifying this, Pavel. > If you come upon an XE3 where Linux-2.6.22 doesn't work as well > as Windows, please let me know. "work as well as windows" is not good enough goal as far as I'm concerned. Please don't break working setups. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Mon 2007-06-04 11:02:01, Stefan Seyfried wrote: > On Thu, May 17, 2007 at 06:35:48PM -0400, Len Brown wrote: > > > Yes, SuSE enables polling mode by default, but that is just > > distro specific "value add" that should eventually be fixed. > > I will do that for openSUSE FACTORY. Well, I still believe right solution is to enable polling mode as soon as trip points are written (and ignoring bios updates from then on). That gets trip point writing into functional state. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thu, May 17, 2007 at 06:35:48PM -0400, Len Brown wrote: > Yes, SuSE enables polling mode by default, but that is just > distro specific "value add" that should eventually be fixed. I will do that for openSUSE FACTORY. -- Stefan Seyfried QA / R Team Mobile Devices| "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Tue, May 22, 2007 at 11:06:36AM +0200, Pavel Machek wrote: > We need to ignore trip point updates from BIOS, and we need to poll > thermals when use overrides trip points. That's expected. Plus I've > yet to see platform actually updating the trip points. Thinkpad 600, whenever a trip point is crossed, all trip points are updated. I think they implemented hysteresis that way. ISTR that hp nx5000 did something similar, but i might be wrong on this one. -- Stefan Seyfried QA / R Team Mobile Devices| "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thu, May 17, 2007 at 06:35:48PM -0400, Len Brown wrote: Yes, SuSE enables polling mode by default, but that is just distro specific value add that should eventually be fixed. I will do that for openSUSE FACTORY. -- Stefan Seyfried QA / RD Team Mobile Devices| Any ideas, John? SUSE LINUX Products GmbH, Nürnberg | Well, surrounding them's out. This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Tue, May 22, 2007 at 11:06:36AM +0200, Pavel Machek wrote: We need to ignore trip point updates from BIOS, and we need to poll thermals when use overrides trip points. That's expected. Plus I've yet to see platform actually updating the trip points. Thinkpad 600, whenever a trip point is crossed, all trip points are updated. I think they implemented hysteresis that way. ISTR that hp nx5000 did something similar, but i might be wrong on this one. -- Stefan Seyfried QA / RD Team Mobile Devices| Any ideas, John? SUSE LINUX Products GmbH, Nürnberg | Well, surrounding them's out. This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Mon 2007-06-04 11:02:01, Stefan Seyfried wrote: On Thu, May 17, 2007 at 06:35:48PM -0400, Len Brown wrote: Yes, SuSE enables polling mode by default, but that is just distro specific value add that should eventually be fixed. I will do that for openSUSE FACTORY. Well, I still believe right solution is to enable polling mode as soon as trip points are written (and ignoring bios updates from then on). That gets trip point writing into functional state. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thu 2007-05-31 22:46:11, Len Brown wrote: On Monday 21 May 2007 08:11, Pavel Machek wrote: On Thu 2007-05-17 18:42:43, Len Brown wrote: Something similar happened to me on XE3, yes. (Actual values were different; BIOS specified critical temperature at cca 95C, but hw killed the power at cca 83C. Setting critical trip point at 80C made the problem go away.) Great, please file a bug and include the acpidump from the XE3 and we'll fix it, rather than supporting a bogus (manual) workaround for it. It is few years since I do not have that XE3 machine. Of course if your system is running at 80*C and the hardware shuts off at 83*C, you may have a broken fan, or one clogged with dust... It _did_ have broken fan. It also had broken trip points. Thanks for clarifying this, Pavel. If you come upon an XE3 where Linux-2.6.22 doesn't work as well as Windows, please let me know. work as well as windows is not good enough goal as far as I'm concerned. Please don't break working setups. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Monday 21 May 2007 08:11, Pavel Machek wrote: > On Thu 2007-05-17 18:42:43, Len Brown wrote: > > > Something similar happened to me on XE3, yes. > > > > > > (Actual values were different; BIOS specified critical temperature at > > > cca 95C, but hw killed the power at cca 83C. Setting critical trip > > > point at 80C made the problem go away.) > > > > Great, please file a bug and include the acpidump from the XE3 > > and we'll fix it, rather than supporting a bogus (manual) workaround for it. > > It is few years since I do not have that XE3 machine. > > > Of course if your system is running at 80*C and the hardware shuts > > off at 83*C, you may have a broken fan, or one clogged with dust... > > It _did_ have broken fan. It also had broken trip points. Thanks for clarifying this, Pavel. If you come upon an XE3 where Linux-2.6.22 doesn't work as well as Windows, please let me know. Given that the justification for this ill-conceived workaround seems to have diminished to the memory of broken hardware, it is clear that we should stay the course of removing it so that it doesn't further confuse future users. If SuSE violently disagrees with me, you are certainly empowered to restore the workaround in your distribution staring at 2.6.22 as part of your value add. However, given its history of confusing users, it seems that it might increase your support burden rather than decrease it. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Monday 21 May 2007 08:11, Pavel Machek wrote: On Thu 2007-05-17 18:42:43, Len Brown wrote: Something similar happened to me on XE3, yes. (Actual values were different; BIOS specified critical temperature at cca 95C, but hw killed the power at cca 83C. Setting critical trip point at 80C made the problem go away.) Great, please file a bug and include the acpidump from the XE3 and we'll fix it, rather than supporting a bogus (manual) workaround for it. It is few years since I do not have that XE3 machine. Of course if your system is running at 80*C and the hardware shuts off at 83*C, you may have a broken fan, or one clogged with dust... It _did_ have broken fan. It also had broken trip points. Thanks for clarifying this, Pavel. If you come upon an XE3 where Linux-2.6.22 doesn't work as well as Windows, please let me know. Given that the justification for this ill-conceived workaround seems to have diminished to the memory of broken hardware, it is clear that we should stay the course of removing it so that it doesn't further confuse future users. If SuSE violently disagrees with me, you are certainly empowered to restore the workaround in your distribution staring at 2.6.22 as part of your value add. However, given its history of confusing users, it seems that it might increase your support burden rather than decrease it. -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Matthew Garrett pisze: . > > Try any recent HP bios. > Yes... hp nx 6310, bios version: F.06. cpufreq works, MFCG Bios Error in dmesg (PCI: BIOS Bug: MCFG area at f800 is not E820-reserved) F.08. like above + cpufreq broken F.09 Remove this errors, but problem with reboot (too long time - remove psmouse module doesn't help) - some people reports it (i didn't test it) F.0B suspend to ram broken, after suspend to disk keyboard doesn't work F.0D I don't have the heart test it... -- Maciej Rutecki http://www.maciek.unixy.pl smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Le 05/22/2007 11:16 AM, Matthew Garrett a déclaré : > On Tue, May 22, 2007 at 11:06:36AM +0200, Pavel Machek wrote: > >> We need to ignore trip point updates from BIOS, and we need to poll >> thermals when use overrides trip points. That's expected. Plus I've >> yet to see platform actually updating the trip points. > > Try any recent HP bios. > man cron... ;-) -- ~~ |Oo| La banquise fond !!! Adoptez un pingouin... /|\/|\ |__|=> http://doc.ubuntu-fr.org/ ^__^ ~~~| |~~~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Tue, May 22, 2007 at 11:06:36AM +0200, Pavel Machek wrote: > We need to ignore trip point updates from BIOS, and we need to poll > thermals when use overrides trip points. That's expected. Plus I've > yet to see platform actually updating the trip points. Try any recent HP bios. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Hi! > > > So don't do it badly. The advantage of doing so is that you can make it > > > work properly, which you can't by putting it in the kernel. > > > > You want stuff like critical shutdowns to work even if userspace is > > dead. > > I don't think anyone suggested putting the critical shutdown control in > userspace. The kernel already handles that fine. No it does not. That is what this thread is about. (On old xe3, critical trip point set by BIOS is ~95C, but machine dies by hw safeguard at ~83C. Workaround is to lower critical trip point to 80C or so. Len broke this.) > Imagine the following situation: > > 1) Platform sets critical shutdown trip point to 85C > 2) Userspace sets critical shutdown trip point to 95C > 3) Temperature reaches 90C > 4) Platform forces reevaluation of trip points > 5) Entire invasion fleet is lost > > How do you avoid that? Disable the ability for the platform to set trip > points? You're breaking the spec and potentially causing hardware We need to ignore trip point updates from BIOS, and we need to poll thermals when use overrides trip points. That's expected. Plus I've yet to see platform actually updating the trip points. Speaking about hw damage... The broken BIOS on xe3 definitely caused damage to its harddrive, so... we are preventing hw damage here. (Plus, Len's patch broke user-kernel in stable series, without warning). 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Hi! So don't do it badly. The advantage of doing so is that you can make it work properly, which you can't by putting it in the kernel. You want stuff like critical shutdowns to work even if userspace is dead. I don't think anyone suggested putting the critical shutdown control in userspace. The kernel already handles that fine. No it does not. That is what this thread is about. (On old xe3, critical trip point set by BIOS is ~95C, but machine dies by hw safeguard at ~83C. Workaround is to lower critical trip point to 80C or so. Len broke this.) Imagine the following situation: 1) Platform sets critical shutdown trip point to 85C 2) Userspace sets critical shutdown trip point to 95C 3) Temperature reaches 90C 4) Platform forces reevaluation of trip points 5) Entire invasion fleet is lost How do you avoid that? Disable the ability for the platform to set trip points? You're breaking the spec and potentially causing hardware We need to ignore trip point updates from BIOS, and we need to poll thermals when use overrides trip points. That's expected. Plus I've yet to see platform actually updating the trip points. Speaking about hw damage... The broken BIOS on xe3 definitely caused damage to its harddrive, so... we are preventing hw damage here. (Plus, Len's patch broke user-kernel in stable series, without warning). 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Tue, May 22, 2007 at 11:06:36AM +0200, Pavel Machek wrote: We need to ignore trip point updates from BIOS, and we need to poll thermals when use overrides trip points. That's expected. Plus I've yet to see platform actually updating the trip points. Try any recent HP bios. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Le 05/22/2007 11:16 AM, Matthew Garrett a déclaré : On Tue, May 22, 2007 at 11:06:36AM +0200, Pavel Machek wrote: We need to ignore trip point updates from BIOS, and we need to poll thermals when use overrides trip points. That's expected. Plus I've yet to see platform actually updating the trip points. Try any recent HP bios. man cron... ;-) -- ~~ |Oo| La banquise fond !!! Adoptez un pingouin... /|\/|\ |__|= http://doc.ubuntu-fr.org/ ^__^ ~~~| |~~~ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Matthew Garrett pisze: . Try any recent HP bios. Yes... hp nx 6310, bios version: F.06. cpufreq works, MFCG Bios Error in dmesg (PCI: BIOS Bug: MCFG area at f800 is not E820-reserved) F.08. like above + cpufreq broken F.09 Remove this errors, but problem with reboot (too long time - remove psmouse module doesn't help) - some people reports it (i didn't test it) F.0B suspend to ram broken, after suspend to disk keyboard doesn't work F.0D I don't have the heart test it... -- Maciej Rutecki http://www.maciek.unixy.pl smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Tue, May 22, 2007 at 12:42:00AM +0200, Pavel Machek wrote: > On Mon 2007-05-21 14:45:53, Matthew Garrett wrote: > > So don't do it badly. The advantage of doing so is that you can make it > > work properly, which you can't by putting it in the kernel. > > You want stuff like critical shutdowns to work even if userspace is > dead. I don't think anyone suggested putting the critical shutdown control in userspace. The kernel already handles that fine. > I do not think you can control passive cooling adequately from > userspace, and you can certainly not prevent kernel from slowing > machine down too soon. Given the choice between something impossible and something difficult, I'm inclined towards picking the difficult one. > Plus, this is actually nasty user-visible change, and a regression > from 2.6.21. I am not sure why we are even debating this; user-kernel > interface changed without warning. Patch should be simply reverted. In http://lkml.org/lkml/2007/1/27/93 you were more than happy to break an interface even though it could be fixed in a (ugly) way that made it work again. Here, there's no way to fix this properly - the platform will quite happily do things based on what it believes the trip points should be, and one of those things may be to alter the trip points. Imagine the following situation: 1) Platform sets critical shutdown trip point to 85C 2) Userspace sets critical shutdown trip point to 95C 3) Temperature reaches 90C 4) Platform forces reevaluation of trip points 5) Entire invasion fleet is lost How do you avoid that? Disable the ability for the platform to set trip points? You're breaking the spec and potentially causing hardware damage. If you have specific hardware that requires specific spec breakage, then a better approach would probably be to quirk the kernel to rectify it. On the other hand, if it works with the Other Leading OS, we ought to be able to just fix the problem properly. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Mon 2007-05-21 14:45:53, Matthew Garrett wrote: > On Mon, May 21, 2007 at 03:40:46PM +0200, Pavel Machek wrote: > > On Mon 2007-05-21 14:36:08, Matthew Garrett wrote: > > > On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote: > > > > Significantly more correct? It forces you to do all the thermal > > > > management in userspace! > > > > > > Why's that a problem? > > > > Duplicating all the kernel logic in userspace, badly? > > So don't do it badly. The advantage of doing so is that you can make it > work properly, which you can't by putting it in the kernel. You want stuff like critical shutdowns to work even if userspace is dead. I do not think you can control passive cooling adequately from userspace, and you can certainly not prevent kernel from slowing machine down too soon. Plus, this is actually nasty user-visible change, and a regression from 2.6.21. I am not sure why we are even debating this; user-kernel interface changed without warning. Patch should be simply reverted. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Mon, May 21, 2007 at 03:40:46PM +0200, Pavel Machek wrote: > On Mon 2007-05-21 14:36:08, Matthew Garrett wrote: > > On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote: > > > Significantly more correct? It forces you to do all the thermal > > > management in userspace! > > > > Why's that a problem? > > Duplicating all the kernel logic in userspace, badly? So don't do it badly. The advantage of doing so is that you can make it work properly, which you can't by putting it in the kernel. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Mon 2007-05-21 14:36:08, Matthew Garrett wrote: > On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote: > > > > No. Manually turning off fans is even worse hack. > > > > > > It's significantly more correct. > > > > Significantly more correct? It forces you to do all the thermal > > management in userspace! > > Why's that a problem? Duplicating all the kernel logic in userspace, badly? 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote: > > > No. Manually turning off fans is even worse hack. > > > > It's significantly more correct. > > Significantly more correct? It forces you to do all the thermal > management in userspace! Why's that a problem? Overriding the hardware policy has to be done somewhere, and doing it in userspace is no more dangerous than kernelspace. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Mon, May 21, 2007 at 02:10:48PM +0200, Pavel Machek wrote: > > 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. As Len says, the system can force a reevaluation of the trip points at any time which will wipe out the local settings. Either you ignore the spec and the notifications (potentially risking misbehaving hardware) or you end up in a perpetual race. > > 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. If there are problems with the fan behaviour, why don't we fix them? > > 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. It's significantly more correct. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Hi! > > > 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. > > It's significantly more correct. Significantly more correct? It forces you to do all the thermal management in userspace! 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thu 2007-05-17 18:42:43, Len Brown wrote: > > Something similar happened to me on XE3, yes. > > > > (Actual values were different; BIOS specified critical temperature at > > cca 95C, but hw killed the power at cca 83C. Setting critical trip > > point at 80C made the problem go away.) > > Great, please file a bug and include the acpidump from the XE3 > and we'll fix it, rather than supporting a bogus (manual) workaround for it. It is few years since I do not have that XE3 machine. > Of course if your system is running at 80*C and the hardware shuts > off at 83*C, you may have a broken fan, or one clogged with dust... It _did_ have broken fan. It also had broken trip points. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Sun, 2007-05-20 at 23:50 -0400, Len Brown wrote: > On Saturday 19 May 2007 15:56, Thomas Renninger wrote: > > On Thu, 2007-05-17 at 15:17 -0400, Len Brown wrote: > > > On Thursday 17 May 2007 05:23, Pavel Machek wrote: > > > > > > > > ACPI: thermal trip points are read-only > > > > > > > > What was the rationale? Can we get this one reverted? > > > > > > > > Some machines (HP omnibook xe3) have broken trip points -- too high -- > > > > so machine will overheat and trigger hw shutdown before starting > > > > passive cooling. > > > > > > > > That's really broken, and write to trip points is reasonable way to > > > > 'fix' that. (I'd understand if you only ever let trip points to > > > > decrease... but otoh root should be able to shoot himself) > > > > > > 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... > Whatever it was, it's in a final Ubuntu dist and the trip point interface could help some people to still be able to use it. ACPI is very machine specific. 100 machines may work well and QA might oversee the 100 and first where critical shutdowns or whatever happens. Such workarounds are really helpful then. Same for ignore _PPC and thermal polling (the latter is always on in our distro, I bet a lot machine would break if disabling it and just ripping out the ability to set it, is really not a solution). One big challenge in the ACPI subsystem (kernel or userspace) is to find out BIOS implemenations that are at the limit of specs or which violate the specs and try to workaround them. We are not in the position of M$ (at least in the desktop/laptop segment) yet. BIOS developers won't follow our implementations and IMO we should go the other way and provide more workarounds. If nobody needs them, the better. > > 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. > > 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. > This will have effect until the next trip point > changes its state. > > > Some people are used to it, I already wanted to write a little userspace > > prog to use them as it is really easy to fake cooling_mode (trip points > > are modified by BIOS) and eliminate fan noise and other things by e.g. > > reducing passsive or whatever trip point. > > please save this effort for a non-ACPI system. > > > This is at least a major sysfs interface change, has this been discussed > > somewhere before or declared deprecated? > > it went out on linux-acpi, but I don't recall any discussion about it. > > > 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. > > > I'd suggest to revert this and I can come with something like "only > > allow lower values > > than BIOS provides" patch if the current implementation is considered > > dangerous. > > That simply will not address the issue. > Indeed, all the entries in the ubuntu bug report are about hitting > the critical temperature and having a critical shutdown when > it isn't wanted. These people want to RAISE the critical shutdown > trip-point. Their cooling problems must be fixed -- raising critical > trip points causes
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Sun, 2007-05-20 at 23:50 -0400, Len Brown wrote: On Saturday 19 May 2007 15:56, Thomas Renninger wrote: On Thu, 2007-05-17 at 15:17 -0400, Len Brown wrote: On Thursday 17 May 2007 05:23, Pavel Machek wrote: ACPI: thermal trip points are read-only What was the rationale? Can we get this one reverted? Some machines (HP omnibook xe3) have broken trip points -- too high -- so machine will overheat and trigger hw shutdown before starting passive cooling. That's really broken, and write to trip points is reasonable way to 'fix' that. (I'd understand if you only ever let trip points to decrease... but otoh root should be able to shoot himself) 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... Whatever it was, it's in a final Ubuntu dist and the trip point interface could help some people to still be able to use it. ACPI is very machine specific. 100 machines may work well and QA might oversee the 100 and first where critical shutdowns or whatever happens. Such workarounds are really helpful then. Same for ignore _PPC and thermal polling (the latter is always on in our distro, I bet a lot machine would break if disabling it and just ripping out the ability to set it, is really not a solution). One big challenge in the ACPI subsystem (kernel or userspace) is to find out BIOS implemenations that are at the limit of specs or which violate the specs and try to workaround them. We are not in the position of M$ (at least in the desktop/laptop segment) yet. BIOS developers won't follow our implementations and IMO we should go the other way and provide more workarounds. If nobody needs them, the better. 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. 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. This will have effect until the next trip point changes its state. Some people are used to it, I already wanted to write a little userspace prog to use them as it is really easy to fake cooling_mode (trip points are modified by BIOS) and eliminate fan noise and other things by e.g. reducing passsive or whatever trip point. please save this effort for a non-ACPI system. This is at least a major sysfs interface change, has this been discussed somewhere before or declared deprecated? it went out on linux-acpi, but I don't recall any discussion about it. 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. I'd suggest to revert this and I can come with something like only allow lower values than BIOS provides patch if the current implementation is considered dangerous. That simply will not address the issue. Indeed, all the entries in the ubuntu bug report are about hitting the critical temperature and having a critical shutdown when it isn't wanted. These people want to RAISE the critical shutdown trip-point. Their cooling problems must be fixed -- raising critical trip points causes them instead to be ignored. For folks with the reverse problem -- active cooling where the fans kick in early than they'd like, they should just turn off
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thu 2007-05-17 18:42:43, Len Brown wrote: Something similar happened to me on XE3, yes. (Actual values were different; BIOS specified critical temperature at cca 95C, but hw killed the power at cca 83C. Setting critical trip point at 80C made the problem go away.) Great, please file a bug and include the acpidump from the XE3 and we'll fix it, rather than supporting a bogus (manual) workaround for it. It is few years since I do not have that XE3 machine. Of course if your system is running at 80*C and the hardware shuts off at 83*C, you may have a broken fan, or one clogged with dust... It _did_ have broken fan. It also had broken trip points. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Mon, May 21, 2007 at 02:10:48PM +0200, Pavel Machek wrote: 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. As Len says, the system can force a reevaluation of the trip points at any time which will wipe out the local settings. Either you ignore the spec and the notifications (potentially risking misbehaving hardware) or you end up in a perpetual race. 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. If there are problems with the fan behaviour, why don't we fix them? 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. It's significantly more correct. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Hi! 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. It's significantly more correct. Significantly more correct? It forces you to do all the thermal management in userspace! 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote: No. Manually turning off fans is even worse hack. It's significantly more correct. Significantly more correct? It forces you to do all the thermal management in userspace! Why's that a problem? Overriding the hardware policy has to be done somewhere, and doing it in userspace is no more dangerous than kernelspace. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Mon 2007-05-21 14:36:08, Matthew Garrett wrote: On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote: No. Manually turning off fans is even worse hack. It's significantly more correct. Significantly more correct? It forces you to do all the thermal management in userspace! Why's that a problem? Duplicating all the kernel logic in userspace, badly? 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Mon, May 21, 2007 at 03:40:46PM +0200, Pavel Machek wrote: On Mon 2007-05-21 14:36:08, Matthew Garrett wrote: On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote: Significantly more correct? It forces you to do all the thermal management in userspace! Why's that a problem? Duplicating all the kernel logic in userspace, badly? So don't do it badly. The advantage of doing so is that you can make it work properly, which you can't by putting it in the kernel. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Mon 2007-05-21 14:45:53, Matthew Garrett wrote: On Mon, May 21, 2007 at 03:40:46PM +0200, Pavel Machek wrote: On Mon 2007-05-21 14:36:08, Matthew Garrett wrote: On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote: Significantly more correct? It forces you to do all the thermal management in userspace! Why's that a problem? Duplicating all the kernel logic in userspace, badly? So don't do it badly. The advantage of doing so is that you can make it work properly, which you can't by putting it in the kernel. You want stuff like critical shutdowns to work even if userspace is dead. I do not think you can control passive cooling adequately from userspace, and you can certainly not prevent kernel from slowing machine down too soon. Plus, this is actually nasty user-visible change, and a regression from 2.6.21. I am not sure why we are even debating this; user-kernel interface changed without warning. Patch should be simply reverted. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Tue, May 22, 2007 at 12:42:00AM +0200, Pavel Machek wrote: On Mon 2007-05-21 14:45:53, Matthew Garrett wrote: So don't do it badly. The advantage of doing so is that you can make it work properly, which you can't by putting it in the kernel. You want stuff like critical shutdowns to work even if userspace is dead. I don't think anyone suggested putting the critical shutdown control in userspace. The kernel already handles that fine. I do not think you can control passive cooling adequately from userspace, and you can certainly not prevent kernel from slowing machine down too soon. Given the choice between something impossible and something difficult, I'm inclined towards picking the difficult one. Plus, this is actually nasty user-visible change, and a regression from 2.6.21. I am not sure why we are even debating this; user-kernel interface changed without warning. Patch should be simply reverted. In http://lkml.org/lkml/2007/1/27/93 you were more than happy to break an interface even though it could be fixed in a (ugly) way that made it work again. Here, there's no way to fix this properly - the platform will quite happily do things based on what it believes the trip points should be, and one of those things may be to alter the trip points. Imagine the following situation: 1) Platform sets critical shutdown trip point to 85C 2) Userspace sets critical shutdown trip point to 95C 3) Temperature reaches 90C 4) Platform forces reevaluation of trip points 5) Entire invasion fleet is lost How do you avoid that? Disable the ability for the platform to set trip points? You're breaking the spec and potentially causing hardware damage. If you have specific hardware that requires specific spec breakage, then a better approach would probably be to quirk the kernel to rectify it. On the other hand, if it works with the Other Leading OS, we ought to be able to just fix the problem properly. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Saturday 19 May 2007 15:56, Thomas Renninger wrote: > On Thu, 2007-05-17 at 15:17 -0400, Len Brown wrote: > > On Thursday 17 May 2007 05:23, Pavel Machek wrote: > > > > > > ACPI: thermal trip points are read-only > > > > > > What was the rationale? Can we get this one reverted? > > > > > > Some machines (HP omnibook xe3) have broken trip points -- too high -- > > > so machine will overheat and trigger hw shutdown before starting > > > passive cooling. > > > > > > That's really broken, and write to trip points is reasonable way to > > > 'fix' that. (I'd understand if you only ever let trip points to > > > decrease... but otoh root should be able to shoot himself) > > > > 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. 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. This will have effect until the next trip point changes its state. > Some people are used to it, I already wanted to write a little userspace > prog to use them as it is really easy to fake cooling_mode (trip points > are modified by BIOS) and eliminate fan noise and other things by e.g. > reducing passsive or whatever trip point. please save this effort for a non-ACPI system. > This is at least a major sysfs interface change, has this been discussed > somewhere before or declared deprecated? it went out on linux-acpi, but I don't recall any discussion about it. > 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. > I'd suggest to revert this and I can come with something like "only > allow lower values > than BIOS provides" patch if the current implementation is considered > dangerous. That simply will not address the issue. Indeed, all the entries in the ubuntu bug report are about hitting the critical temperature and having a critical shutdown when it isn't wanted. These people want to RAISE the critical shutdown trip-point. Their cooling problems must be fixed -- raising critical trip points causes them instead to be ignored. 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. If they make a mistake, they will be forgiven when the system reaches the next trip point and turns the fan back on. thanks, -Len > > The OS has no capability to actually change the ACPI trip points > > that are used by the BIOS. Changing the OS copy of them > > to make the user think that trip events will actually > > happen when the temperature crosses the OS copy is crazy. > > > > If there are systems with broken thermals and the > > ACPI thermal control needs and over-ride to turn > > on the fan, then that is fine -- but using > > fake trip-points and giving the user the impression > > that they are real is not viable. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Saturday 19 May 2007 15:56, Thomas Renninger wrote: On Thu, 2007-05-17 at 15:17 -0400, Len Brown wrote: On Thursday 17 May 2007 05:23, Pavel Machek wrote: ACPI: thermal trip points are read-only What was the rationale? Can we get this one reverted? Some machines (HP omnibook xe3) have broken trip points -- too high -- so machine will overheat and trigger hw shutdown before starting passive cooling. That's really broken, and write to trip points is reasonable way to 'fix' that. (I'd understand if you only ever let trip points to decrease... but otoh root should be able to shoot himself) 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. 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. This will have effect until the next trip point changes its state. Some people are used to it, I already wanted to write a little userspace prog to use them as it is really easy to fake cooling_mode (trip points are modified by BIOS) and eliminate fan noise and other things by e.g. reducing passsive or whatever trip point. please save this effort for a non-ACPI system. This is at least a major sysfs interface change, has this been discussed somewhere before or declared deprecated? it went out on linux-acpi, but I don't recall any discussion about it. 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. I'd suggest to revert this and I can come with something like only allow lower values than BIOS provides patch if the current implementation is considered dangerous. That simply will not address the issue. Indeed, all the entries in the ubuntu bug report are about hitting the critical temperature and having a critical shutdown when it isn't wanted. These people want to RAISE the critical shutdown trip-point. Their cooling problems must be fixed -- raising critical trip points causes them instead to be ignored. 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. If they make a mistake, they will be forgiven when the system reaches the next trip point and turns the fan back on. thanks, -Len The OS has no capability to actually change the ACPI trip points that are used by the BIOS. Changing the OS copy of them to make the user think that trip events will actually happen when the temperature crosses the OS copy is crazy. If there are systems with broken thermals and the ACPI thermal control needs and over-ride to turn on the fan, then that is fine -- but using fake trip-points and giving the user the impression that they are real is not viable. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thu, 2007-05-17 at 15:17 -0400, Len Brown wrote: > On Thursday 17 May 2007 05:23, Pavel Machek wrote: > > > > ACPI: thermal trip points are read-only > > > > What was the rationale? Can we get this one reverted? > > > > Some machines (HP omnibook xe3) have broken trip points -- too high -- > > so machine will overheat and trigger hw shutdown before starting > > passive cooling. > > > > That's really broken, and write to trip points is reasonable way to > > 'fix' that. (I'd understand if you only ever let trip points to > > decrease... but otoh root should be able to shoot himself) > > 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 It's also convenient to e.g. lower passive trip point to avoid fan noise. Some people are used to it, I already wanted to write a little userspace prog to use them as it is really easy to fake cooling_mode (trip points are modified by BIOS) and eliminate fan noise and other things by e.g. reducing passsive or whatever trip point. This is at least a major sysfs interface change, has this been discussed somewhere before or declared deprecated? It's there for a long time, why is this "a dangerous and mis-leading hack." now? I'd suggest to revert this and I can come with something like "only allow lower values than BIOS provides" patch if the current implementation is considered dangerous. Thomas > The OS has no capability to actually change the ACPI trip points > that are used by the BIOS. Changing the OS copy of them > to make the user think that trip events will actually > happen when the temperature crosses the OS copy is crazy. > > If there are systems with broken thermals and the > ACPI thermal control needs and over-ride to turn > on the fan, then that is fine -- but using > fake trip-points and giving the user the impression > that they are real is not viable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thu, 2007-05-17 at 15:17 -0400, Len Brown wrote: On Thursday 17 May 2007 05:23, Pavel Machek wrote: ACPI: thermal trip points are read-only What was the rationale? Can we get this one reverted? Some machines (HP omnibook xe3) have broken trip points -- too high -- so machine will overheat and trigger hw shutdown before starting passive cooling. That's really broken, and write to trip points is reasonable way to 'fix' that. (I'd understand if you only ever let trip points to decrease... but otoh root should be able to shoot himself) 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 It's also convenient to e.g. lower passive trip point to avoid fan noise. Some people are used to it, I already wanted to write a little userspace prog to use them as it is really easy to fake cooling_mode (trip points are modified by BIOS) and eliminate fan noise and other things by e.g. reducing passsive or whatever trip point. This is at least a major sysfs interface change, has this been discussed somewhere before or declared deprecated? It's there for a long time, why is this a dangerous and mis-leading hack. now? I'd suggest to revert this and I can come with something like only allow lower values than BIOS provides patch if the current implementation is considered dangerous. Thomas The OS has no capability to actually change the ACPI trip points that are used by the BIOS. Changing the OS copy of them to make the user think that trip events will actually happen when the temperature crosses the OS copy is crazy. If there are systems with broken thermals and the ACPI thermal control needs and over-ride to turn on the fan, then that is fine -- but using fake trip-points and giving the user the impression that they are real is not viable. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
> Something similar happened to me on XE3, yes. > > (Actual values were different; BIOS specified critical temperature at > cca 95C, but hw killed the power at cca 83C. Setting critical trip > point at 80C made the problem go away.) Great, please file a bug and include the acpidump from the XE3 and we'll fix it, rather than supporting a bogus (manual) workaround for it. Of course if your system is running at 80*C and the hardware shuts off at 83*C, you may have a broken fan, or one clogged with dust... -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
> > 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. > > > > The OS has no capability to actually change the ACPI trip points > > that are used by the BIOS. Changing the OS copy of them > > to make the user think that trip events will actually > > happen when the temperature crosses the OS copy is crazy. > > Aha... wait. It seemed to work for me when I enabled thermal > polling... That's exactly the point. If you allow a user to think they over-rode a trip-point but that trip point never fires unless they enable polling mode, then they're not going to get what they asked for. Yes, SuSE enables polling mode by default, but that is just distro specific "value add" that should eventually be fixed. > Slowing cpu down / shutdown / turn the fan on is done in the os after > all. Should we just start polling temperatures when user writes custom > trip points? I actually agree with you for passively cooled embedded systems. Indeed, that is the topic of one of my OLS papers. However, for an off-the-shelf laptop that the vendor ships with a specific active and passive cooling model, Linux is not currently set up to ignore what the vendor provided and go off on its own. Yes, it could be done, but for 99.99% of cases, I expect it would be a mistake. > > If there are systems with broken thermals and the > > ACPI thermal control needs and over-ride to turn > > on the fan, then that is fine -- but using > > fake trip-points and giving the user the impression > > that they are real is not viable. > > They become real when we fake _TSP, too, ..? We are mis-using _TSP today, and over-riding it is a hack on top of a bug... _TSP is only supposed to be for the passive cooling algorithm -- which by definition is polling based. It is not intended to be used for active cooling at all. That is what active trip were invented for... -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thu 2007-05-17 15:08:39, Len Brown wrote: > On Thursday 17 May 2007 09:36, Maciej Rutecki wrote: > > > Many people need change trippoints, for example I have: > > > > cat /proc/acpi/thermal_zone/TZ0/trip_points | grep critical > > critical (S5): 256 C > > > > I _must_ change it to below 105 C, or edit DSDT table (too difficult to > > me). I cannot use this kernel, when trip points are read only. > > What bad things happen if you leave the critical trip point at 256? > Do you find that you can drive the temperature over 105 and > the system fails to shut down? Something similar happened to me on XE3, yes. (Actual values were different; BIOS specified critical temperature at cca 95C, but hw killed the power at cca 83C. Setting critical trip point at 80C made the problem go away.) 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Hi! > > > ACPI: thermal trip points are read-only > > > > What was the rationale? Can we get this one reverted? > > > > Some machines (HP omnibook xe3) have broken trip points -- too high -- > > so machine will overheat and trigger hw shutdown before starting > > passive cooling. > > > > That's really broken, and write to trip points is reasonable way to > > 'fix' that. (I'd understand if you only ever let trip points to > > decrease... but otoh root should be able to shoot himself) > > 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. > > The OS has no capability to actually change the ACPI trip points > that are used by the BIOS. Changing the OS copy of them > to make the user think that trip events will actually > happen when the temperature crosses the OS copy is crazy. Aha... wait. It seemed to work for me when I enabled thermal polling... Slowing cpu down / shutdown / turn the fan on is done in the os after all. Should we just start polling temperatures when user writes custom trip points? > If there are systems with broken thermals and the > ACPI thermal control needs and over-ride to turn > on the fan, then that is fine -- but using > fake trip-points and giving the user the impression > that they are real is not viable. They become real when we fake _TSP, too, ..? 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Added to bugzilla (Bug 8496) http://bugzilla.kernel.org/show_bug.cgi?id=8496 -- Maciej Rutecki http://www.maciek.unixy.pl smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Len Brown pisze: > What bad things happen if you leave the critical trip point at 256? > Do you find that you can drive the temperature over 105 and > the system fails to shut down? > > -Len > > It isn't problem in this case (nx6310). But on hp nc nc6220 first trip point is at 30 *C, so fan is usually on (noise, power consumption). -- Maciej Rutecki www.unixy.pl Kernel Monkeys (http://kernel.wikidot.com/) smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thursday 17 May 2007 05:23, Pavel Machek wrote: > > ACPI: thermal trip points are read-only > > What was the rationale? Can we get this one reverted? > > Some machines (HP omnibook xe3) have broken trip points -- too high -- > so machine will overheat and trigger hw shutdown before starting > passive cooling. > > That's really broken, and write to trip points is reasonable way to > 'fix' that. (I'd understand if you only ever let trip points to > decrease... but otoh root should be able to shoot himself) 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. The OS has no capability to actually change the ACPI trip points that are used by the BIOS. Changing the OS copy of them to make the user think that trip events will actually happen when the temperature crosses the OS copy is crazy. If there are systems with broken thermals and the ACPI thermal control needs and over-ride to turn on the fan, then that is fine -- but using fake trip-points and giving the user the impression that they are real is not viable. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thursday 17 May 2007 09:36, Maciej Rutecki wrote: > Many people need change trippoints, for example I have: > > cat /proc/acpi/thermal_zone/TZ0/trip_points | grep critical > critical (S5): 256 C > > I _must_ change it to below 105 C, or edit DSDT table (too difficult to > me). I cannot use this kernel, when trip points are read only. What bad things happen if you leave the critical trip point at 256? Do you find that you can drive the temperature over 105 and the system fails to shut down? -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Pavel Machek pisze: > What was the rationale? Can we get this one reverted? > > Some machines (HP omnibook xe3) have broken trip points -- too high -- > so machine will overheat and trigger hw shutdown before starting > passive cooling. > > That's really broken, and write to trip points is reasonable way to > 'fix' that. (I'd understand if you only ever let trip points to > decrease... but otoh root should be able to shoot himself) > > Pavel Many people need change trippoints, for example I have: cat /proc/acpi/thermal_zone/TZ0/trip_points | grep critical critical (S5): 256 C I _must_ change it to below 105 C, or edit DSDT table (too difficult to me). I cannot use this kernel, when trip points are read only. -- Maciej Rutecki www.unixy.pl Kernel Monkeys (http://kernel.wikidot.com/) smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Hi! > > In 2.6.20.9 I can change trippoints: > > > > echo "105:100:100:78:70:40:30" > /proc/acpi/thermal_zone/TZ0/trip_points > > echo 10 > /proc/acpi/thermal_zone/TZ0/polling_frequency > > > > Then I got: > > cat /proc/acpi/thermal_zone/TZ0/* ... > > Its bug or feature? > > > > Committed to mainline May 10: > > Gitweb: > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=11ccc0f249cb01a129f54760b8ff087f242935d4 > Commit: 11ccc0f249cb01a129f54760b8ff087f242935d4 > Parent: de46c33745f5e2ad594c72f2cf5f490861b16ce1 > Author: Len Brown <[EMAIL PROTECTED]> > AuthorDate: Mon Apr 30 22:36:01 2007 -0400 > Committer: Len Brown <[EMAIL PROTECTED]> > CommitDate: Mon Apr 30 22:36:01 2007 -0400 > > ACPI: thermal trip points are read-only What was the rationale? Can we get this one reverted? Some machines (HP omnibook xe3) have broken trip points -- too high -- so machine will overheat and trigger hw shutdown before starting passive cooling. That's really broken, and write to trip points is reasonable way to 'fix' that. (I'd understand if you only ever let trip points to decrease... but otoh root should be able to shoot himself) 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Hi! In 2.6.20.9 I can change trippoints: echo 105:100:100:78:70:40:30 /proc/acpi/thermal_zone/TZ0/trip_points echo 10 /proc/acpi/thermal_zone/TZ0/polling_frequency Then I got: cat /proc/acpi/thermal_zone/TZ0/* ... Its bug or feature? Committed to mainline May 10: Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=11ccc0f249cb01a129f54760b8ff087f242935d4 Commit: 11ccc0f249cb01a129f54760b8ff087f242935d4 Parent: de46c33745f5e2ad594c72f2cf5f490861b16ce1 Author: Len Brown [EMAIL PROTECTED] AuthorDate: Mon Apr 30 22:36:01 2007 -0400 Committer: Len Brown [EMAIL PROTECTED] CommitDate: Mon Apr 30 22:36:01 2007 -0400 ACPI: thermal trip points are read-only What was the rationale? Can we get this one reverted? Some machines (HP omnibook xe3) have broken trip points -- too high -- so machine will overheat and trigger hw shutdown before starting passive cooling. That's really broken, and write to trip points is reasonable way to 'fix' that. (I'd understand if you only ever let trip points to decrease... but otoh root should be able to shoot himself) 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Pavel Machek pisze: What was the rationale? Can we get this one reverted? Some machines (HP omnibook xe3) have broken trip points -- too high -- so machine will overheat and trigger hw shutdown before starting passive cooling. That's really broken, and write to trip points is reasonable way to 'fix' that. (I'd understand if you only ever let trip points to decrease... but otoh root should be able to shoot himself) Pavel Many people need change trippoints, for example I have: cat /proc/acpi/thermal_zone/TZ0/trip_points | grep critical critical (S5): 256 C I _must_ change it to below 105 C, or edit DSDT table (too difficult to me). I cannot use this kernel, when trip points are read only. -- Maciej Rutecki www.unixy.pl Kernel Monkeys (http://kernel.wikidot.com/) smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thursday 17 May 2007 09:36, Maciej Rutecki wrote: Many people need change trippoints, for example I have: cat /proc/acpi/thermal_zone/TZ0/trip_points | grep critical critical (S5): 256 C I _must_ change it to below 105 C, or edit DSDT table (too difficult to me). I cannot use this kernel, when trip points are read only. What bad things happen if you leave the critical trip point at 256? Do you find that you can drive the temperature over 105 and the system fails to shut down? -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thursday 17 May 2007 05:23, Pavel Machek wrote: ACPI: thermal trip points are read-only What was the rationale? Can we get this one reverted? Some machines (HP omnibook xe3) have broken trip points -- too high -- so machine will overheat and trigger hw shutdown before starting passive cooling. That's really broken, and write to trip points is reasonable way to 'fix' that. (I'd understand if you only ever let trip points to decrease... but otoh root should be able to shoot himself) 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. The OS has no capability to actually change the ACPI trip points that are used by the BIOS. Changing the OS copy of them to make the user think that trip events will actually happen when the temperature crosses the OS copy is crazy. If there are systems with broken thermals and the ACPI thermal control needs and over-ride to turn on the fan, then that is fine -- but using fake trip-points and giving the user the impression that they are real is not viable. -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Len Brown pisze: What bad things happen if you leave the critical trip point at 256? Do you find that you can drive the temperature over 105 and the system fails to shut down? -Len It isn't problem in this case (nx6310). But on hp nc nc6220 first trip point is at 30 *C, so fan is usually on (noise, power consumption). -- Maciej Rutecki www.unixy.pl Kernel Monkeys (http://kernel.wikidot.com/) smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Added to bugzilla (Bug 8496) http://bugzilla.kernel.org/show_bug.cgi?id=8496 -- Maciej Rutecki http://www.maciek.unixy.pl smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Hi! ACPI: thermal trip points are read-only What was the rationale? Can we get this one reverted? Some machines (HP omnibook xe3) have broken trip points -- too high -- so machine will overheat and trigger hw shutdown before starting passive cooling. That's really broken, and write to trip points is reasonable way to 'fix' that. (I'd understand if you only ever let trip points to decrease... but otoh root should be able to shoot himself) 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. The OS has no capability to actually change the ACPI trip points that are used by the BIOS. Changing the OS copy of them to make the user think that trip events will actually happen when the temperature crosses the OS copy is crazy. Aha... wait. It seemed to work for me when I enabled thermal polling... Slowing cpu down / shutdown / turn the fan on is done in the os after all. Should we just start polling temperatures when user writes custom trip points? If there are systems with broken thermals and the ACPI thermal control needs and over-ride to turn on the fan, then that is fine -- but using fake trip-points and giving the user the impression that they are real is not viable. They become real when we fake _TSP, too, ..? 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thu 2007-05-17 15:08:39, Len Brown wrote: On Thursday 17 May 2007 09:36, Maciej Rutecki wrote: Many people need change trippoints, for example I have: cat /proc/acpi/thermal_zone/TZ0/trip_points | grep critical critical (S5): 256 C I _must_ change it to below 105 C, or edit DSDT table (too difficult to me). I cannot use this kernel, when trip points are read only. What bad things happen if you leave the critical trip point at 256? Do you find that you can drive the temperature over 105 and the system fails to shut down? Something similar happened to me on XE3, yes. (Actual values were different; BIOS specified critical temperature at cca 95C, but hw killed the power at cca 83C. Setting critical trip point at 80C made the problem go away.) 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
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. The OS has no capability to actually change the ACPI trip points that are used by the BIOS. Changing the OS copy of them to make the user think that trip events will actually happen when the temperature crosses the OS copy is crazy. Aha... wait. It seemed to work for me when I enabled thermal polling... That's exactly the point. If you allow a user to think they over-rode a trip-point but that trip point never fires unless they enable polling mode, then they're not going to get what they asked for. Yes, SuSE enables polling mode by default, but that is just distro specific value add that should eventually be fixed. Slowing cpu down / shutdown / turn the fan on is done in the os after all. Should we just start polling temperatures when user writes custom trip points? I actually agree with you for passively cooled embedded systems. Indeed, that is the topic of one of my OLS papers. However, for an off-the-shelf laptop that the vendor ships with a specific active and passive cooling model, Linux is not currently set up to ignore what the vendor provided and go off on its own. Yes, it could be done, but for 99.99% of cases, I expect it would be a mistake. If there are systems with broken thermals and the ACPI thermal control needs and over-ride to turn on the fan, then that is fine -- but using fake trip-points and giving the user the impression that they are real is not viable. They become real when we fake _TSP, too, ..? We are mis-using _TSP today, and over-riding it is a hack on top of a bug... _TSP is only supposed to be for the passive cooling algorithm -- which by definition is polling based. It is not intended to be used for active cooling at all. That is what active trip were invented for... -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Something similar happened to me on XE3, yes. (Actual values were different; BIOS specified critical temperature at cca 95C, but hw killed the power at cca 83C. Setting critical trip point at 80C made the problem go away.) Great, please file a bug and include the acpidump from the XE3 and we'll fix it, rather than supporting a bogus (manual) workaround for it. Of course if your system is running at 80*C and the hardware shuts off at 83*C, you may have a broken fan, or one clogged with dust... -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Le 05/16/2007 07:47 PM, Chuck Ebbert a déclaré : > Gitweb: > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=11ccc0f249cb01a129f54760b8ff087f242935d4 > Commit: 11ccc0f249cb01a129f54760b8ff087f242935d4 > Parent: de46c33745f5e2ad594c72f2cf5f490861b16ce1 > Author: Len Brown <[EMAIL PROTECTED]> > AuthorDate: Mon Apr 30 22:36:01 2007 -0400 > Committer: Len Brown <[EMAIL PROTECTED]> > CommitDate: Mon Apr 30 22:36:01 2007 -0400 > > ACPI: thermal trip points are read-only Should one understand that it IS a wanted behaviour ? Isn't it the DSDT job (which is kernel-accessible, or isn't it ?) to communicate trip_points to ACPI thermal zone ? Isn't OSPM managing thermal zone ? (http://acpi.sourceforge.net/documentation/thermal.html) PS : Sorry for all these (maybe stupid) questions, but I think I remember that changing trip_points had an effect on a (DSDT-bugged) laptop I used to use, and I'd like to understand... PPS : Sorry also for the english mistakes or approximations... -- ~~ |Oo| La banquise fond !!! Adoptez un pingouin... /|\/|\ |__|=> http://doc.ubuntu-fr.org/ ^__^ ~~~| |~~~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Maciej Rutecki wrote: > In 2.6.20.9 I can change trippoints: > > echo "105:100:100:78:70:40:30" > /proc/acpi/thermal_zone/TZ0/trip_points > echo 10 > /proc/acpi/thermal_zone/TZ0/polling_frequency > > Then I got: > cat /proc/acpi/thermal_zone/TZ0/* > > cooling mode: active > polling frequency: 10 seconds > state: active[2] > temperature: 45 C > critical (S5): 105 C > active[0]: 78 C: devices=0xdf415a40 > active[1]: 70 C: devices=0xdf4159dc > active[2]: 40 C: devices=0xdf41598c > active[3]: 30 C: devices=0xdf41593c > > cat /proc/acpi/fan/*/* > status: off > status: off > status: on > status: on > > And fan turns on. > > In 2.6.22-rc1-mm1: > echo "105:100:100:78:70:40:30" > /proc/acpi/thermal_zone/TZ0/trip_points > bash: echo: write error: BĹÄ d wejĹcia/wyjĹcia (input/output error) > > rutek:/home/maciek# cat /proc/acpi/thermal_zone/TZ0/* > > polling frequency: 10 seconds > state: ok > temperature: 45 C > critical (S5): 256 C > active[0]: 78 C: devices=0xc1827a40 > active[1]: 70 C: devices=0xc18279dc > active[2]: 60 C: devices=0xc182798c > active[3]: 50 C: devices=0xc182793c > rutek:/home/maciek# cat /proc/acpi/fan/*/* > status: off > status: off > status: off > status: off > > Fan turns on when temperature is over 50*C. (want: 30) > > A read this: > http://article.gmane.org/gmane.linux.acpi.devel/22750 > > But I don't have colling_policy, but only colling_mode: > ls /proc/acpi/thermal_zone/TZ0/ > cooling_mode polling_frequency state temperature trip_points > > Its bug or feature? > Committed to mainline May 10: Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=11ccc0f249cb01a129f54760b8ff087f242935d4 Commit: 11ccc0f249cb01a129f54760b8ff087f242935d4 Parent: de46c33745f5e2ad594c72f2cf5f490861b16ce1 Author: Len Brown <[EMAIL PROTECTED]> AuthorDate: Mon Apr 30 22:36:01 2007 -0400 Committer: Len Brown <[EMAIL PROTECTED]> CommitDate: Mon Apr 30 22:36:01 2007 -0400 ACPI: thermal trip points are read-only - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
In 2.6.20.9 I can change trippoints: echo "105:100:100:78:70:40:30" > /proc/acpi/thermal_zone/TZ0/trip_points echo 10 > /proc/acpi/thermal_zone/TZ0/polling_frequency Then I got: cat /proc/acpi/thermal_zone/TZ0/* cooling mode: active polling frequency: 10 seconds state: active[2] temperature: 45 C critical (S5): 105 C active[0]: 78 C: devices=0xdf415a40 active[1]: 70 C: devices=0xdf4159dc active[2]: 40 C: devices=0xdf41598c active[3]: 30 C: devices=0xdf41593c cat /proc/acpi/fan/*/* status: off status: off status: on status: on And fan turns on. In 2.6.22-rc1-mm1: echo "105:100:100:78:70:40:30" > /proc/acpi/thermal_zone/TZ0/trip_points bash: echo: write error: BĹÄ d wejĹcia/wyjĹcia (input/output error) rutek:/home/maciek# cat /proc/acpi/thermal_zone/TZ0/* polling frequency: 10 seconds state: ok temperature: 45 C critical (S5): 256 C active[0]: 78 C: devices=0xc1827a40 active[1]: 70 C: devices=0xc18279dc active[2]: 60 C: devices=0xc182798c active[3]: 50 C: devices=0xc182793c rutek:/home/maciek# cat /proc/acpi/fan/*/* status: off status: off status: off status: off Fan turns on when temperature is over 50*C. (want: 30) A read this: http://article.gmane.org/gmane.linux.acpi.devel/22750 But I don't have colling_policy, but only colling_mode: ls /proc/acpi/thermal_zone/TZ0/ cooling_mode polling_frequency state temperature trip_points Its bug or feature? Config, acpidump, dmesg: http://www.unixy.pl/maciek/download/kernel/2.6.22-rc1-mm1/ -- Maciej Rutecki www.unixy.pl Kernel Monkeys (http://kernel.wikidot.com/) smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
In 2.6.20.9 I can change trippoints: echo 105:100:100:78:70:40:30 /proc/acpi/thermal_zone/TZ0/trip_points echo 10 /proc/acpi/thermal_zone/TZ0/polling_frequency Then I got: cat /proc/acpi/thermal_zone/TZ0/* setting not supported cooling mode: active polling frequency: 10 seconds state: active[2] temperature: 45 C critical (S5): 105 C active[0]: 78 C: devices=0xdf415a40 active[1]: 70 C: devices=0xdf4159dc active[2]: 40 C: devices=0xdf41598c active[3]: 30 C: devices=0xdf41593c cat /proc/acpi/fan/*/* status: off status: off status: on status: on And fan turns on. In 2.6.22-rc1-mm1: echo 105:100:100:78:70:40:30 /proc/acpi/thermal_zone/TZ0/trip_points bash: echo: write error: BĹÄ d wejĹcia/wyjĹcia (input/output error) rutek:/home/maciek# cat /proc/acpi/thermal_zone/TZ0/* setting not supported polling frequency: 10 seconds state: ok temperature: 45 C critical (S5): 256 C active[0]: 78 C: devices=0xc1827a40 active[1]: 70 C: devices=0xc18279dc active[2]: 60 C: devices=0xc182798c active[3]: 50 C: devices=0xc182793c rutek:/home/maciek# cat /proc/acpi/fan/*/* status: off status: off status: off status: off Fan turns on when temperature is over 50*C. (want: 30) A read this: http://article.gmane.org/gmane.linux.acpi.devel/22750 But I don't have colling_policy, but only colling_mode: ls /proc/acpi/thermal_zone/TZ0/ cooling_mode polling_frequency state temperature trip_points Its bug or feature? Config, acpidump, dmesg: http://www.unixy.pl/maciek/download/kernel/2.6.22-rc1-mm1/ -- Maciej Rutecki www.unixy.pl Kernel Monkeys (http://kernel.wikidot.com/) smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Maciej Rutecki wrote: In 2.6.20.9 I can change trippoints: echo 105:100:100:78:70:40:30 /proc/acpi/thermal_zone/TZ0/trip_points echo 10 /proc/acpi/thermal_zone/TZ0/polling_frequency Then I got: cat /proc/acpi/thermal_zone/TZ0/* setting not supported cooling mode: active polling frequency: 10 seconds state: active[2] temperature: 45 C critical (S5): 105 C active[0]: 78 C: devices=0xdf415a40 active[1]: 70 C: devices=0xdf4159dc active[2]: 40 C: devices=0xdf41598c active[3]: 30 C: devices=0xdf41593c cat /proc/acpi/fan/*/* status: off status: off status: on status: on And fan turns on. In 2.6.22-rc1-mm1: echo 105:100:100:78:70:40:30 /proc/acpi/thermal_zone/TZ0/trip_points bash: echo: write error: BĹÄ d wejĹcia/wyjĹcia (input/output error) rutek:/home/maciek# cat /proc/acpi/thermal_zone/TZ0/* setting not supported polling frequency: 10 seconds state: ok temperature: 45 C critical (S5): 256 C active[0]: 78 C: devices=0xc1827a40 active[1]: 70 C: devices=0xc18279dc active[2]: 60 C: devices=0xc182798c active[3]: 50 C: devices=0xc182793c rutek:/home/maciek# cat /proc/acpi/fan/*/* status: off status: off status: off status: off Fan turns on when temperature is over 50*C. (want: 30) A read this: http://article.gmane.org/gmane.linux.acpi.devel/22750 But I don't have colling_policy, but only colling_mode: ls /proc/acpi/thermal_zone/TZ0/ cooling_mode polling_frequency state temperature trip_points Its bug or feature? Committed to mainline May 10: Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=11ccc0f249cb01a129f54760b8ff087f242935d4 Commit: 11ccc0f249cb01a129f54760b8ff087f242935d4 Parent: de46c33745f5e2ad594c72f2cf5f490861b16ce1 Author: Len Brown [EMAIL PROTECTED] AuthorDate: Mon Apr 30 22:36:01 2007 -0400 Committer: Len Brown [EMAIL PROTECTED] CommitDate: Mon Apr 30 22:36:01 2007 -0400 ACPI: thermal trip points are read-only - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
Le 05/16/2007 07:47 PM, Chuck Ebbert a déclaré : Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=11ccc0f249cb01a129f54760b8ff087f242935d4 Commit: 11ccc0f249cb01a129f54760b8ff087f242935d4 Parent: de46c33745f5e2ad594c72f2cf5f490861b16ce1 Author: Len Brown [EMAIL PROTECTED] AuthorDate: Mon Apr 30 22:36:01 2007 -0400 Committer: Len Brown [EMAIL PROTECTED] CommitDate: Mon Apr 30 22:36:01 2007 -0400 ACPI: thermal trip points are read-only Should one understand that it IS a wanted behaviour ? Isn't it the DSDT job (which is kernel-accessible, or isn't it ?) to communicate trip_points to ACPI thermal zone ? Isn't OSPM managing thermal zone ? (http://acpi.sourceforge.net/documentation/thermal.html) PS : Sorry for all these (maybe stupid) questions, but I think I remember that changing trip_points had an effect on a (DSDT-bugged) laptop I used to use, and I'd like to understand... PPS : Sorry also for the english mistakes or approximations... -- ~~ |Oo| La banquise fond !!! Adoptez un pingouin... /|\/|\ |__|= http://doc.ubuntu-fr.org/ ^__^ ~~~| |~~~ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
