Date: Sat, 22 Aug 2009 08:50:23 +0200 From: Marc Balmer <marc@msys.ch> To: Gonzalo Nemmi <gnemmi@gmail.com> Cc: =?ISO-8859-1?Q?Aur=E9lien_M=E9r=E9?= <kindman@amc-os.com>, freebsd-hackers@FreeBSD.org, Oliver Pinter <oliver.pntr@gmail.com> Subject: Re: Common interface for sensors/health monitoring Message-ID: <2DC22872-96F5-4C0A-82E4-F9755A10E245@msys.ch> In-Reply-To: <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com> References: <D3D19C706C2842389C87590424D0A8CB@kmlaptop> <6101e8c40908211917k69c82491w3cff00a527d14873@mail.gmail.com> <19e9a5dc0908212303j28a6913er604bfd06e7df81ec@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 22.08.2009 um 08:03 schrieb Gonzalo Nemmi: > On Fri, Aug 21, 2009 at 11:17 PM, Oliver Pinter =20 > <oliver.pntr@gmail.com>wrote: > >> 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=3D\_SB_.PCI0.SBRG.ASOC >> dev.acpi_aiboost.0.%pnpinfo: _HID=3DATK0110 _UID=3D16843024 >> 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=E9lien M=E9r=E9 <kindman@amc-os.com> wrote: >>> Hi, >>> >>> I've been using FreeBSD for years in all my servers, but I'm =20 >>> facing a big >>> problem today. All servers are under monitoring using a couple of >>> applications and scripts. Monitored items for each server =20 >>> especially are >>> CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, =20 >>> PSU/UPS >>> voltages, HDD/RAID status&usage, network connectivity, UPS load, =20 >>> battery >>> status & runtime, ... >>> >>> My concern today, excepted that there is no way to gather all the =20= >>> data >>> through a unique interface and that consequently we have to change =20= >>> the >>> scripts depending on hardware, is that some information are no =20 >>> longer >>> available at all, especially concerning the MB IC, ie. temperatures, >>> voltages & fan speed. Actually, some SMBus controllers (like from =20= >>> 2006 or >>> so) are not supported by any driver and I didn't find any port =20 >>> updated to >>> access the IC directly (if even possible). Currently, I sometimes =20= >>> have to >>> use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes =20 >>> healthd >> and >>> sometimes nothing works (PR 137668 or 136762 as examples in my =20 >>> case). >>> >>> Besides that, I was quite surprised that these information are =20 >>> 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 =20= >>> that >> below >>> this presentation layer, this may be much less perfect, and by =20 >>> digging >> in, I >>> found that a 2007 GSoC project for porting the OpenBSD sensor =20 >>> framework >> was >>> realised and planned to be put in HEAD. I also read hundreds of =20 >>> mails >>> concerning this project, and why finally it was not commited. >>> >>> As developer, I fully understand some of the concerns in these =20 >>> threads >> and >>> that there are probably lots of things to change and work on, =20 >>> integrate >> it >>> in a cleaner repository like snmp or whatever; and I'd be glad to =20= >>> help in >>> any >>> possible way to improve this. But in the meantime, as netadmin, =20 >>> this kind >> of >>> information can be very important to prevent or diagnose major =20 >>> problems; >> so >>> I'd like to know what is being planned/done on this subject, as I =20= >>> didn't >>> find any >>> more information related to this than a discussion during bsdcan =20 >>> 2008. >>> >>> Thanks for your help and time, >>> Aur=E9lien >> > > +10 > > I was looking for the same info a time ago .. something that would =20 > allow me > to gather all the info from the same place, but the only thing I =20 > 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. =20 event capabilities like getting an event if a certain threshold is =20 exceeded. And it propbably was used for things that it better had not =20= (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 =20 tree to hack on... - Marc Balmer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2DC22872-96F5-4C0A-82E4-F9755A10E245>