Re: Common interface for sensors/health monitoring
Quoting Antony Mawer li...@mawer.org (from Mon, 24 Aug 2009 10:34:46 +1000): On Mon, Aug 24, 2009 at 2:38 AM, Marc Balmerm...@msys.ch wrote: Is there a summary (perhaps something suitable to go on the Project Ideas page) that outlines: - An outline of what such a system should provide - What it should NOT provide (ie. what would be out of scope) - What lessons should be learned from the SoC effort (ie. both good points and what NOT to do) - Suggested starting points There's nothing like this. The big controversy in the discussion is, that one party wants to put a lot of processing and logic into the kernel (IMO over-engineered), and the GSoC-party wants to keep this complexity out of the kernel (why doing stuff in the kernel when it can be done in the userland, there's no need to get the last few % of performance out of this). Other things discussed there (providing the data via sysctl or via a binary interface in /dev/) are minor implementation details which do not really matter that much (the argument of the GSoC-party was that we already have the sysctl interface and use it already for similar things like process monitoring (kern.proc.*), and it also usable in single-user mode without the need to write another decoding utility for this new binary data). Bye, Alexander. -- Computers are not intelligent. They only think they are. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
Am 23.08.2009 um 17:08 schrieb Alexander Leidinger:
On Sat, 22 Aug 2009 21:02:32 +0200 Aurélien Méré
aurelien.m...@amc-os.com wrote:
I'm just afraid by reading your email that the situation doesn't seem
to have evolved since the discussion regarding the SoC, maybe even
more taboo, and that I'll have to keep writing my own software and
drivers to get the data I want in the future if I want to get this
data under FreeBSD.. Is it the case ?
It is not taboo, it is just that nobody wants to spend his spare
time
with something like this now.
And yes, as far as I know you have to keep writting our own stuff. But
maybe we can set up a wiki page where people can share their
FreeBSD specific stuff. Someone just has to be willing to invest some
time to add stuff. I have a little script which adds 24 values to
ganglia, and it's extensible (4 lines for wach value), e.g.:
---snip---
metrics=${metrics} HD3_Temp
HD3_Temp_value=$(smartctl -A ad3 |awk '/Temperature_Celsius/ { print
$10 }') HD3_Temp_type=uint8
HD3_Temp_unit=Celsius
metrics=${metrics} logins
logins_value=$(who -q | grep users | cut -d ' ' -f 4)
logins_type=uint8
logins_unit=Users
metrics=${metrics} SwapIn
SwapIn_value=$(sysctl vm.stats.vm.v_swapin | cut -d ' ' -f 2)
SwapIn_type=uint32
SwapIn_unit=Units
---snip---
I would add my script to such a wiki page, if some else is willing to
start such a page.
sarcasm
such a script would indeed be much nicer than a well crafted framework
for the job.
/sarcasm
If someone not @FreeBSD.org wants to maintain such a page, feel free
to
register in the wiki and tell me (or another committer), I will hand
out
write permission then.
I hope people spend their time on thinking what was bad with the
sensor framework last time and improve on that, instead.
Bye,
Alexander.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
Am 23.08.2009 um 18:24 schrieb Alexander Leidinger:
On Sun, 23 Aug 2009 17:13:42 +0200 Marc Balmer m...@msys.ch wrote:
Am 23.08.2009 um 17:08 schrieb Alexander Leidinger:
On Sat, 22 Aug 2009 21:02:32 +0200 Aurélien Méré
aurelien.m...@amc-os.com wrote:
I'm just afraid by reading your email that the situation doesn't
seem to have evolved since the discussion regarding the SoC, maybe
even more taboo, and that I'll have to keep writing my own
software and drivers to get the data I want in the future if I
want to get this data under FreeBSD.. Is it the case ?
It is not taboo, it is just that nobody wants to spend his spare
time
with something like this now.
And yes, as far as I know you have to keep writting our own stuff.
But maybe we can set up a wiki page where people can share their
FreeBSD specific stuff. Someone just has to be willing to invest
some time to add stuff. I have a little script which adds 24 values
to ganglia, and it's extensible (4 lines for wach value), e.g.:
---snip---
metrics=${metrics} HD3_Temp
HD3_Temp_value=$(smartctl -A ad3 |awk '/Temperature_Celsius/
{ print $10 }') HD3_Temp_type=uint8
HD3_Temp_unit=Celsius
metrics=${metrics} logins
logins_value=$(who -q | grep users | cut -d ' ' -f 4)
logins_type=uint8
logins_unit=Users
metrics=${metrics} SwapIn
SwapIn_value=$(sysctl vm.stats.vm.v_swapin | cut -d ' ' -f 2)
SwapIn_type=uint32
SwapIn_unit=Units
---snip---
I would add my script to such a wiki page, if some else is willing
to start such a page.
sarcasm
such a script would indeed be much nicer than a well crafted
framework for the job.
/sarcasm
Indeed...
If someone not @FreeBSD.org wants to maintain such a page, feel
free to
register in the wiki and tell me (or another committer), I will
hand out
write permission then.
I hope people spend their time on thinking what was bad with the
sensor framework last time and improve on that, instead.
Go and read in the archives about it, maybe you understand why
there's not much motivation to spend spare time on such a topic.
Everyone should have the right to come back with a subject, if work is
put into it. Or is the stanza that once there has been a heated
discussion about a topic, there is no possibility to come back to it,
maybe making it better a seccond time? And no, I have no plans to do
so... I am just a bit astonished about the attitude...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Sat, 22 Aug 2009 21:02:32 +0200 Aurélien Méré
aurelien.m...@amc-os.com wrote:
I'm just afraid by reading your email that the situation doesn't seem
to have evolved since the discussion regarding the SoC, maybe even
more taboo, and that I'll have to keep writing my own software and
drivers to get the data I want in the future if I want to get this
data under FreeBSD.. Is it the case ?
It is not taboo, it is just that nobody wants to spend his spare time
with something like this now.
And yes, as far as I know you have to keep writting our own stuff. But
maybe we can set up a wiki page where people can share their
FreeBSD specific stuff. Someone just has to be willing to invest some
time to add stuff. I have a little script which adds 24 values to
ganglia, and it's extensible (4 lines for wach value), e.g.:
---snip---
metrics=${metrics} HD3_Temp
HD3_Temp_value=$(smartctl -A ad3 |awk '/Temperature_Celsius/ { print
$10 }') HD3_Temp_type=uint8
HD3_Temp_unit=Celsius
metrics=${metrics} logins
logins_value=$(who -q | grep users | cut -d ' ' -f 4)
logins_type=uint8
logins_unit=Users
metrics=${metrics} SwapIn
SwapIn_value=$(sysctl vm.stats.vm.v_swapin | cut -d ' ' -f 2)
SwapIn_type=uint32
SwapIn_unit=Units
---snip---
I would add my script to such a wiki page, if some else is willing to
start such a page.
If someone not @FreeBSD.org wants to maintain such a page, feel free to
register in the wiki and tell me (or another committer), I will hand out
write permission then.
Bye,
Alexander.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Sun, 23 Aug 2009 17:13:42 +0200 Marc Balmer m...@msys.ch wrote:
Am 23.08.2009 um 17:08 schrieb Alexander Leidinger:
On Sat, 22 Aug 2009 21:02:32 +0200 Aurélien Méré
aurelien.m...@amc-os.com wrote:
I'm just afraid by reading your email that the situation doesn't
seem to have evolved since the discussion regarding the SoC, maybe
even more taboo, and that I'll have to keep writing my own
software and drivers to get the data I want in the future if I
want to get this data under FreeBSD.. Is it the case ?
It is not taboo, it is just that nobody wants to spend his spare
time
with something like this now.
And yes, as far as I know you have to keep writting our own stuff.
But maybe we can set up a wiki page where people can share their
FreeBSD specific stuff. Someone just has to be willing to invest
some time to add stuff. I have a little script which adds 24 values
to ganglia, and it's extensible (4 lines for wach value), e.g.:
---snip---
metrics=${metrics} HD3_Temp
HD3_Temp_value=$(smartctl -A ad3 |awk '/Temperature_Celsius/
{ print $10 }') HD3_Temp_type=uint8
HD3_Temp_unit=Celsius
metrics=${metrics} logins
logins_value=$(who -q | grep users | cut -d ' ' -f 4)
logins_type=uint8
logins_unit=Users
metrics=${metrics} SwapIn
SwapIn_value=$(sysctl vm.stats.vm.v_swapin | cut -d ' ' -f 2)
SwapIn_type=uint32
SwapIn_unit=Units
---snip---
I would add my script to such a wiki page, if some else is willing
to start such a page.
sarcasm
such a script would indeed be much nicer than a well crafted
framework for the job.
/sarcasm
Indeed...
If someone not @FreeBSD.org wants to maintain such a page, feel
free to
register in the wiki and tell me (or another committer), I will
hand out
write permission then.
I hope people spend their time on thinking what was bad with the
sensor framework last time and improve on that, instead.
Go and read in the archives about it, maybe you understand why
there's not much motivation to spend spare time on such a topic.
Bye,
Alexander.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Sun, Aug 23, 2009 at 06:38:12PM +0200, Marc Balmer wrote: Everyone should have the right to come back with a subject, if work is put into it. Or is the stanza that once there has been a heated discussion about a topic, there is no possibility to come back to it, maybe making it better a seccond time? And no, I have no plans to do so... I am just a bit astonished about the attitude... I think what Alexander was trying to say was that, given the heated discussion last time, people are now reluctant to restart another discussion. From what I remember, it was very hard to understand why such a large number of messages was being created for such a small detail. Topics, such as these, pose a high risk of making your FreeBSD developer experience more painful than it should be. And since I believe a lot of people here like to work on FreeBSD, sometimes these types of discussions are avoided for a long time just because the developer(s) doesn't(don't) want to make their FreeBSD development experience any more painful. I believe that if we keep insisting on the same bikesheds for a long time, developers will defintely go away. So, there's no ``stanza'' or whatever, just human nature. Regardless of what I just said, the topic keeps coming back and that's a clear sign that a framework should be developed and, possibly, in a way that appeals to both parties. -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Mon, Aug 24, 2009 at 2:38 AM, Marc Balmerm...@msys.ch wrote: Am 23.08.2009 um 18:24 schrieb Alexander Leidinger: On Sun, 23 Aug 2009 17:13:42 +0200 Marc Balmer m...@msys.ch wrote: Am 23.08.2009 um 17:08 schrieb Alexander Leidinger: On Sat, 22 Aug 2009 21:02:32 +0200 Aurélien Méré aurelien.m...@amc-os.com wrote: I'm just afraid by reading your email that the situation doesn't seem to have evolved since the discussion regarding the SoC, maybe even more taboo, and that I'll have to keep writing my own software and drivers to get the data I want in the future if I want to get this data under FreeBSD.. Is it the case ? It is not taboo, it is just that nobody wants to spend his spare time with something like this now. I hope people spend their time on thinking what was bad with the sensor framework last time and improve on that, instead. Go and read in the archives about it, maybe you understand why there's not much motivation to spend spare time on such a topic. Everyone should have the right to come back with a subject, if work is put into it. Or is the stanza that once there has been a heated discussion about a topic, there is no possibility to come back to it, maybe making it better a seccond time? And no, I have no plans to do so... I am just a bit astonished about the attitude... I for one would be quite happy to contribute towards such an effort. I would much rather contribute towards a project-wide monitoring solution rather than continuing to extend/maintain my own ad-hoc monitoring scripts. I am sure many others are in a similar position... it seems crazy that we are all re-inventing the wheel instead of contributing to a common effort. Is there a summary (perhaps something suitable to go on the Project Ideas page) that outlines: - An outline of what such a system should provide - What it should NOT provide (ie. what would be out of scope) - What lessons should be learned from the SoC effort (ie. both good points and what NOT to do) - Suggested starting points Maybe that would go a long way to ensuring anyone wanting to start such an effort without getting to the end and having their efforts rejected... Yes, bits of this can be found in the past mailing list posts, but it would nice to have an clear official summary of this so that any volunteer effort has the best chance of being accepted... -- Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Fri, Aug 21, 2009 at 11:17 PM, Oliver Pinter oliver.p...@gmail.comwrote: Hello! When I good know, no common interface exisit in current freebsd kernel, but some other sysctl interfece exisit: coretemp, aiboost ... ~ sysctl dev.coretemp dev.coretemp.0.%desc: CPU On-Die Thermal Sensors dev.coretemp.0.%driver: coretemp dev.coretemp.0.%parent: cpu0 dev.coretemp.1.%desc: CPU On-Die Thermal Sensors dev.coretemp.1.%driver: coretemp dev.coretemp.1.%parent: cpu1 dev.coretemp.2.%desc: CPU On-Die Thermal Sensors dev.coretemp.2.%driver: coretemp dev.coretemp.2.%parent: cpu2 dev.coretemp.3.%desc: CPU On-Die Thermal Sensors dev.coretemp.3.%driver: coretemp dev.coretemp.3.%parent: cpu3 ~ sysctl dev.acpi_aiboost dev.acpi_aiboost.0.%desc: ASUStek AIBOOSTER dev.acpi_aiboost.0.%driver: acpi_aiboost dev.acpi_aiboost.0.%location: handle=\_SB_.PCI0.SBRG.ASOC dev.acpi_aiboost.0.%pnpinfo: _HID=ATK0110 _UID=16843024 dev.acpi_aiboost.0.%parent: acpi0 dev.acpi_aiboost.0.temp0: 190 dev.acpi_aiboost.0.temp1: 300 dev.acpi_aiboost.0.volt0: 1144 dev.acpi_aiboost.0.volt1: 3328 dev.acpi_aiboost.0.volt2: 5064 dev.acpi_aiboost.0.volt3: 12096 dev.acpi_aiboost.0.fan0: 1962 dev.acpi_aiboost.0.fan1: 1180 dev.acpi_aiboost.0.fan2: 1278 dev.acpi_aiboost.0.fan3: 0 dev.acpi_aiboost.0.fan4: 0 but no common if.. Is there an acpi_dell or something like that? On 8/22/09, Aurélien Méré kind...@amc-os.com wrote: Hi, I've been using FreeBSD for years in all my servers, but I'm facing a big problem today. All servers are under monitoring using a couple of applications and scripts. Monitored items for each server especially are CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS voltages, HDD/RAID statususage, network connectivity, UPS load, battery status runtime, ... My concern today, excepted that there is no way to gather all the data through a unique interface and that consequently we have to change the scripts depending on hardware, is that some information are no longer available at all, especially concerning the MB IC, ie. temperatures, voltages fan speed. Actually, some SMBus controllers (like from 2006 or so) are not supported by any driver and I didn't find any port updated to access the IC directly (if even possible). Currently, I sometimes have to use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and sometimes nothing works (PR 137668 or 136762 as examples in my case). Besides that, I was quite surprised that these information are available in OpenBSD through a very simple and unique sysctl interface, with up-to-date drivers, working on all my servers with a generic install. I know that below this presentation layer, this may be much less perfect, and by digging in, I found that a 2007 GSoC project for porting the OpenBSD sensor framework was realised and planned to be put in HEAD. I also read hundreds of mails concerning this project, and why finally it was not commited. As developer, I fully understand some of the concerns in these threads and that there are probably lots of things to change and work on, integrate it in a cleaner repository like snmp or whatever; and I'd be glad to help in any possible way to improve this. But in the meantime, as netadmin, this kind of information can be very important to prevent or diagnose major problems; so I'd like to know what is being planned/done on this subject, as I didn't find any more information related to this than a discussion during bsdcan 2008. Thanks for your help and time, Aurélien +10 I was looking for the same info a time ago .. something that would allow me to gather all the info from the same place, but the only thing I came up with was the very same discussion about the sensors framework port and nothing else. Any info on any such proyect will be greatly apreciated Regards ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
Aurélien Méré wrote: Hi, I've been using FreeBSD for years in all my servers, but I'm facing a big problem today. All servers are under monitoring using a couple of applications and scripts. Monitored items for each server especially are CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS voltages, HDD/RAID statususage, network connectivity, UPS load, battery status runtime, ... My concern today, excepted that there is no way to gather all the data through a unique interface and that consequently we have to change the scripts depending on hardware, is that some information are no longer available at all, especially concerning the MB IC, ie. temperatures, voltages fan speed. Actually, some SMBus controllers (like from 2006 or so) are not supported by any driver and I didn't find any port updated to access the IC directly (if even possible). Currently, I sometimes have to use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and sometimes nothing works (PR 137668 or 136762 as examples in my case). Besides that, I was quite surprised that these information are available in OpenBSD through a very simple and unique sysctl interface, with up-to-date drivers, working on all my servers with a generic install. I know that below this presentation layer, this may be much less perfect, and by digging in, I found that a 2007 GSoC project for porting the OpenBSD sensor framework was realised and planned to be put in HEAD. I also read hundreds of mails concerning this project, and why finally it was not commited. As developer, I fully understand some of the concerns in these threads and that there are probably lots of things to change and work on, integrate it in a cleaner repository like snmp or whatever; and I'd be glad to help in any possible way to improve this. But in the meantime, as netadmin, this kind of information can be very important to prevent or diagnose major problems; so I'd like to know what is being planned/done on this subject, as I didn't find any more information related to this than a discussion during bsdcan 2008. The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. Thanks for your help and time, Aurélien ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
Am 22.08.2009 um 08:03 schrieb Gonzalo Nemmi: On Fri, Aug 21, 2009 at 11:17 PM, Oliver Pinter oliver.p...@gmail.comwrote: Hello! When I good know, no common interface exisit in current freebsd kernel, but some other sysctl interfece exisit: coretemp, aiboost ... ~ sysctl dev.coretemp dev.coretemp.0.%desc: CPU On-Die Thermal Sensors dev.coretemp.0.%driver: coretemp dev.coretemp.0.%parent: cpu0 dev.coretemp.1.%desc: CPU On-Die Thermal Sensors dev.coretemp.1.%driver: coretemp dev.coretemp.1.%parent: cpu1 dev.coretemp.2.%desc: CPU On-Die Thermal Sensors dev.coretemp.2.%driver: coretemp dev.coretemp.2.%parent: cpu2 dev.coretemp.3.%desc: CPU On-Die Thermal Sensors dev.coretemp.3.%driver: coretemp dev.coretemp.3.%parent: cpu3 ~ sysctl dev.acpi_aiboost dev.acpi_aiboost.0.%desc: ASUStek AIBOOSTER dev.acpi_aiboost.0.%driver: acpi_aiboost dev.acpi_aiboost.0.%location: handle=\_SB_.PCI0.SBRG.ASOC dev.acpi_aiboost.0.%pnpinfo: _HID=ATK0110 _UID=16843024 dev.acpi_aiboost.0.%parent: acpi0 dev.acpi_aiboost.0.temp0: 190 dev.acpi_aiboost.0.temp1: 300 dev.acpi_aiboost.0.volt0: 1144 dev.acpi_aiboost.0.volt1: 3328 dev.acpi_aiboost.0.volt2: 5064 dev.acpi_aiboost.0.volt3: 12096 dev.acpi_aiboost.0.fan0: 1962 dev.acpi_aiboost.0.fan1: 1180 dev.acpi_aiboost.0.fan2: 1278 dev.acpi_aiboost.0.fan3: 0 dev.acpi_aiboost.0.fan4: 0 but no common if.. Is there an acpi_dell or something like that? On 8/22/09, Aurélien Méré kind...@amc-os.com wrote: Hi, I've been using FreeBSD for years in all my servers, but I'm facing a big problem today. All servers are under monitoring using a couple of applications and scripts. Monitored items for each server especially are CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS voltages, HDD/RAID statususage, network connectivity, UPS load, battery status runtime, ... My concern today, excepted that there is no way to gather all the data through a unique interface and that consequently we have to change the scripts depending on hardware, is that some information are no longer available at all, especially concerning the MB IC, ie. temperatures, voltages fan speed. Actually, some SMBus controllers (like from 2006 or so) are not supported by any driver and I didn't find any port updated to access the IC directly (if even possible). Currently, I sometimes have to use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and sometimes nothing works (PR 137668 or 136762 as examples in my case). Besides that, I was quite surprised that these information are available in OpenBSD through a very simple and unique sysctl interface, with up-to-date drivers, working on all my servers with a generic install. I know that below this presentation layer, this may be much less perfect, and by digging in, I found that a 2007 GSoC project for porting the OpenBSD sensor framework was realised and planned to be put in HEAD. I also read hundreds of mails concerning this project, and why finally it was not commited. As developer, I fully understand some of the concerns in these threads and that there are probably lots of things to change and work on, integrate it in a cleaner repository like snmp or whatever; and I'd be glad to help in any possible way to improve this. But in the meantime, as netadmin, this kind of information can be very important to prevent or diagnose major problems; so I'd like to know what is being planned/done on this subject, as I didn't find any more information related to this than a discussion during bsdcan 2008. Thanks for your help and time, Aurélien +10 I was looking for the same info a time ago .. something that would allow me to gather all the info from the same place, but the only thing I came up with was the very same discussion about the sensors framework port and nothing else. Any info on any such proyect will be greatly apreciated The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had not (yes, I am culprit for on of these (ab)uses...). I am sure these features could be added if only the code was in the tree to hack on... - Marc Balmer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Sat, 22 Aug 2009, Marc Balmer wrote: I was looking for the same info a time ago .. something that would allow me to gather all the info from the same place, but the only thing I came up with was the very same discussion about the sensors framework port and nothing else. Any info on any such proyect will be greatly apreciated The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had not (yes, I am culprit for on of these (ab)uses...). I am sure these features could be added if only the code was in the tree to hack on... One of the things I'd particularly like to see is an alignment between kernel/user level monitoring frameworks and the SNMP model (especially relating to traps). The SNMP information model (MIBs, agents, traps, etc) has its limitations, but having a compatible model at all layers of the system will make it easier to store, manipulate, manage, and report this information consistently throughout the OS and larger distributed systems. Robert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Sat, 22 Aug 2009 08:50:23 +0200 Marc Balmer m...@msys.ch wrote: The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had This assumes the kernel is monitoring the device periodically (in the general case, as there are a lot of dump sensors which do not send events on their own). The framework as in the SoC did not provide this feature to keep the kernel part simple. You want to see a value, you poll the kernel for it, and the userland would have been responsible to fire up an event. For smart sensors which trigger an event on their own (interrupt), you can use the exiting kernel event framework (and the idea in the SoC was to use it for such sensors). The devd is the userland side of it. not (yes, I am culprit for on of these (ab)uses...). I am sure these features could be added if only the code was in the tree to hack on... The event stuff is in the kernel, go ahead and write a driver for your smart sensor which fires events on its own. Bye, Alexander. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer jul...@elischer.org wrote: The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. Bye, Alexander. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
Am 22.08.2009 um 18:29 schrieb Alexander Leidinger: On Sat, 22 Aug 2009 08:50:23 +0200 Marc Balmer m...@msys.ch wrote: The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had This assumes the kernel is monitoring the device periodically (in the general case, as there are a lot of dump sensors which do not send events on their own). The framework as in the SoC did not provide this feature to keep the kernel part simple. You want to see a value, you poll the kernel for it, and the userland would have been responsible to fire up an event. For smart sensors which trigger an event on their own (interrupt), you can use the exiting kernel event framework (and the idea in the SoC was to use it for such sensors). The devd is the userland side of it. not (yes, I am culprit for on of these (ab)uses...). I am sure these features could be added if only the code was in the tree to hack on... The event stuff is in the kernel, go ahead and write a driver for your smart sensor which fires events on its own. Well, most of the sensors are likely I2C or 1-Wire devices and these can only be polled. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
* Alexander Leidinger alexan...@leidinger.net [090822 10:44] wrote: On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer jul...@elischer.org wrote: The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. I say good riddence, if someone wants thier hardware not to melt then each machine should be personally responsible and enroll in a private monitoring service we don't need project sponsored health monitoring. (ron paul!) -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
Alfred Perlstein wrote: * Alexander Leidinger alexan...@leidinger.net [090822 10:44] wrote: On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer jul...@elischer.org wrote: The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. I say good riddence, if someone wants thier hardware not to melt then each machine should be personally responsible and enroll in a private monitoring service we don't need project sponsored health monitoring. (ron paul!) I think that this kind of talk calls for boycotting certain device drivers! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
Stephen Montgomery-Smith wrote: Alfred Perlstein wrote: * Alexander Leidinger alexan...@leidinger.net [090822 10:44] wrote: On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer jul...@elischer.org wrote: The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. I say good riddence, if someone wants thier hardware not to melt then each machine should be personally responsible and enroll in a private monitoring service we don't need project sponsored health monitoring. (ron paul!) I think that this kind of talk calls for boycotting certain device drivers! In OpenBSD they have project sponsored healthware and sometimes you have to wait in a queue to get you notifications, and sometimes the queue is so long events have to get merged! Not for me! I want all my individual events to be lost After I get them. It's my right! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had This assumes the kernel is monitoring the device periodically (in the general case, as there are a lot of dump sensors which do not send events on their own). The framework as in the SoC did not provide this feature to keep the kernel part simple. You want to see a value, you poll the kernel for it, and the userland would have been responsible to fire up an event. In my pratical case, this is perfectly satisfying. Probably most of the controllers I work with don't even support event triggering, and we already have the scripts to trigger events depending on the polled values. I'm worried that today drivers don't exist or don't seem to be maintained to provide these values. So, I would be satisfied just by getting the values. I would be very satisfied if it was in a common interface. Heaven with triggers... I'm just afraid by reading your email that the situation doesn't seem to have evolved since the discussion regarding the SoC, maybe even more taboo, and that I'll have to keep writing my own software and drivers to get the data I want in the future if I want to get this data under FreeBSD.. Is it the case ? Thx Aurélien ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Sat, 22 Aug 2009, Julian Elischer wrote: Stephen Montgomery-Smith wrote: Alfred Perlstein wrote: * Alexander Leidinger alexan...@leidinger.net [090822 10:44] wrote: On Sat, 22 Aug 2009 00:04:10 -0700 Julian Elischer jul...@elischer.org wrote: The purists won out in that one by shouting loudly and screaming about socialized healthware. Consequently we have 47 million unsupported devices. You forgot to tell that now nobody wants to touch this subject anymore, as he may be the target of similar shouting then. I say good riddence, if someone wants thier hardware not to melt then each machine should be personally responsible and enroll in a private monitoring service we don't need project sponsored health monitoring. (ron paul!) I think that this kind of talk calls for boycotting certain device drivers! In OpenBSD they have project sponsored healthware and sometimes you have to wait in a queue to get you notifications, and sometimes the queue is so long events have to get merged! Not for me! I want all my individual events to be lost After I get them. It's my right! Perhaps you are getting too much information through the cable network. Your system might be getting all wee weed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
As terribly clever as you all are, can you please restrict the political commentary/humor/whatever to -chat? Thanks, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Common interface for sensors/health monitoring
Hi, I've been using FreeBSD for years in all my servers, but I'm facing a big problem today. All servers are under monitoring using a couple of applications and scripts. Monitored items for each server especially are CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS voltages, HDD/RAID statususage, network connectivity, UPS load, battery status runtime, ... My concern today, excepted that there is no way to gather all the data through a unique interface and that consequently we have to change the scripts depending on hardware, is that some information are no longer available at all, especially concerning the MB IC, ie. temperatures, voltages fan speed. Actually, some SMBus controllers (like from 2006 or so) are not supported by any driver and I didn't find any port updated to access the IC directly (if even possible). Currently, I sometimes have to use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and sometimes nothing works (PR 137668 or 136762 as examples in my case). Besides that, I was quite surprised that these information are available in OpenBSD through a very simple and unique sysctl interface, with up-to-date drivers, working on all my servers with a generic install. I know that below this presentation layer, this may be much less perfect, and by digging in, I found that a 2007 GSoC project for porting the OpenBSD sensor framework was realised and planned to be put in HEAD. I also read hundreds of mails concerning this project, and why finally it was not commited. As developer, I fully understand some of the concerns in these threads and that there are probably lots of things to change and work on, integrate it in a cleaner repository like snmp or whatever; and I'd be glad to help in any possible way to improve this. But in the meantime, as netadmin, this kind of information can be very important to prevent or diagnose major problems; so I'd like to know what is being planned/done on this subject, as I didn't find any more information related to this than a discussion during bsdcan 2008. Thanks for your help and time, Aurélien ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
Hello! When I good know, no common interface exisit in current freebsd kernel, but some other sysctl interfece exisit: coretemp, aiboost ... ~ sysctl dev.coretemp dev.coretemp.0.%desc: CPU On-Die Thermal Sensors dev.coretemp.0.%driver: coretemp dev.coretemp.0.%parent: cpu0 dev.coretemp.1.%desc: CPU On-Die Thermal Sensors dev.coretemp.1.%driver: coretemp dev.coretemp.1.%parent: cpu1 dev.coretemp.2.%desc: CPU On-Die Thermal Sensors dev.coretemp.2.%driver: coretemp dev.coretemp.2.%parent: cpu2 dev.coretemp.3.%desc: CPU On-Die Thermal Sensors dev.coretemp.3.%driver: coretemp dev.coretemp.3.%parent: cpu3 ~ sysctl dev.acpi_aiboost dev.acpi_aiboost.0.%desc: ASUStek AIBOOSTER dev.acpi_aiboost.0.%driver: acpi_aiboost dev.acpi_aiboost.0.%location: handle=\_SB_.PCI0.SBRG.ASOC dev.acpi_aiboost.0.%pnpinfo: _HID=ATK0110 _UID=16843024 dev.acpi_aiboost.0.%parent: acpi0 dev.acpi_aiboost.0.temp0: 190 dev.acpi_aiboost.0.temp1: 300 dev.acpi_aiboost.0.volt0: 1144 dev.acpi_aiboost.0.volt1: 3328 dev.acpi_aiboost.0.volt2: 5064 dev.acpi_aiboost.0.volt3: 12096 dev.acpi_aiboost.0.fan0: 1962 dev.acpi_aiboost.0.fan1: 1180 dev.acpi_aiboost.0.fan2: 1278 dev.acpi_aiboost.0.fan3: 0 dev.acpi_aiboost.0.fan4: 0 but no common if.. On 8/22/09, Aurélien Méré kind...@amc-os.com wrote: Hi, I've been using FreeBSD for years in all my servers, but I'm facing a big problem today. All servers are under monitoring using a couple of applications and scripts. Monitored items for each server especially are CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS voltages, HDD/RAID statususage, network connectivity, UPS load, battery status runtime, ... My concern today, excepted that there is no way to gather all the data through a unique interface and that consequently we have to change the scripts depending on hardware, is that some information are no longer available at all, especially concerning the MB IC, ie. temperatures, voltages fan speed. Actually, some SMBus controllers (like from 2006 or so) are not supported by any driver and I didn't find any port updated to access the IC directly (if even possible). Currently, I sometimes have to use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and sometimes nothing works (PR 137668 or 136762 as examples in my case). Besides that, I was quite surprised that these information are available in OpenBSD through a very simple and unique sysctl interface, with up-to-date drivers, working on all my servers with a generic install. I know that below this presentation layer, this may be much less perfect, and by digging in, I found that a 2007 GSoC project for porting the OpenBSD sensor framework was realised and planned to be put in HEAD. I also read hundreds of mails concerning this project, and why finally it was not commited. As developer, I fully understand some of the concerns in these threads and that there are probably lots of things to change and work on, integrate it in a cleaner repository like snmp or whatever; and I'd be glad to help in any possible way to improve this. But in the meantime, as netadmin, this kind of information can be very important to prevent or diagnose major problems; so I'd like to know what is being planned/done on this subject, as I didn't find any more information related to this than a discussion during bsdcan 2008. Thanks for your help and time, Aurélien ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
