Hello everyone,
I'm unable to read temperature Gigabyte H77-DH3H motherboard. Is that
motherboard supported or am I doing it incorrectly?
When trying to access hw.acpi.thermal everything appears to be ok, but
it is not, the system always returns 27,8C and 29,8C which fooled me
initially - the values never change.
Here is output:
[chinatsu]:/root# sysctl hw.acpi.thermal
hw.acpi.thermal.min_runtime: 0
hw.acpi.thermal.polling_rate: 10
hw.acpi.thermal.user_override: 0
hw.acpi.thermal.tz0.temperature: 27,8C
hw.acpi.thermal.tz0.active: 2
hw.acpi.thermal.tz0.passive_cooling: 0
hw.acpi.thermal.tz0.thermal_flags: 0
hw.acpi.thermal.tz0._PSV: -1
hw.acpi.thermal.tz0._HOT: -1
hw.acpi.thermal.tz0._CRT: 106,0C
hw.acpi.thermal.tz0._ACx: 85,0C 55,0C 0,0C 0,0C 0,0C -1 -1 -1 -1 -1
hw.acpi.thermal.tz0._TC1: -1
hw.acpi.thermal.tz0._TC2: -1
hw.acpi.thermal.tz0._TSP: -1
hw.acpi.thermal.tz1.temperature: 29,8C
hw.acpi.thermal.tz1.active: -1
hw.acpi.thermal.tz1.passive_cooling: 1
hw.acpi.thermal.tz1.thermal_flags: 0
hw.acpi.thermal.tz1._PSV: 106,0C
hw.acpi.thermal.tz1._HOT: -1
hw.acpi.thermal.tz1._CRT: 106,0C
hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
hw.acpi.thermal.tz1._TC1: 1
hw.acpi.thermal.tz1._TC2: 5
hw.acpi.thermal.tz1._TSP: 10
Since above method fails, I decided to try motherboard monitors in
ports. It seems that almost all of them rely on /dev/smb device.
After loading smb and ichsmb (seems like ichsmb is the only driver
that causes /dev/smb0) any access to /dev/smb0 returns "Device
not configured". For example:
[chinatsu]:/root# lmmon
IOCTL: Device not configured
Similarly mbmon fails:
[chinatsu]:/root# mbmon -V
No VIA686 HWM available!!
InitMBInfo: No error: 0
Exit 1
[chinatsu]:/root# mbmon -S
No SMBus HWM available!!
InitMBInfo: No error: 0
Exit 1
[chinatsu]:/root# mbmon -I
No ISA-IO HWM available!!
InitMBInfo: No error: 0
Exit 1
[chinatsu]:/root# mbmon -A
InitMBInfo: No error: 0
This program needs "setuid root"!!
Exit 1
Here's output of pciconf:
[chinatsu]:/root# pciconf -lv
hostb0 at pci0:0:0:0: class=0x060000 card=0x50001458 chip=0x01508086
rev=0x09 hdr=0x00
vendor = 'Intel Corporation'
device = 'Ivy Bridge DRAM Controller'
class = bridge
subclass = HOST-PCI
vgapci0 at pci0:0:2:0: class=0x030000 card=0xd0001458 chip=0x01528086
rev=0x09 hdr=0x00
vendor = 'Intel Corporation'
device = 'Ivy Bridge Graphics Controller'
class = display
subclass = VGA
xhci0 at pci0:0:20:0: class=0x0c0330 card=0x50071458 chip=0x1e318086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point USB xHCI Host Controller'
class = serial bus
subclass = USB
none0 at pci0:0:22:0: class=0x078000 card=0x1c3a1458 chip=0x1e3a8086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point MEI Controller'
class = simple comms
ehci0 at pci0:0:26:0: class=0x0c0320 card=0x50061458 chip=0x1e2d8086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point USB Enhanced Host Controller'
class = serial bus
subclass = USB
pcib1 at pci0:0:28:0: class=0x060400 card=0x50011458 chip=0x1e108086
rev=0xc4 hdr=0x01
vendor = 'Intel Corporation'
device = 'Panther Point PCI Express Root Port 1'
class = bridge
subclass = PCI-PCI
pcib2 at pci0:0:28:2: class=0x060400 card=0x50011458 chip=0x1e148086
rev=0xc4 hdr=0x01
vendor = 'Intel Corporation'
device = 'Panther Point PCI Express Root Port 3'
class = bridge
subclass = PCI-PCI
pcib3 at pci0:0:28:3: class=0x060401 card=0x50011458 chip=0x244e8086
rev=0xc4 hdr=0x01
vendor = 'Intel Corporation'
device = '82801 PCI Bridge'
class = bridge
subclass = PCI-PCI
ehci1 at pci0:0:29:0: class=0x0c0320 card=0x50061458 chip=0x1e268086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point USB Enhanced Host Controller'
class = serial bus
subclass = USB
isab0 at pci0:0:31:0: class=0x060100 card=0x50011458 chip=0x1e4a8086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point LPC Controller'
class = bridge
subclass = PCI-ISA
ahci0 at pci0:0:31:2: class=0x010601 card=0xb0051458 chip=0x1e028086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point 6 port SATA AHCI Controller'
class = mass storage
subclass = SATA
ichsmb0 at pci0:0:31:3: class=0x0c0500 card=0x50011458 chip=0x1e228086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point SMBus Controller'
class = serial bus
subclass = SMBus
alc0 at pci0:2:0:0: class=0x020000 card=0xe0001458 chip=0x10831969
rev=0xc0 hdr=0x00
vendor = 'Atheros Communications'
device = 'AR8151 v2.0 Gigabit Ethernet'
class = network
subclass = ethernet
pcib4 at pci0:3:0:0: class=0x060401 card=0x88921458 chip=0x244e8086
rev=0x41 hdr=0x01
vendor = 'Intel Corporation'
device = '82801 PCI Bridge'
class = bridge
subclass = PCI-PCI
em0 at pci0:4:1:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05
hdr=0x00
vendor = 'Intel Corporation'
device = '82541PI Gigabit Ethernet Controller'
class = network
subclass = ethernet
--
Best regards,
Derek mailto:takeda at takeda.tk
Never underestimate the bandwidth of a station wagon full of tapes hurling down
the highway
on 17/10/2012 23:15 Derek Kulinski said the following:> Hello everyone, > > I'm unable to read temperature Gigabyte H77-DH3H motherboard. Is that > motherboard supported or am I doing it incorrectly? > > When trying to access hw.acpi.thermal everything appears to be ok, but > it is not, the system always returns 27,8C and 29,8C which fooled me > initially - the values never change.I've found that on quite a few modern systems the ACPI platform advertises some useless thermal zones, which always return some hardcoded temperatures. E.g. I have Asus P8Z77-M PRO near me and it also reports two thermal zones. Looking at DSDT (acpidump -dt) I see that the temperatures are hardcoded. It seems that your motherboard has an ITE Super I/O with hardware monitoring function. I am not sure which model though... Your best bet would be it(4) driver, but it is not committed yet. If you are into some mild hacking (applying patches, building custom kernel), then I can point you to the patches. Although I can not give a firm guarantee that the driver supports your HWM chip, since I don't know the model.> Here is output: > [chinatsu]:/root# sysctl hw.acpi.thermal > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 27,8C > hw.acpi.thermal.tz0.active: 2 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 106,0C > hw.acpi.thermal.tz0._ACx: 85,0C 55,0C 0,0C 0,0C 0,0C -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: -1 > hw.acpi.thermal.tz0._TC2: -1 > hw.acpi.thermal.tz0._TSP: -1 > hw.acpi.thermal.tz1.temperature: 29,8C > hw.acpi.thermal.tz1.active: -1 > hw.acpi.thermal.tz1.passive_cooling: 1 > hw.acpi.thermal.tz1.thermal_flags: 0 > hw.acpi.thermal.tz1._PSV: 106,0C > hw.acpi.thermal.tz1._HOT: -1 > hw.acpi.thermal.tz1._CRT: 106,0C > hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz1._TC1: 1 > hw.acpi.thermal.tz1._TC2: 5 > hw.acpi.thermal.tz1._TSP: 10 > > Since above method fails, I decided to try motherboard monitors in > ports. It seems that almost all of them rely on /dev/smb device. > > After loading smb and ichsmb (seems like ichsmb is the only driver > that causes /dev/smb0) any access to /dev/smb0 returns "Device > not configured". For example: > > [chinatsu]:/root# lmmon > IOCTL: Device not configured > > Similarly mbmon fails: > [chinatsu]:/root# mbmon -V > No VIA686 HWM available!! > InitMBInfo: No error: 0 > Exit 1 > [chinatsu]:/root# mbmon -S > No SMBus HWM available!! > InitMBInfo: No error: 0 > Exit 1 > [chinatsu]:/root# mbmon -I > No ISA-IO HWM available!! > InitMBInfo: No error: 0 > Exit 1 > [chinatsu]:/root# mbmon -A > InitMBInfo: No error: 0 > This program needs "setuid root"!! > Exit 1 > > Here's output of pciconf:These tools from ports are very outdated and thus do not support new hardware.> [chinatsu]:/root# pciconf -lv > hostb0 at pci0:0:0:0: class=0x060000 card=0x50001458 chip=0x01508086 rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Ivy Bridge DRAM Controller' > class = bridge > subclass = HOST-PCI > vgapci0 at pci0:0:2:0: class=0x030000 card=0xd0001458 chip=0x01528086 rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Ivy Bridge Graphics Controller' > class = display > subclass = VGA > xhci0 at pci0:0:20:0: class=0x0c0330 card=0x50071458 chip=0x1e318086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point USB xHCI Host Controller' > class = serial bus > subclass = USB > none0 at pci0:0:22:0: class=0x078000 card=0x1c3a1458 chip=0x1e3a8086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point MEI Controller' > class = simple comms > ehci0 at pci0:0:26:0: class=0x0c0320 card=0x50061458 chip=0x1e2d8086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point USB Enhanced Host Controller' > class = serial bus > subclass = USB > pcib1 at pci0:0:28:0: class=0x060400 card=0x50011458 chip=0x1e108086 rev=0xc4 hdr=0x01 > vendor = 'Intel Corporation' > device = 'Panther Point PCI Express Root Port 1' > class = bridge > subclass = PCI-PCI > pcib2 at pci0:0:28:2: class=0x060400 card=0x50011458 chip=0x1e148086 rev=0xc4 hdr=0x01 > vendor = 'Intel Corporation' > device = 'Panther Point PCI Express Root Port 3' > class = bridge > subclass = PCI-PCI > pcib3 at pci0:0:28:3: class=0x060401 card=0x50011458 chip=0x244e8086 rev=0xc4 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 PCI Bridge' > class = bridge > subclass = PCI-PCI > ehci1 at pci0:0:29:0: class=0x0c0320 card=0x50061458 chip=0x1e268086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point USB Enhanced Host Controller' > class = serial bus > subclass = USB > isab0 at pci0:0:31:0: class=0x060100 card=0x50011458 chip=0x1e4a8086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point LPC Controller' > class = bridge > subclass = PCI-ISA > ahci0 at pci0:0:31:2: class=0x010601 card=0xb0051458 chip=0x1e028086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point 6 port SATA AHCI Controller' > class = mass storage > subclass = SATA > ichsmb0 at pci0:0:31:3: class=0x0c0500 card=0x50011458 chip=0x1e228086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Panther Point SMBus Controller' > class = serial bus > subclass = SMBus > alc0 at pci0:2:0:0: class=0x020000 card=0xe0001458 chip=0x10831969 rev=0xc0 hdr=0x00 > vendor = 'Atheros Communications' > device = 'AR8151 v2.0 Gigabit Ethernet' > class = network > subclass = ethernet > pcib4 at pci0:3:0:0: class=0x060401 card=0x88921458 chip=0x244e8086 rev=0x41 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801 PCI Bridge' > class = bridge > subclass = PCI-PCI > em0 at pci0:4:1:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = '82541PI Gigabit Ethernet Controller' > class = network > subclass = ethernet > >-- Andriy Gapon
On Sat, Oct 20, 2012 at 3:09 PM, Andriy Gapon <avg at freebsd.org> wrote:> on 20/10/2012 22:42 Andriy Gapon said the following: >> on 20/10/2012 22:20 Derek Kulinski said the following: >>> I have three questions though: >>> 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, >>> and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. >>> Seems like: >>> fan0 -> CPU_FAN (did not try to disconnect it to check :) >>> fan1 -> SYS_FAN1 >>> fan2 -> SYS_FAN2 >>> There is no entry for SYS_FAN3. I disconnected it temporarily but >>> it did not seem to affect the output. Is it possible to get that >>> information from the motherboard? >> >> The driver would have to be updated for that. >> Unfortunately ITE does not provide public datasheets. >> We could pick up some new bits from the Linux driver though. >> http://lxr.linux.no/#linux+v3.6.2/drivers/hwmon/it87.c > > In fact, here is a completely untested patch: > http://people.freebsd.org/~avg/it-fans-0x80.diff >@@ -354,12 +372,15 @@ static void it_refresh_sensor_data(struct it_softc *sc) { /* Refresh our stored data for every sensor */ - it_generic_stemp(sc, &sc->sensors[12]); - it_generic_svolt(sc, &sc->sensors[3]); - if (sc->fan16bit) + if (sc->fan16bit) { it_16bit_fanrpm(sc, &sc->sensors[0]); - else + it_generic_svolt(sc, &sc->sensors[5]); + it_generic_svolt(sc, &sc->sensors[14]); <- Looks to be a copy/paste bug ;-) + } else { it_generic_fanrpm(sc, &sc->sensors[0]); + it_generic_svolt(sc, &sc->sensors[3]); + it_generic_stemp(sc, &sc->sensors[12]); + } }
on 21/10/2012 10:11 Scot Hetzel said the following:> On Sat, Oct 20, 2012 at 3:09 PM, Andriy Gapon <avg at freebsd.org> wrote: >> on 20/10/2012 22:42 Andriy Gapon said the following: >>> on 20/10/2012 22:20 Derek Kulinski said the following: >>>> I have three questions though: >>>> 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, >>>> and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. >>>> Seems like: >>>> fan0 -> CPU_FAN (did not try to disconnect it to check :) >>>> fan1 -> SYS_FAN1 >>>> fan2 -> SYS_FAN2 >>>> There is no entry for SYS_FAN3. I disconnected it temporarily but >>>> it did not seem to affect the output. Is it possible to get that >>>> information from the motherboard? >>> >>> The driver would have to be updated for that. >>> Unfortunately ITE does not provide public datasheets. >>> We could pick up some new bits from the Linux driver though. >>> http://lxr.linux.no/#linux+v3.6.2/drivers/hwmon/it87.c >> >> In fact, here is a completely untested patch: >> http://people.freebsd.org/~avg/it-fans-0x80.diff >> > > @@ -354,12 +372,15 @@ static void > it_refresh_sensor_data(struct it_softc *sc) > { > /* Refresh our stored data for every sensor */ > - it_generic_stemp(sc, &sc->sensors[12]); > - it_generic_svolt(sc, &sc->sensors[3]); > - if (sc->fan16bit) > + if (sc->fan16bit) { > it_16bit_fanrpm(sc, &sc->sensors[0]); > - else > + it_generic_svolt(sc, &sc->sensors[5]); > + it_generic_svolt(sc, &sc->sensors[14]); <- Looks to be a copy/paste bug ;-)Indeed. Should be "stemp" of course. Thank you!> + } else { > it_generic_fanrpm(sc, &sc->sensors[0]); > + it_generic_svolt(sc, &sc->sensors[3]); > + it_generic_stemp(sc, &sc->sensors[12]); > + } > } >-- Andriy Gapon
Hello Andriy, Sunday, October 21, 2012, 1:53:51 AM, you wrote:>> it_16bit_fanrpm(sc, &sc->sensors[0]); >> - else >> + it_generic_svolt(sc, &sc->sensors[5]); >> + it_generic_svolt(sc, &sc->sensors[14]); <- Looks to be a copy/paste bug ;-)> Indeed. Should be "stemp" of course. > Thank you!I just fixed the code and looks better now: hw.sensors.it0.fan0: 997 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1303 RPM hw.sensors.it0.fan3: 1149 RPM hw.sensors.it0.fan4: invalid hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) hw.sensors.it0.volt2: 2,70 VDC (+3.3V) hw.sensors.it0.volt3: 4,60 VDC (+5V) hw.sensors.it0.volt4: 0,06 VDC (+12V) hw.sensors.it0.volt5: -5,08 VDC (Unused) hw.sensors.it0.volt6: -6,53 VDC (-12V) hw.sensors.it0.volt7: 3,74 VDC (+5VSB) hw.sensors.it0.volt8: 2,14 VDC (VBAT) hw.sensors.it0.temp0: 30,00 degC hw.sensors.it0.temp1: 25,00 degC hw.sensors.it0.temp2: 25,00 degC -- Best regards, Derek mailto:takeda at takeda.tk -- DEFINITION: Computer - A device designed to speed and automate errors.
Hello Jeremy, Monday, October 22, 2012, 6:03:49 AM, you wrote:> I'm not subscribed to the FreeBSD lists any longer, but I did come > across this thread via the web:> http://lists.freebsd.org/pipermail/freebsd-stable/2012-October/070169.html> Either (or both) of you are free to bounce a copy of my Email here to > the list if you feel it'd benefit others.> I have a lot of familiarity with hardware monitoring chips and > interfacing with them (as the author of ports/sysutils/bsdhwmon).> The H/W monitoring chip on that Gigabyte motherboard is **not** the same > or has resistors/pullups that differ from what the OpenBSD sensors > framework code expects. That is quite evident from the below. There > are also very likely labels that are wrong. I'll get to explaining how > to fix that properly further down.> Let me explain in detail one section at a time:>> hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) >> hw.sensors.it0.volt1: 2,72 VDC (VCORE_B)> The term "Vcore" refers to the CPU core voltage. This is a > per-physical-CPU basis. This software is assuming there's 2 physical > CPUs (not cores, I'm talking about physical processors).> VCORE_A may be correct (meaning 1.42V), however it depends on the CPU > model. Derek did not disclose this so I cannot tell you if 1.42V is > considered "correct" or not. Some models run at 1.2V, others 1.5V, > others vary.It is i5-3470 3.2GHz quad core (The entire component list I used to build is here: http://pcpartpicker.com/p/koz3). The CPU is not overclocked, I set "auto" for all this kind of settings in the BIOS.> VCORE_B is probably not VCORE_B at all. However, worse: 2.72V does not > look to be a correct/valid voltage no matter what (even if for an MCH or > a southbridge). So probably a calculation error or its reading the > wrong bits from the chip.>> hw.sensors.it0.volt2: 2,70 VDC (+3.3V)> This is also wrong -- either the voltage or the label. There is no way > your system would be stable if a +3.3V line was at +2.7V. So another > calculation error or reading wrong bits from the chip.>> hw.sensors.it0.volt3: 4,60 VDC (+5V)> This is probably also wrong, but it's hard to say. +5V is relied on > heavily throughout the entire system, so a 0.4V drop is pretty damn > major. So probably another calculation error or reading wrong bits from > the chip.>> hw.sensors.it0.volt4: 0,06 VDC (+12V)> This is flat out completely wrong on numerous levels.>> hw.sensors.it0.volt5: -5,08 VDC (Unused)> No idea. This could be -5V monitoring, but it depends. Only Gigabyte > would know.>> hw.sensors.it0.volt6: -6,53 VDC (-12V)> Also totally wrong (voltage and label). So another calculation error or > reading wrong bits from the chip.>> hw.sensors.it0.volt7: 3,74 VDC (+5VSB)> Also totally wrong (voltage and/or label). "+5Vsb" stands for "+5V > standby"; it's the +5V line that comes off the PSU and is *always on*, > even when the motherboard is off. It's what allows systems to power > back up from sleep state. So another calculation error or reading wrong > bits from the chip.>> hw.sensors.it0.volt8: 2,14 VDC (VBAT)> Also totally wrong (voltage and/or label). "VBAT" refers to the voltage > of the CMOS battery, which should be +3.3V. So another calculation > error or reading wrong bits from the chip.> Here is what proper labels and a proper system should show, as an > example:> # bsdhwmon > CPU1 Temperature 31 C > System Temperature 35 C > FAN1 0 RPM > FAN2 0 RPM > FAN3 0 RPM > FAN4 2042 RPM > FAN5 0 RPM > FAN6 1875 RPM > VcoreA 1.106 V > MCH Core 1.522 V > -12V -12.288 V > V_DIMM 1.712 V > +3.3V 3.392 V > +12V 12.096 V > 5Vsb 5.070 V > 5VDD 5.118 V > P_VTT 1.142 V > Vbat 3.328 V> The bottom line here is this: the problem with the sensors framework is > that it has no concept of per-motherboard engineering (to my knowledge). > Again, that is why I designed bsdhwmon the way I did -- I key off of > SMBIOS string data because it's the only way to do things as reliable as > possible. Each motherboard model requires unique support. Without > that, voltage calculations are either wrong, or labels are completely > wrong, or both.> If I could get within the bowels of Gigabyte and actually talk to a > **real engineer** and not tech support, I could find out if their > GA-H77-DS3H motherboard has SMBus tie-ins for their H/W monitoring chip. > If it does, I **absolutely** could add PROPER support for it to > bsdhwmon.> However, regardless of that, it also requires the owner of the > motherboard to be able to run the monitoring software provided by the > vendor for the board (usually Windows software) as a "baseline" > comparison -- or -- take a screenshot of the hardware monitoring details > in the BIOS (or UEFI system) for comparison. Sometimes a VERY HIGH > RESOLUTION photo of the motherboard is helpful -- though sometimes this > isn't useful because motherboard vendors actually use "emulation modes" > of their Super I/O chips (e.g. Chip Z is installed on the board, but > it's configured to emulate Chip X which the Chip company made 2 years > ago). I've found this on many Supermicro boards actually -- what's > silkscreened on the chips says one thing but how the chip *behaves* is > another.Not exactly a screenshot but I wrote down values given by BIOS: CPU Vcore 1.044V DRAM Voltage 1.524V +3.3V 3.363V +12V 12.168V CPU Temp 33C System Temp 30C Please let me know if this is enough. As for the picture of the motherboard, this one (http://www.nix.ru/autocatalog/motherboards_gigabyte/135869_2245_draft.jpg) looks way better than any of my picture. It is revision 1.0. Gigabyte seems to have also rev 1.1, but 1.0 is the one I use.> But sometimes even WITH proper documentation from the vendor there are > unexplained issues. Two examples taken from bsdhwmon's doc/BUGS:> Winbond W83792D: +5V Vcc is incorrect > ======================================> Currently, boards which use the Winbond W83792D H/W monitoring IC will > have their +5V voltage shown incorrectly.> I've mailed Supermicro to try and find out why the calculation formula > is wrong (since what I'm following comes from Winbond), but as of this > writing have received no response.> I have also looked at the Linux lm-sensors project, but the code is > quite "spaghetti" -- it's hard to discern what the calculation values > are, and if they're the same for all W83792D systems.> Winbond W83792D: FAN3 RPMs may be inaccurate/high > ==================================================> I've received a single (isolated) report involving a Supermicro P8SCi > board reporting absurdly high values for FAN3. Example:> FAN1 0 RPM > FAN2 2909 RPM > FAN3 84375 RPM > FAN4 0 RPM > FAN5 0 RPM> Further executions of bsdhwmon did not exhibit this problem. However, > I take the report seriously, as it could indicate a strange bug in > bsdhwmon, or possibly a bug in the Winbond W83792D chipset. At this > time I have not been able to determine the root cause, however the > user had his fan RPM configuration in the system BIOS set to > "3-pin Server" rather than "Disabled" (which runs the fans at full > speed). This could be a bug in the Winbond chipset, but I simply > don't know. > ------------> I refuse to interface with Super I/O or H/W monitoring chips that use > the classic ISA interface (/dev/io) because it's an extremely risky > interface. You can crash and lock up a system very very easily with > this model. The wrong I/O port or wrong bit set in the wrong sub-reg > and pow, the system is in a weird state. It's a lot more difficult with > SMBus given the unique assignment of a slave device address per-device.> Don't get me started on what Linux lm-sensors looks like either. Good > god what a mess. Does it work? Yeah, it works. But it's just such a > garbled mess of code and "configs" and some abstract strangeness. It > really doesn't read well, and is not commented good to boot.> I wish I could help solve this in some way for you guys (without using > sensors). I've spent way too many years doing H/W monitoring "stuff", > and concluded long ago that on FreeBSD H/W monitoring is absolutely > doable but we need support from vendors on a per-motherboard basis. > Supermicro happens to be one of the few vendors who is quite good about > this, barring the Winbond W83792D +5V Vcc problem.> The biggest problem: this kind of support/effort is quite literally a > full-time job. Finding/getting in contact with engineers deep within > the bowels of companies is the hardest part.> P.S. -- Question for Andriy: I thought it was established long ago that > none of this monitoring should be done in the kernel? Were you around > when someone took the time to port the OpenBSD sensors framework to > FreeBSD, and it resulted in a *massive* discussion and backlash from > FreeBSD kernel committers stating "this should not go in the kernel?" > Now I see this, and mention of an it(4) driver...? What exactly is > going on? To put it in California-style: "dude. This REALLY pisses me > off. WTF is going on over there?"-- Best regards, Derek mailto:takeda at takeda.tk Always remember you're unique, just like everyone else.