Re: [lm-sensors] Identifying i2c devices on Asus P8P67 sandybridge

Re: [lm-sensors] Identifying i2c devices on Asus P8P67 sandybridge

[Phillip Susi]

( moved from linux-i2c to lm-sensors )

> No, the device isn't even listed on lm-sensors.org's wiki, I am not
> aware of anyone working on it.
>
> The datasheet isn't available for download from Nuvoton, but can
> probably be requested from them.

I signed up for an account and downloaded the datasheet today.  I'll 
take a look at some of the other drivers that are probably quite similar 
and see if I can modify one to work on this chip.

>> Then again, I wonder if it might be better to come up with an SSDT I can
>> dynamically load to define the ACPI FAN and TZ objects and let the
>> regular acpi driver manage it.
>
> What an horrid idea. The ACPI FAN and TZ interfaces are very limited.
> If the ACPI BIOS doesn't block access to the NCT6776F's I/O ports,
> you'll be much better with a native driver.

Why is this a horrid idea?  It seems like the idea is that ACPI systems 
are supposed to provide the TZ and FAN interfaces so that the OS can 
monitor the temperature and fan speed and get automatic fan speed 
control, or choose to override it, all without the bother of hardware 
specific drivers.  That seems good to me.

Also here is the DIMM SPD dump that decode-dimms does not like:

      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 93 10 0b 02 02 11 00 09 03 52 01 08 0f 00 1e 00    ??????.??R???.?.
10: 69 78 69 3c 69 10 f0 8c 70 03 3c 3c 00 f0 03 04    ixi<i???p?<<.???
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01    ..............??
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
70: 00 00 00 00 00 84 b0 02 00 00 00 00 00 00 3f 58    .....???......?X
80: 4f 43 5a 33 50 31 36 30 30 43 36 4c 56 32 47 20    OCZ3P1600C6LV2G
90: 20 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ..............
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Identifying i2c devices on Asus P8P67 sandybridge

[Jean Delvare]

Hi Philip,

On Wed, 26 Jan 2011 22:16:46 -0500, Phillip Susi wrote:
> ( moved from linux-i2c to lm-sensors )
> 
> > No, the device isn't even listed on lm-sensors.org's wiki, I am not
> > aware of anyone working on it.
> >
> > The datasheet isn't available for download from Nuvoton, but can
> > probably be requested from them.
> 
> I signed up for an account and downloaded the datasheet today.  I'll 

Signed up for an account where? The only way I know to get Nuvoton
datasheets is asking for them by e-mail. Did you find another way?

> take a look at some of the other drivers that are probably quite similar 
> and see if I can modify one to work on this chip.

If any of our drivers is suitable for addition of NCT6776F support,
this would most likely be w83627ehf. But only a close look at the
datasheet will tell if this is possible and a desirable.

> >> Then again, I wonder if it might be better to come up with an SSDT I can
> >> dynamically load to define the ACPI FAN and TZ objects and let the
> >> regular acpi driver manage it.
> >
> > What an horrid idea. The ACPI FAN and TZ interfaces are very limited.
> > If the ACPI BIOS doesn't block access to the NCT6776F's I/O ports,
> > you'll be much better with a native driver.
> 
> Why is this a horrid idea?  It seems like the idea is that ACPI systems 
> are supposed to provide the TZ and FAN interfaces so that the OS can 
> monitor the temperature and fan speed and get automatic fan speed 
> control, or choose to override it, all without the bother of hardware 
> specific drivers.  That seems good to me.

First of all, I am not aware of any ACPI interface for automatic fan
speed control, not even for fan speed reporting. All I've ever seen
from standard ACPI interfaces are: temperature values with a 1°C
resolution, and fan on/off switching. As I said, this is very limited.
Mind you, there is a reason why Asus came up with their own "standard"
(ATK0110).

Secondly, if you are going to write the code, writing it in the SSDT
won't save you any effort compared to writing native code (except that
I find ASL syntax horrible compared to C). The only interest of ACPI
implementations is that the OS needs no specific code to handle them,
but you still have hardware-specific driving code in the end. Simply,
it's in the BIOS, provided by the vendor, instead of being in the OS.

