GSoC2007: cnst-sensors.2007-09-13.patch

[Constantine A. Murenin-3]

Dear freebsd-{arch,current,hackers}@,

On this 256th day of 2007, it is my great pleasure to announce the
completion of my GSoC2007 project on porting the sysctl hardware sensors
framework from OpenBSD to FreeBSD.

All of the things that were planned to be ported from OpenBSD base
system to FreeBSD have now been ported.

The userland part of the framework is entirely source-code compatible
with OpenBSD.  For example, you can take OpenBSD's stock sensorsd(8),
and it'll compile and work on FreeBSD with no modifications.

The framework is quite self-contained, so I think it is a safe bet to at
least try to get it into the tree even at this point, when the code
freeze is taking place in preparation for RELENG_7 branching.

Therefore, I hereby request that this patch be considered for immediate
inclusion into FreeBSD's main CVS repository.

The complete CVS patch is available from:
        http://mojo.ru/us/GSoC2007.cnst-sensors.2007-09-13.patch.gz

For backup purposes, a copy of this CVS patch is also available in my
perforce branch, although it has tainted $P4$ tags in individual files,
so use perforce as a last resort:
http://p4web.freebsd.org//depot/projects/soc2007/cnst-sensors/cnst-sensors.2007-09-13.patch

Exact details on how to apply and test the patch are available in my
LiveJournal, along with certain other comments:

        http://cnst.livejournal.com/38421.html#directions

If you have an Intel Core 2 processor, or a Winbond or ITE Tech Super
I/O chip on your board, then please test and report back on how your
tests went.

Best regards,
Constantine Aleksandrovich Murenin,
Google Summer of Code 2007 Student @ The FreeBSD Project. ;)


On 13/09/2007 19:02, Constantine A. Murenin wrote:

> http://perforce.freebsd.org/chv.cgi?CH=126384
>
> Change 126384 by cnst@dale on 2007/09/13 23:01:55
>
> On this 256th day of 2007,   it is my great pleasure to
> present a feature-complete port of the hardware sensors
> framework from OpenBSD to FreeBSD.
>
> Below is a complete `cvs diff` of cnst-sensors GSoC2007
> project as of 2007-256.
>
> It includes the following components,  listed below in
> the very same order as they are appearing in this diff:
>
> * sample configuration file for sensorsd
> * rc(8) script and glue code for sensorsd(8)
> * sysctl(3) doc fixes for CTL_HW tree
> * sysctl(3) documentation for hardware sensors
> * sysctl(8) documentation for hardware sensors
> * assorted KNF and bug-fixes for sysctl(8)
> * support for the sensor structure for sysctl(8)
> * coretemp(4) documentation
> * it(4) documentation
> * lm(4) documentation
> * rc.conf(5) documentation for starting sensorsd(8)
> * sensor_attach(9) et al documentation
> * coretemp(4) conversion to the hw.sensors framework
> * it(4) isa driver ported from OpenBSD
> * lm(4) isa driver ported from OpenBSD
> * /sys/kern/kern_sensors.c
>  o sensor_attach(9) API for drivers to register ksensors
>  o sensor_task_register(9) API for the update task
>  o sysctl(3) glue code
>  o hw.sensors shadow tree for sysctl(8) internal magic
> * assorted KNF and bug-fixes for /sys/kern/kern_sysctl.c
> * it(4) module for testing sensor_attach/detach et al
> * lm(4) module for testing sensor_attach/detach et al
> * <sys/sensors.h>
> * assorted bug-fixes and HW_SENSORS definition for <sys/sysctl.h>
> * sensors display for systat(1), including all documentation
> * sensorsd(8) and all applicable documentation
>
> The userland part of the framework is entirely source-code
> compatible with OpenBSD 4.1, 4.2 and  -current as of today.
>
> All sensor readings can be viewed with `sysctl hw.sensors`,
> monitored in semi-realtime with `systat -sensors` and also
> logged with `sensorsd`.   Third-party tools, for example a
> plug-in for nagios, are also available.  A separate patch
> for ports/sysutils/symon will be provided upon request.
>
> Submitted by: cnst@... (Constantine A. Murenin)
> Obtained from: generated by sensors.cvsdiff.sh from
> //depot/projects/soc2007/cnst-sensors/
> Sponsored by: Google Summer of Code 2007
>
>
> Obtained from: http://mojo.ru/us/GSoC2007.cnst-sensors.2007-09-13.patch.gz
>
> Details at: http://cnst.livejournal.com/38421.html
>
> Affected files ...
>
> .. //depot/projects/soc2007/cnst-sensors/cnst-sensors.2007-09-13.patch#1 add
>
> Differences ...
>

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Dag-Erling Smørgrav]

