Date: Mon, 22 Oct 2012 09:15:29 -0700 From: Jeremy Chadwick <jdc@koitsu.org> To: Derek Kulinski <takeda@takeda.tk> Cc: freebsd-stable@FreeBSD.org, avg@FreeBSD.org Subject: Re: Problem reading vitals from Gigabyte H77-DH3H Message-ID: <20121022161529.GA31919@icarus.home.lan> In-Reply-To: <35578786.20121022083811@takeda.tk> References: <20121022130348.GA28302@icarus.home.lan> <35578786.20121022083811@takeda.tk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 22, 2012 at 08:38:11AM -0700, Derek Kulinski wrote:
> Hello Jeremy,
>
> Monday, October 22, 2012, 6:03:49 AM, you wrote:
>
{snipping}
> > 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.
Then it's simple: the voltage shown is wrong. The Core i5-3470 runs at
a stock Vcore of 1.1V, and with some CPU features will downthrottle to
around 1.0V. Thus, 1.42V is too high (thus wrong), and is just further
indication that the calculation is wrong or the data being obtained is
wrong. If your CPU was really running at 1.42V, it'd have crashed by
the time you got into the BIOS. (The highest I've seen people overclock
Vcore on this chip is 1.25V, so 1.42V is obviously a calculation error)
{snipping}
> > 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
And here we have proof that the sensor data you're seeing in FreeBSD is
wrong, so I rest my case.
> Please let me know if this is enough.
I'll repeat what I wrote:
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.
> 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.
The H/W monitoring and Super I/O chip on this board is from iTE, but I
cannot read the silkscreening. The chip model matters.
But furthermore, as I said above, the silkscreening is not always an
indicator of how the chip operates.
The official site only says "iTE I/O Controller", which is also too
vague.
This is why getting full documentation from the board vendor is needed.
Getting this is like pulling teeth. Given that Gigabyte is a
workstation and consumer-focused company (not server-focused), the
likelihood of them understanding this question is very low:
"Hello. I am a developer of H/W monitoring software for FreeBSD, and
I'm looking to get technical documentation about the H/W monitoring and
Super I/O chip used on the Gigabyte GA-H77-DS3H (revision 1.0)
motherboard. I need to know what chip is used that provides voltages,
fan RPMs, and temperatures, and I need to know if that chip has SMBus
tie-ins. If it does, I need to know what the SMBus slave address is,
and what the register offsets are + full descriptions of the registers.
If you have calculation formulas (for in-line resistor offsets and so
on) that would be quite helpful. Thank you."
Supermicro Technical Support, comparatively, understands the above
question and will give full documentation for each board you ask for.
I've asked them for 10-12 boards "in bulk" once, and they provided all
the documentation for every board. It takes them about 2 weeks to get
it to you -- because they have to get it from an actual engineer. But
getting this from consumer-focused manufacturers (ex. Asus, Gigabyte,
MSI, and even Intel) is difficult. Don't ask me why.
bsdhwmon has no support for iTE chips at this time. It only works with
Supermicro motherboards which (so far) have been (mostly) Winbond chips
(now known as Nuvoton). Some Supermicro boards are also very unique
and strange, such as some of their higher-end blade-based boards, where
things are done very uniquely (in some cases, *2* H/W monitoring chips
are used on the same board, with multiple SMBus slave addresses).
Anyway, more abstract: this is why you will find software such as the
free "Motherboard Monitor" application for Windows reporting wrong
voltages, temperatures, and fan RPMs -- because the software simply
probes busses looking for chips, and if it finds one, ***assumes***
they're all the same. That assumption is what causes these types of
problems, and is why official documentation and support **per board** is
needed. That is why I designed bsdhwmon the way I did -- I test each
and every board *individually*. It's the only way, sadly.
> It is revision 1.0. Gigabyte seems to have also rev 1.1, but 1.0 is
> the one I use.
Gigabyte board revisions are interesting -- some change very little
(optimising some circuitry, changing location of some components), while
others change dramatically (changing NIC/PHY vendors, changing USB 3.0
chip vendors, changing Firewire or Super I/O chip vendors). It varies
greatly.
I use Gigabyte boards for my workstations, but do not use them for
FreeBSD-related things. I use Supermicro for that.
--
| Jeremy Chadwick jdc@koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121022161529.GA31919>