> Also here is the DIMM SPD dump that decode-dimms does not like:
> 
>       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
> 00: 93 10 0b 02 02 11 00 09 03 52 01 08 0f 00 1e 00    ??????.??R???.?.
> 10: 69 78 69 3c 69 10 f0 8c 70 03 3c 3c 00 f0 03 04    ixi<i???p?<<.???
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01    ..............??
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 70: 00 00 00 00 00 84 b0 02 00 00 00 00 00 00 3f 58    .....???......?X
> 80: 4f 43 5a 33 50 31 36 30 30 43 36 4c 56 32 47 20    OCZ3P1600C6LV2G
> 90: 20 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00      ..............
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

Decoded correctly by decode-dimms version 5733. I guess you were using
an old version of the script which didn't know about DDR3.

I am surprised by the tRAS though, it seems way too high, there may be a
bug in the script.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Identifying i2c devices on Asus P8P67 sandybridge

[Phillip Susi]

On 1/27/2011 3:15 AM, Jean Delvare wrote:
> Signed up for an account where? The only way I know to get Nuvoton
> datasheets is asking for them by e-mail. Did you find another way?

I just googled the part number and their web site came right up with a
link to download the data sheet ( login required ).  I signed up for a
login, confirmed via email, and downloaded it.

http://www.sequoia.co.uk/components/product.php?d=1&cy&f(6&p\x1425&fmt=grid

> If any of our drivers is suitable for addition of NCT6776F support,
> this would most likely be w83627ehf. But only a close look at the
> datasheet will tell if this is possible and a desirable.

Yep, this looks pretty similar so far.

> First of all, I am not aware of any ACPI interface for automatic fan
> speed control, not even for fan speed reporting. All I've ever seen
> from standard ACPI interfaces are: temperature values with a 1°C
> resolution, and fan on/off switching. As I said, this is very limited.
> Mind you, there is a reason why Asus came up with their own "standard"
> (ATK0110).

It looks like the ACPI spec allows fans to define up to 10 levels of
operation.  While that is a bit more coarse than the full 255 pwm
levels, it should be enough.

> Secondly, if you are going to write the code, writing it in the SSDT
> won't save you any effort compared to writing native code (except that
> I find ASL syntax horrible compared to C). The only interest of ACPI
> implementations is that the OS needs no specific code to handle them,
> but you still have hardware-specific driving code in the end. Simply,
> it's in the BIOS, provided by the vendor, instead of being in the OS.

The reason I was considering it was so I could send it to Asus and ask
them to include it in future bios revs so that it just works right out
of the box in the future.  Having to figure out what hwmon driver to
load, tell the kernel to let it even though the resources are claimed by
acpi, then configure sensors and the fancontrol script is a pain.  The
ACPI temperature just works without any configuration.

I also find the fancontrol script to be somewhat poor at controlling the
fans and this really is a function that should be in the kernel and is
defined by ACPI.

> Decoded correctly by decode-dimms version 5733. I guess you were using
> an old version of the script which didn't know about DDR3.

They changed the format for DDR3?  Odd.

> I am surprised by the tRAS though, it seems way too high, there may be a
> bug in the script.

It should be 6-8-6-24.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Identifying i2c devices on Asus P8P67 sandybridge

[Jean Delvare]

Hi Phillip,

On Thu, 27 Jan 2011 11:07:41 -0500, Phillip Susi wrote:
> On 1/27/2011 3:15 AM, Jean Delvare wrote:
> > Signed up for an account where? The only way I know to get Nuvoton
> > datasheets is asking for them by e-mail. Did you find another way?
> 
> I just googled the part number and their web site came right up with a
> link to download the data sheet ( login required ).  I signed up for a
> login, confirmed via email, and downloaded it.
> 
> http://www.sequoia.co.uk/components/product.php?d=1&cy&f(6&p\x1425&fmt=grid

Oh, that's not "their website". This is a reseller's website. It's
pretty surprising that they allow visitors to download datasheets when
these aren't available from Nuvoton's website.

> > If any of our drivers is suitable for addition of NCT6776F support,
> > this would most likely be w83627ehf. But only a close look at the
> > datasheet will tell if this is possible and a desirable.
> 
> Yep, this looks pretty similar so far.
> 
> > First of all, I am not aware of any ACPI interface for automatic fan
> > speed control, not even for fan speed reporting. All I've ever seen
> > from standard ACPI interfaces are: temperature values with a 1°C
> > resolution, and fan on/off switching. As I said, this is very limited.
> > Mind you, there is a reason why Asus came up with their own "standard"
> > (ATK0110).
> 
> It looks like the ACPI spec allows fans to define up to 10 levels of
> operation.  While that is a bit more coarse than the full 255 pwm
> levels, it should be enough.