"Constantine A. Murenin" <cnst@...> writes:
> Therefore, I hereby request that this patch be considered for
> immediate inclusion into FreeBSD's main CVS repository.

Trouble is, we're in code freeze...  you'll have to ask re@.

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Doug Barton]

On Thu, 13 Sep 2007, Constantine A. Murenin wrote:

> Dear freebsd-{arch,current,hackers}@,
>
> On this 256th day of 2007, it is my great pleasure to announce the completion
> of my GSoC2007 project on porting the sysctl hardware sensors framework from
> OpenBSD to FreeBSD.

This works great on my C2D:

hw.sensors.cpu0.temp0: 79.00 degC
hw.sensors.cpu1.temp0: 82.00 degC

Sensor                            Value      Status       Description
cpu0.temp0                   82.00 degC
cpu1.temp0                   84.00 degC

(the temp went up because I was compiling something).

Two small comments about the rc.d stuff. First, the empty _flags variable
in defaults/rc.conf should be commented out. Second, the rc.d script needs
the shutdown KEYWORD.

hth,

Doug

--

     This .signature sanitized for your protection

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Constantine A. Murenin-3]

On 19/09/2007 01:13, Doug Barton wrote:

> On Thu, 13 Sep 2007, Constantine A. Murenin wrote:
>
>> Dear freebsd-{arch,current,hackers}@,
>>
>> On this 256th day of 2007, it is my great pleasure to announce the
>> completion of my GSoC2007 project on porting the sysctl hardware
>> sensors framework from OpenBSD to FreeBSD.
>
>
> This works great on my C2D:
>
> hw.sensors.cpu0.temp0: 79.00 degC
> hw.sensors.cpu1.temp0: 82.00 degC
>
> Sensor                            Value      Status       Description
> cpu0.temp0                   82.00 degC
> cpu1.temp0                   84.00 degC
>
> (the temp went up because I was compiling something).

Thanks for testing!

> Two small comments about the rc.d stuff. First, the empty _flags
> variable in defaults/rc.conf should be commented out. Second, the rc.d

How so?  I don't see any other empty _flags variables in
defaults/rc.conf being commented out.

> script needs the shutdown KEYWORD.

Similarly, I don't see why this is needed -- it was not used by the
scripts on which this script was based on (the history is in p4).
Reading through rc(8) doesn't seem to suggest that this keyword would
actually be applicable here.

Cheers,
Constnatine.
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Doug Barton]

On Wed, 19 Sep 2007, Constantine A. Murenin wrote:

> Thanks for testing!

Glad to help. In case it's interesting, I was doing the xorg update with
portmaster last night and I got several "PROCHOT asserted" messages on my
console at different times. I'm assuming that's expected behavior, just
curious if it's something bad, as in when that happens it's time to turn
off the laptop? (I didn't seem them when the happened, they were there
when I got back to check on the compiling.)

>> Two small comments about the rc.d stuff. First, the empty _flags variable
>> in defaults/rc.conf should be commented out. Second, the rc.d
>
> How so?  I don't see any other empty _flags variables in defaults/rc.conf
> being commented out.

Well you missed named_flags. :) But seriously, I didn't realize that
things had gotten quite so out of hand with that ... never mind then.

>> script needs the shutdown KEYWORD.
>
> Similarly, I don't see why this is needed -- it was not used by the scripts
> on which this script was based on

Which scripts? I realize that a distressingly large number of scripts that
start services don't have this keyword, but they should. I'll work on a
patch for that. At the same time, we don't want to add any new scripts
that make the same mistake.

> Reading through rc(8) doesn't seem to suggest that this keyword would
> actually be applicable here.

As far as I can tell, you're starting a daemon, which means that it should
be cleanly shut down when the system exits.

Doug

--

     This .signature sanitized for your protection

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Constantine A. Murenin-3]

On 20/09/2007 19:12, Doug Barton wrote:

> On Wed, 19 Sep 2007, Constantine A. Murenin wrote:
>
>> Thanks for testing!
>
>
> Glad to help. In case it's interesting, I was doing the xorg update with
> portmaster last night and I got several "PROCHOT asserted" messages on
> my console at different times. I'm assuming that's expected behavior,
> just curious if it's something bad, as in when that happens it's time to
> turn off the laptop? (I didn't seem them when the happened, they were
> there when I got back to check on the compiling.)

Based on the fact that it's a laptop, I'm not too surprised -- the word
'laptop' in itself should not be taken literally due to the heat that
these things produce -- you clearly don't want them on your lap. :-)

>>> Two small comments about the rc.d stuff. First, the empty _flags
>>> variable in defaults/rc.conf should be commented out. Second, the rc.d
>>
>>
>> How so?  I don't see any other empty _flags variables in
>> defaults/rc.conf being commented out.
>
>
> Well you missed named_flags. :) But seriously, I didn't realize that
> things had gotten quite so out of hand with that ... never mind then.
>
>>> script needs the shutdown KEYWORD.
>>
>>
>> Similarly, I don't see why this is needed -- it was not used by the
>> scripts on which this script was based on
>
>
> Which scripts? I realize that a distressingly large number of scripts
> that start services don't have this keyword, but they should. I'll work
> on a patch for that. At the same time, we don't want to add any new
> scripts that make the same mistake.

http://lists.freebsd.org/pipermail/p4-projects/2007-September/020980.html
"add /etc/rc.d/sensorsd, modelled after ftpproxy and somewhat around powerd"


>> Reading through rc(8) doesn't seem to suggest that this keyword would
>> actually be applicable here.
>
>
> As far as I can tell, you're starting a daemon, which means that it
> should be cleanly shut down when the system exits.

Again, this is not how the majority of other daemons do it.  Moreover, I
am not aware of any practical problems with the current approach.

> Doug

C.
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Rui Paulo]

On 21 Sep 2007, at 00:12, Doug Barton wrote:

> On Wed, 19 Sep 2007, Constantine A. Murenin wrote:
>
>> Thanks for testing!
>
> Glad to help. In case it's interesting, I was doing the xorg update  
> with portmaster last night and I got several "PROCHOT asserted"  
> messages on my console at different times. I'm assuming that's  
> expected behavior, just curious if it's something bad, as in when  
> that happens it's time to turn off the laptop? (I didn't seem them  
> when the happened, they were there when I got back to check on the  
> compiling.)

That basically means the digital sensor has detected a high  
temperature and it allows the operating system to do "something". I  
plan to work a bit more on coretemp(4) so that all these  
notifications go through devctl(4).

Regards.
--
Rui Paulo

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Kevin Oberman]

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Kevin Oberman]

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Kevin Oberman]

> Date: Thu, 20 Sep 2007 16:12:13 -0700 (PDT)

> From: Doug Barton <dougb@...>
> Sender: owner-freebsd-current@...
>
> On Wed, 19 Sep 2007, Constantine A. Murenin wrote:
>
> > Thanks for testing!
>
> Glad to help. In case it's interesting, I was doing the xorg update with
> portmaster last night and I got several "PROCHOT asserted" messages on my
> console at different times. I'm assuming that's expected behavior, just
> curious if it's something bad, as in when that happens it's time to turn
> off the laptop? (I didn't seem them when the happened, they were there
> when I got back to check on the compiling.)
>
> >> Two small comments about the rc.d stuff. First, the empty _flags variable
> >> in defaults/rc.conf should be commented out. Second, the rc.d
> >
> > How so?  I don't see any other empty _flags variables in defaults/rc.conf
> > being commented out.
>
> Well you missed named_flags. :) But seriously, I didn't realize that
> things had gotten quite so out of hand with that ... never mind then.
>
> >> script needs the shutdown KEYWORD.
> >
> > Similarly, I don't see why this is needed -- it was not used by the scripts
> > on which this script was based on
>
> Which scripts? I realize that a distressingly large number of scripts that
> start services don't have this keyword, but they should. I'll work on a
> patch for that. At the same time, we don't want to add any new scripts
> that make the same mistake.
>
> > Reading through rc(8) doesn't seem to suggest that this keyword would
> > actually be applicable here.
>
> As far as I can tell, you're starting a daemon, which means that it should
> be cleanly shut down when the system exits.

I've now read rcorder(8) and rc(8). I am very unclear what the
significance of the shutdown keyword is. I thought it was to cause
rc.shutdown to invoke a "stop" at shutdown time, but only 11 of the
scripts in /etc/rc.d include the shutdown keyword. They do include most
of the daemons which look likely to really need to be shut down
(e.g. random, mixer, nfsd, inetd, auditd), but it is missing from a
number of others.

I think 'shutdown' might belong in others, but, if a 'kill -9' does the
same thing as a 'stop' operation for a given daemon, it might be better
to not have 'shutdown' to avoid having a hung daemon delay the shutdown.

The reality is that it looks like it is usually done right and I don't
see any real reason for 'shutdown' in this case.

Feel free to call me a fool. I don't claim to
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@... Phone: [phone]
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

[Doug Barton]

On Fri, 21 Sep 2007, Rui Paulo wrote:

>
> On 21 Sep 2007, at 00:12, Doug Barton wrote:
>
>> On Wed, 19 Sep 2007, Constantine A. Murenin wrote:
>>
>>> Thanks for testing!
>>
>> Glad to help. In case it's interesting, I was doing the xorg update with
>> portmaster last night and I got several "PROCHOT asserted" messages on my
>> console at different times. I'm assuming that's expected behavior, just
>> curious if it's something bad, as in when that happens it's time to turn
>> off the laptop? (I didn't seem them when the happened, they were there when
>> I got back to check on the compiling.)
>
> That basically means the digital sensor has detected a high temperature and
> it allows the operating system to do "something". I plan to work a bit more
> on coretemp(4) so that all these notifications go through devctl(4).

Great, I look forward to that. :)

Doug

--

     This .signature sanitized for your protection

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Chuck Swiger-2]

On Sep 21, 2007, at 9:16 AM, Rui Paulo wrote:

> On 21 Sep 2007, at 00:12, Doug Barton wrote:
>> On Wed, 19 Sep 2007, Constantine A. Murenin wrote:
>>> Thanks for testing!
>>
>> Glad to help. In case it's interesting, I was doing the xorg  
>> update with portmaster last night and I got several "PROCHOT  
>> asserted" messages on my console at different times. I'm assuming  
>> that's expected behavior, just curious if it's something bad, as  
>> in when that happens it's time to turn off the laptop? (I didn't  
>> seem them when the happened, they were there when I got back to  
>> check on the compiling.)
>
> That basically means the digital sensor has detected a high  
> temperature and it allows the operating system to do "something". I  
> plan to work a bit more on coretemp(4) so that all these  
> notifications go through devctl(4).

The CPU itself has a thermal control circuit which puts the CPU into  
a reduced duty cycle (ie, it reduces the core voltage and stops the  
CPU for something like 10 clocks, and then allows one clock through)  
and continues to run the CPU at about 10% of normal workload until  
the temperature falls below the critical threshold.  There's a good  
document here:

   http://www.intel.com/technology/magazine/computing/it04021.pdf

[ There are plenty of others handy if you do a search on Intel's  
website, but that particular link is short and readable compared with  
the processor spec docs.  :-) ]

The threshold temperature varies depending on the exact part, but is  
generally around 65 Celsius-- and is hot enough that you don't really  
want to encounter it in normal operation, as it's a sign that cooling  
is not adequate for the system to continue to operate safely at full  
speed.  Most of the Intel CPUs also include a second thermal circuit  
called THERMTRIP which fires around 95 Celsius which will shut the  
CPU down entirely to prevent a catastrophic failure.

A longer article is here:

   http://www.intel.com/technology/itj/2006/volume10issue02/ 
art03_power_and_thermal_management/p03_power_management.htm

--
-Chuck

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Jeremy Chadwick-3]

On Fri, Sep 21, 2007 at 12:20:07PM -0700, Chuck Swiger wrote:
> The CPU itself has a thermal control circuit which puts the CPU into a
> reduced duty cycle (ie, it reduces the core voltage and stops the CPU for
> something like 10 clocks, and then allows one clock through) and continues
> to run the CPU at about 10% of normal workload until the temperature falls
> below the critical threshold.  There's a good document here:

Are you referring to the Core 2 Duo C1E (Enhanced Halt State) processor
feature or the EIST feature?  I'm guessing C1E.  Note that for C1E to
work, it has to be enabled/available in the BIOS.

I'll add that C1E is really great, dropping temperatures during idle
periods by about 5-6C from what I've seen.  The additional C[234]E
states (at least for desktops) don't provide much benefit, but C1E
definitely does.

--
| Jeremy Chadwick                                    jdc at parodius.com |
| Parodius Networking                           http://www.parodius.com/ |
| UNIX Systems Administrator                      Mountain View, CA, USA |
| Making life hard for others since 1977.                  PGP: 4BD6C0CB |

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Chuck Swiger-2]

On Sep 21, 2007, at 12:33 PM, Jeremy Chadwick wrote:

> On Fri, Sep 21, 2007 at 12:20:07PM -0700, Chuck Swiger wrote:
>> The CPU itself has a thermal control circuit which puts the CPU  
>> into a
>> reduced duty cycle (ie, it reduces the core voltage and stops the  
>> CPU for
>> something like 10 clocks, and then allows one clock through) and  
>> continues
>> to run the CPU at about 10% of normal workload until the  
>> temperature falls
>> below the critical threshold.  There's a good document here:
>
> Are you referring to the Core 2 Duo C1E (Enhanced Halt State)  
> processor
> feature or the EIST feature?  I'm guessing C1E.  Note that for C1E to
> work, it has to be enabled/available in the BIOS.
>
> I'll add that C1E is really great, dropping temperatures during idle
> periods by about 5-6C from what I've seen.  The additional C[234]E
> states (at least for desktops) don't provide much benefit, but C1E
> definitely does.

Nope, although the second link I mentioned does discuss the state  
diagram the Core processors use for transitioning between various  
ACPI sleep states also in order to reduce power usage and hence  
thermal dissipation.  That does indeed require ACPI to be enabled/
supported in the BIOS, as you've said.

Anyway, the PROCHOT signal originated back circa the Pentium-3's or  
Pentium-M/Centrino's and has been included with the P4/Xeon and now  
Core/Core2's also-- it's a fallback mechanism which does not require  
BIOS support, and involves changes which reduce the CPU core voltage  
supplied by the voltage regulator circuitry and what Intel calls  
"modulating" the CPU clock to reduce the effective clock frequency it  
is running at by running at roughly a 10% duty cycle (this varies  
depending on the specific part), even if the external clock doesn't  
change the way it does with SpeedStep/EIST.

--
-Chuck

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Constantine A. Murenin-3]

Dear freebsd-{current,hardware}@,

Let me a give a few guiding comments for potential testers and
integrators of this patch.


First of all, let's start with a common pitfall:

*  You have to update your /boot/device.hints, and then reboot. In no
other circumstance will the isa-based lm(4) or it(4) be probed. Manually
updating the hints with kenv(1) after the system has already been booted
has no effect on the isa modules.  *


Second, since this patch is not only about the framework, but about some
Super I/O Hardware Monitoring drivers too, let me once again reiterate
on the popularity of the chips that are supported by the lm(4) and it(4)
drivers.

I have four boxes here, all run FreeBSD and OpenBSD.  Let's see what
Super I/O chips they have:

* AOpen AX4G-N (845G + Intel Pentium 4 Northwood): Winbond W83627HF-AM
* ASUS Terminator C3 (VIA CLE266 + VIA C3 Samuel 2): Winbond W83627THF-A
* ASUS V3-P5G965 (G965 + Intel Core 2 Duo Allendale): Winbond W83627DHG-A
* PCCHIPS V21G (VIA CN700 + VIA C7 Esther): ITE IT8716F-S

Out of the above, Winbond W83627* are supported by lm(4), and ITE
IT8716F-S by it(4). (Obviously, the drivers support other chips, too. ;)

In general, most boards from Taiwanese manufacturers have either a
Winbond or ITE Tech Super I/O chips, supported by lm(4) and it(4)
respectively;  e.g. if you have a Gigabyte or ASUS mainboard, then the
probability of you having one of these chips is quite substantial --
consider testing the patch if you are interested.

Supermicro boards also feature Winbond chips quite often -- feel free to
test.

Intel-branded boards, on the other hand, often use an SMBus-interfaced
Hardware Monitoring solution.  I have none of those boards, so none of
the SMBus drivers were ported to FreeBSD yet.

Anyhow, I hope this information helps some potential testers and
integrators. ;)

Cheers,
Constantine.


On 13/09/2007 23:12, Constantine A. Murenin wrote:

> Dear freebsd-{arch,current,hackers}@,
>
> On this 256th day of 2007, it is my great pleasure to announce the
> completion of my GSoC2007 project on porting the sysctl hardware sensors
> framework from OpenBSD to FreeBSD.
>
> All of the things that were planned to be ported from OpenBSD base
> system to FreeBSD have now been ported.
>
> The userland part of the framework is entirely source-code compatible
> with OpenBSD.  For example, you can take OpenBSD's stock sensorsd(8),
> and it'll compile and work on FreeBSD with no modifications.
>
> The framework is quite self-contained, so I think it is a safe bet to at
> least try to get it into the tree even at this point, when the code
> freeze is taking place in preparation for RELENG_7 branching.
>
> Therefore, I hereby request that this patch be considered for immediate
> inclusion into FreeBSD's main CVS repository.
>
> The complete CVS patch is available from:
>     http://mojo.ru/us/GSoC2007.cnst-sensors.2007-09-13.patch.gz
>
> For backup purposes, a copy of this CVS patch is also available in my
> perforce branch, although it has tainted $P4$ tags in individual files,
> so use perforce as a last resort:
> http://p4web.freebsd.org//depot/projects/soc2007/cnst-sensors/cnst-sensors.2007-09-13.patch 
>
>
> Exact details on how to apply and test the patch are available in my
> LiveJournal, along with certain other comments:
>
>     http://cnst.livejournal.com/38421.html#directions
>
> If you have an Intel Core 2 processor, or a Winbond or ITE Tech Super
> I/O chip on your board, then please test and report back on how your
> tests went.
>
> Best regards,
> Constantine Aleksandrovich Murenin,
> Google Summer of Code 2007 Student @ The FreeBSD Project. ;)
>
>
> On 13/09/2007 19:02, Constantine A. Murenin wrote:
>
>> http://perforce.freebsd.org/chv.cgi?CH=126384
>>
>> Change 126384 by cnst@dale on 2007/09/13 23:01:55
>>
>>     On this 256th day of 2007,   it is my great pleasure to
>>     present a feature-complete port of the hardware sensors
>>     framework from OpenBSD to FreeBSD.
>>    
>>     Below is a complete `cvs diff` of cnst-sensors GSoC2007
>>     project as of 2007-256.
>>    
>>     It includes the following components,  listed below in
>>     the very same order as they are appearing in this diff:
>>    
>>     * sample configuration file for sensorsd
>>     * rc(8) script and glue code for sensorsd(8)
>>     * sysctl(3) doc fixes for CTL_HW tree
>>     * sysctl(3) documentation for hardware sensors
>>     * sysctl(8) documentation for hardware sensors
>>     * assorted KNF and bug-fixes for sysctl(8)
>>     * support for the sensor structure for sysctl(8)
>>     * coretemp(4) documentation
>>     * it(4) documentation
>>     * lm(4) documentation
>>     * rc.conf(5) documentation for starting sensorsd(8)
>>     * sensor_attach(9) et al documentation
>>     * coretemp(4) conversion to the hw.sensors framework
>>     * it(4) isa driver ported from OpenBSD
>>     * lm(4) isa driver ported from OpenBSD
>>     * /sys/kern/kern_sensors.c
>>       o sensor_attach(9) API for drivers to register ksensors
>>       o sensor_task_register(9) API for the update task
>>       o sysctl(3) glue code
>>       o hw.sensors shadow tree for sysctl(8) internal magic
>>     * assorted KNF and bug-fixes for /sys/kern/kern_sysctl.c
>>     * it(4) module for testing sensor_attach/detach et al
>>     * lm(4) module for testing sensor_attach/detach et al
>>     * <sys/sensors.h>
>>     * assorted bug-fixes and HW_SENSORS definition for <sys/sysctl.h>
>>     * sensors display for systat(1), including all documentation
>>     * sensorsd(8) and all applicable documentation
>>    
>>     The userland part of the framework is entirely source-code
>>     compatible with OpenBSD 4.1, 4.2 and  -current as of today.
>>    
>>     All sensor readings can be viewed with `sysctl hw.sensors`,
>>     monitored in semi-realtime with `systat -sensors` and also
>>     logged with `sensorsd`.   Third-party tools, for example a
>>     plug-in for nagios, are also available.  A separate patch
>>     for ports/sysutils/symon will be provided upon request.
>>    
>>     Submitted by:    cnst@... (Constantine A. Murenin)
>>     Obtained from:    generated by sensors.cvsdiff.sh from
>>             //depot/projects/soc2007/cnst-sensors/
>>     Sponsored by:    Google Summer of Code 2007
>>    
>>    
>>     Obtained from:    
>> http://mojo.ru/us/GSoC2007.cnst-sensors.2007-09-13.patch.gz
>>    
>>     Details at:    http://cnst.livejournal.com/38421.html
>>
>> Affected files ...
>>
>> ..
>> //depot/projects/soc2007/cnst-sensors/cnst-sensors.2007-09-13.patch#1 add
>>
>> Differences ...
>>
>

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[martinko-5]

Chuck Swiger wrote:
>
> The threshold temperature varies depending on the exact part, but is
> generally around 65 Celsius-- and is hot enough that you don't really
> want to encounter it in normal operation, as it's a sign that cooling is
> not adequate for the system to continue to operate safely at full
> speed.  Most of the Intel CPUs also include a second thermal circuit
> called THERMTRIP which fires around 95 Celsius which will shut the CPU
> down entirely to prevent a catastrophic failure.
>


I've got Pentium-M at 2GHz and when fully loaded it heats up to 79
Celsius.  Could it be OK or do I have a faulty laptop ?

M.

_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Kevin Oberman]

> From: martinko <gamato@...>

> Date: Tue, 25 Sep 2007 20:35:44 +0200
> Sender: owner-freebsd-current@...
>
> Chuck Swiger wrote:
> >
> > The threshold temperature varies depending on the exact part, but is
> > generally around 65 Celsius-- and is hot enough that you don't really
> > want to encounter it in normal operation, as it's a sign that cooling is
> > not adequate for the system to continue to operate safely at full
> > speed.  Most of the Intel CPUs also include a second thermal circuit
> > called THERMTRIP which fires around 95 Celsius which will shut the CPU
> > down entirely to prevent a catastrophic failure.
> >
>
>
> I've got Pentium-M at 2GHz and when fully loaded it heats up to 79
> Celsius.  Could it be OK or do I have a faulty laptop ?

My Pentium-M 2GHz system will get well above 80C when doing big builds
and this is well below the defined PSV (94.5C) and CRT (99C)
levels. These things can run very hot and be perfectly happy.

OTOH, it might be time to clean the heatsink in the machine. That can
hurt heat transfer as a machine gets older.

FWIW, the spec on the Pentium-M 2GHZ system is 105C, so CRT at 99 looks
right.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@... Phone: [phone]
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

[martinko-5]

Kevin Oberman wrote:

>> From: martinko <gamato@...>
>> Date: Tue, 25 Sep 2007 20:35:44 +0200
>> Sender: owner-freebsd-current@...
>>
>> Chuck Swiger wrote:
>>    
>>> The threshold temperature varies depending on the exact part, but is
>>> generally around 65 Celsius-- and is hot enough that you don't really
>>> want to encounter it in normal operation, as it's a sign that cooling is
>>> not adequate for the system to continue to operate safely at full
>>> speed.  Most of the Intel CPUs also include a second thermal circuit
>>> called THERMTRIP which fires around 95 Celsius which will shut the CPU
>>> down entirely to prevent a catastrophic failure.
>>>
>>>      
>> I've got Pentium-M at 2GHz and when fully loaded it heats up to 79
>> Celsius.  Could it be OK or do I have a faulty laptop ?
>>    
>
> My Pentium-M 2GHz system will get well above 80C when doing big builds
> and this is well below the defined PSV (94.5C) and CRT (99C)
> levels. These things can run very hot and be perfectly happy.
>
> OTOH, it might be time to clean the heatsink in the machine. That can
> hurt heat transfer as a machine gets older.
>
> FWIW, the spec on the Pentium-M 2GHZ system is 105C, so CRT at 99 looks
> right.
>  

Mine says:

hw.acpi.thermal.tz0._PSV: 105.0C
hw.acpi.thermal.tz0._CRT: 110.0C

This is Asus W1N laptop.
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."

[Kevin Oberman]

> Date: Mon, 01 Oct 2007 19:34:56 +0200

> From: mato <gamato@...>
>
> Kevin Oberman wrote:
> >> From: martinko <gamato@...>
> >> Date: Tue, 25 Sep 2007 20:35:44 +0200
> >> Sender: owner-freebsd-current@...
> >>
> >> Chuck Swiger wrote:
> >>    
> >>> The threshold temperature varies depending on the exact part, but is
> >>> generally around 65 Celsius-- and is hot enough that you don't really
> >>> want to encounter it in normal operation, as it's a sign that cooling is
> >>> not adequate for the system to continue to operate safely at full
> >>> speed.  Most of the Intel CPUs also include a second thermal circuit
> >>> called THERMTRIP which fires around 95 Celsius which will shut the CPU
> >>> down entirely to prevent a catastrophic failure.
> >>>
> >>>      
> >> I've got Pentium-M at 2GHz and when fully loaded it heats up to 79
> >> Celsius.  Could it be OK or do I have a faulty laptop ?
> >>    
> >
> > My Pentium-M 2GHz system will get well above 80C when doing big builds
> > and this is well below the defined PSV (94.5C) and CRT (99C)
> > levels. These things can run very hot and be perfectly happy.
> >
> > OTOH, it might be time to clean the heatsink in the machine. That can
> > hurt heat transfer as a machine gets older.
> >
> > FWIW, the spec on the Pentium-M 2GHZ system is 105C, so CRT at 99 looks
> > right.
> >  
>
> Mine says:
>
> hw.acpi.thermal.tz0._PSV: 105.0C
> hw.acpi.thermal.tz0._CRT: 110.0C
>
> This is Asus W1N laptop.

I'm not about to start checking spec sheets for people. They are all
on-line. I assume that the ASUS W1N is not in the same processor family
as the Pentium-M 735, but I have no idea what it is. I don't even know
if it is Intel, AMD or VIA.

Looks like this one might require Kevlar pants if you put it on your
lap. Ouch! Of course, the external temperature of the unit will never
approach these temperatures.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@... Phone: [phone]
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

[martinko-5]

Kevin Oberman wrote:

>> Date: Mon, 01 Oct 2007 19:34:56 +0200
>> From: mato <gamato@...>
>>
>> Kevin Oberman wrote:
>>    
>>>> From: martinko <gamato@...>
>>>> Date: Tue, 25 Sep 2007 20:35:44 +0200
>>>> Sender: owner-freebsd-current@...
>>>>
>>>> Chuck Swiger wrote:
>>>>    
>>>>        
>>>>> The threshold temperature varies depending on the exact part, but is
>>>>> generally around 65 Celsius-- and is hot enough that you don't really
>>>>> want to encounter it in normal operation, as it's a sign that cooling is
>>>>> not adequate for the system to continue to operate safely at full
>>>>> speed.  Most of the Intel CPUs also include a second thermal circuit
>>>>> called THERMTRIP which fires around 95 Celsius which will shut the CPU
>>>>> down entirely to prevent a catastrophic failure.
>>>>>
>>>>>      
>>>>>          
>>>> I've got Pentium-M at 2GHz and when fully loaded it heats up to 79
>>>> Celsius.  Could it be OK or do I have a faulty laptop ?
>>>>    
>>>>        
>>> My Pentium-M 2GHz system will get well above 80C when doing big builds
>>> and this is well below the defined PSV (94.5C) and CRT (99C)
>>> levels. These things can run very hot and be perfectly happy.
>>>
>>> OTOH, it might be time to clean the heatsink in the machine. That can
>>> hurt heat transfer as a machine gets older.
>>>
>>> FWIW, the spec on the Pentium-M 2GHZ system is 105C, so CRT at 99 looks
>>> right.
>>>  
>>>      
>> Mine says:
>>
>> hw.acpi.thermal.tz0._PSV: 105.0C
>> hw.acpi.thermal.tz0._CRT: 110.0C
>>
>> This is Asus W1N laptop.
>>    
>
> I'm not about to start checking spec sheets for people. They are all
> on-line. I assume that the ASUS W1N is not in the same processor family
> as the Pentium-M 735, but I have no idea what it is. I don't even know
> if it is Intel, AMD or VIA.
>
> Looks like this one might require Kevlar pants if you put it on your
> lap. Ouch! Of course, the external temperature of the unit will never
> approach these temperatures.
>  

I didn't mean it.  I only provided my values since they differ from yours.
As I wrote I've got Intel Pentium M at 2 GHz, model 755 (Dothan).

Anyway, thanks for your feedback and please consider this thread closed.

M.
_______________________________________________
freebsd-current@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@..."