Does ACPI allow reporting an unlimited number of voltage values? Does
ACPI allow reporting an unlimited number of fan speeds? Reporting of
temperature values with a resolution better than 1°C? Setting low and
high limits for each of these items?

Honestly, I don't know what ACPI allows. What I know is that I've never
seen any implementation going anywhere even remotely near to what a
native hwmon driver can offer.

> > Secondly, if you are going to write the code, writing it in the SSDT
> > won't save you any effort compared to writing native code (except that
> > I find ASL syntax horrible compared to C). The only interest of ACPI
> > implementations is that the OS needs no specific code to handle them,
> > but you still have hardware-specific driving code in the end. Simply,
> > it's in the BIOS, provided by the vendor, instead of being in the OS.
> 
> The reason I was considering it was so I could send it to Asus and ask
> them to include it in future bios revs so that it just works right out
> of the box in the future.

Wow, you are pretty optimistic. A board vendor accepting code from
external contributors? I bet I will be dead before this happens.

> Having to figure out what hwmon driver to
> load, tell the kernel to let it even though the resources are claimed by
> acpi, then configure sensors and the fancontrol script is a pain.  The
> ACPI temperature just works without any configuration.

Or fails without any configuration, as happened to me on some boards.

> I also find the fancontrol script to be somewhat poor at controlling the
> fans and this really is a function that should be in the kernel and is
> defined by ACPI.

I wholeheartedly agree that pwmconfig and fancontrol suck. They are
afternoon hacks that have grown too old, and I wouldn't recommend
anyone to use them. I wish someone interested would write a proper tool
(i.e. not written in bash to start with) to deal with manual fan speed
control. And automatic fan speed control, too.

I also agree that the ACPI resource conflicts we're seeing on many
boards these days is a pain. But in many cases, the right fix would be
for board vendors to stop claiming resources they don't use.

And even with the two statements above, I still claim that native
hwmon drivers are doing a much better job than any ACPI implementation
I've seen. And don't believe it makes me happy: I would love all
systems to have hardware monitoring support working out of the box
thanks to a brilliant ACPI specification and no-less brilliant
implementations. But I don't expect this to happen any time soon :(

> > Decoded correctly by decode-dimms version 5733. I guess you were using
> > an old version of the script which didn't know about DDR3.
> 
> They changed the format for DDR3?  Odd.

There is a common part mostly common to all SDRAM formats, and the rest
is type-specific. But the key problem is probably that the script can't
decode a type it doesn't know about. You can look at the source code
(or the JEDEC specs) if you are interested in the details.

> > I am surprised by the tRAS though, it seems way too high, there may be a
> > bug in the script.
> 
> It should be 6-8-6-24.

Really? Is this what memtest86 is report? It's a long time since I last
saw a memory module with the 3 first digits not being the same.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Identifying i2c devices on Asus P8P67 sandybridge

[Phillip Susi]

On 1/27/2011 12:14 PM, Jean Delvare wrote:
> Does ACPI allow reporting an unlimited number of voltage values? Does
> ACPI allow reporting an unlimited number of fan speeds? Reporting of
> temperature values with a resolution better than 1°C? Setting low and
> high limits for each of these items?

From what I have read so far, the TZ sets temperature thresholds at
which the various fan settings should kick in.  The resolution may have
only been in whole degrees, but that doesn't seem to be a problem to me.

> Wow, you are pretty optimistic. A board vendor accepting code from
> external contributors? I bet I will be dead before this happens.

Admittedly it's a long shot.  I also figured it would be a good learning
experience ;)

> I wholeheartedly agree that pwmconfig and fancontrol suck. They are
> afternoon hacks that have grown too old, and I wouldn't recommend
> anyone to use them. I wish someone interested would write a proper tool
> (i.e. not written in bash to start with) to deal with manual fan speed
> control. And automatic fan speed control, too.

Frequency control started off in user space too, then moved to the
kernel.  Maybe it is time for the same to be done with fan speed.  A
generic fan control driver could be written to interface with the hwmon
devices.

The problem is that it still would require manual configuration of which
temperature sensors should govern which fan pwm controls, since the
platform does not provide that information.

> And even with the two statements above, I still claim that native
> hwmon drivers are doing a much better job than any ACPI implementation
> I've seen. And don't believe it makes me happy: I would love all
> systems to have hardware monitoring support working out of the box
> thanks to a brilliant ACPI specification and no-less brilliant
> implementations. But I don't expect this to happen any time soon :(

Indeed.  It seems to me that vendors just don't care to do it right in
the standard way since they can just ship a windows driver that will
make 99% of their customers happy.  That is another reason I was
wondering about doing it with an SSDT.  If I could, it would show
clearly that it CAN be done, and pressure could be put on vendors to
start doing it the right way.

>> It should be 6-8-6-24.
> 
> Really? Is this what memtest86 is report? It's a long time since I last
> saw a memory module with the 3 first digits not being the same.

It is what the MFR specs say.  I haven't run a memtest86 on it, but I
think the bios detected and used those values.  I'll double check it
tonight and maybe run a memtest.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Identifying i2c devices on Asus P8P67 sandybridge

[Phillip Susi]

On 01/27/2011 12:14 PM, Jean Delvare wrote:
>>> I am surprised by the tRAS though, it seems way too high, there may be a
>>> bug in the script.
>>
>> It should be 6-8-6-24.
>
> Really? Is this what memtest86 is report? It's a long time since I last
> saw a memory module with the 3 first digits not being the same.

memtest86 seems to hang or reboot.  I am now quite confused because the 
part number that I ordered was OCZ3P11600C6LV4GK and was listed on 
newegg as having 6-8-6-24 timings.  That is the part number listed on 
the retail packaging, but the SPD decodes with decode-dimms ( release 
3.0.3 ) as having part number OCZ3P1600C6LV2G with 7-7-7-33 timing.  The 
Asus bios has an SPD decode utility that agrees with the part number, 
but shows 7-7-7 for cas, trcp, trp, but 16 for tras, not 33.  Despite 
showing tRas as 16 in the SPD, it defaults to driving it at 18.  It also 
lists a bunch of additional timings, none of which are 33.  I can find 
neither part number on OCZ's web site.


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Identifying i2c devices on Asus P8P67 sandybridge

[Jean Delvare]

On Thu, 27 Jan 2011 23:51:00 -0500, Phillip Susi wrote:
> On 01/27/2011 12:14 PM, Jean Delvare wrote:
> >>> I am surprised by the tRAS though, it seems way too high, there may be a
> >>> bug in the script.
> >>
> >> It should be 6-8-6-24.
> >
> > Really? Is this what memtest86 is report? It's a long time since I last
> > saw a memory module with the 3 first digits not being the same.
> 
> memtest86 seems to hang or reboot.

FWIW, last time I experienced this, it was caused by a mouse connected
to the serial port of the machine. Disconnecting the mouse fixed it.

Also, there are various versions of memtest86 and memtest86+ around,
trying a different version might work around the bug. OTOH, old
versions probably won't know how to deal with DDR3.

> I am now quite confused because the 
> part number that I ordered was OCZ3P11600C6LV4GK and was listed on 
> newegg as having 6-8-6-24 timings.  That is the part number listed on 
> the retail packaging, but the SPD decodes with decode-dimms ( release 
> 3.0.3 ) as having part number OCZ3P1600C6LV2G with 7-7-7-33 timing.  The 
> Asus bios has an SPD decode utility that agrees with the part number, 
> but shows 7-7-7 for cas, trcp, trp, but 16 for tras, not 33.  Despite 
> showing tRas as 16 in the SPD, it defaults to driving it at 18.  It also 
> lists a bunch of additional timings, none of which are 33.  I can find 
> neither part number on OCZ's web site.

Oh well. The market of memory modules has gone crazy. And the number of
timing values has literally exploded since DDR2. My BIOS offers to let
me tweak each setting manually and I got totally frightened by the
length of the list (of course I set it all back to auto and ran away.)

Anyway, I don't think this will be a big issue in practice. All I
really meant was: take the output of decode-dimms with a grain of salt,
while it should be OK on SDRAM and DDR, DDR2 and DDR3 support isn't too
well tested and the reported values may be incorrect.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Identifying i2c devices on Asus P8P67 sandybridge

[Jean Delvare]

Hi Phillip,

On Thu, 27 Jan 2011 13:47:39 -0500, Phillip Susi wrote:
> On 1/27/2011 12:14 PM, Jean Delvare wrote:
> > I wholeheartedly agree that pwmconfig and fancontrol suck. They are
> > afternoon hacks that have grown too old, and I wouldn't recommend
> > anyone to use them. I wish someone interested would write a proper tool
> > (i.e. not written in bash to start with) to deal with manual fan speed
> > control. And automatic fan speed control, too.
> 
> Frequency control started off in user space too, then moved to the
> kernel.  Maybe it is time for the same to be done with fan speed.  A
> generic fan control driver could be written to interface with the hwmon
> devices.

Well, if you thought that the CPU frequency scaling case was difficult
and that explained why it took so long to get right, please realize
that thermal regulation is one order of magnitude more complex.

> The problem is that it still would require manual configuration of which
> temperature sensors should govern which fan pwm controls, since the
> platform does not provide that information.

Yes, this is the problem exactly. Except for embedded design and vendor
machines (e.g. Apple), the kernel has no clue how fan inputs, fan
outputs and temperature inputs relate to each other. Nor does it have a
clue on what each temperature sensor is measuring, or which part of the
machine each fan is cooling.

This is the reason why configuration is difficult, and why it has to
happen in user-space. The only way this could be addressed in the PC
world is if ACPI (or any similarly broadly adopted specification) was
to give vendors a way to describe all these relations in a simple and
unambiguous way. But then again I don't expect it to happen anytime
soon, as PC board manufacturers use their proprietary tuning software
as differentiators on the market.

OTOH, I strongly believe that thermal management should NOT be
OS-dependent in the first place. We have chips which can do automatic
fan speed control, it's up to the BIOS to program them at start-up to
avoid any overheating of the system. Letting the user select a profile
(as Asus is doing) is nice, and as long as the BIOS does its job
properly and gives enough flexibility, it should be enough in practice
for 95% of the users. Fine-tuning at run-time would be nice to have,
but I don't expect my parents to use it. Maybe not even me.

> > And even with the two statements above, I still claim that native
> > hwmon drivers are doing a much better job than any ACPI implementation
> > I've seen. And don't believe it makes me happy: I would love all
> > systems to have hardware monitoring support working out of the box
> > thanks to a brilliant ACPI specification and no-less brilliant
> > implementations. But I don't expect this to happen any time soon :(
> 
> Indeed.  It seems to me that vendors just don't care to do it right in
> the standard way since they can just ship a windows driver that will
> make 99% of their customers happy.

Sad but true :(

> That is another reason I was
> wondering about doing it with an SSDT.  If I could, it would show
> clearly that it CAN be done, and pressure could be put on vendors to
> start doing it the right way.

Sure, but I'm not holding my breath. Once I reported to a board vendor
(Jetway) that their TZ code was reading the temperature from the wrong
register, returning a constant 9°C instead of the actual temperature
value. It would have been fixed with changing one constant in the DSDT.
I never got any reply, and they never fixed it.

But well, one can certainly hope that some vendors are better than
others, and dream that the trend is for them to get more open to their
customers.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Identifying i2c devices on Asus P8P67 sandybridge

[Phillip Susi]

On 1/28/2011 4:25 AM, Jean Delvare wrote:
> FWIW, last time I experienced this, it was caused by a mouse connected
> to the serial port of the machine. Disconnecting the mouse fixed it.

All USB here.  I wonder if the SMM keyboard and mouse emulation could be
the problem?

> Also, there are various versions of memtest86 and memtest86+ around,
> trying a different version might work around the bug. OTOH, old
> versions probably won't know how to deal with DDR3.

I'll have to try the latest one tonight and see.  The one on my Ubuntu
Maverick install just instantly reboots.  The one on my Natty test flash
stick hangs after drawing the initial screen and a few lines of output.

> Oh well. The market of memory modules has gone crazy. And the number of
> timing values has literally exploded since DDR2. My BIOS offers to let
> me tweak each setting manually and I got totally frightened by the
> length of the list (of course I set it all back to auto and ran away.)

That's exactly how I felt.

> Anyway, I don't think this will be a big issue in practice. All I
> really meant was: take the output of decode-dimms with a grain of salt,
> while it should be OK on SDRAM and DDR, DDR2 and DDR3 support isn't too
> well tested and the reported values may be incorrect.

That's why I'm reporting it; so the bugs can be fixed ;)

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors