[lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Ian Dobson]

Hello All,

Firstly I'd like to thank Guenter for all his work adding support for the 
nct6776f superIO chip.

During my testing of the driver on a Asus p8p67 pro motherboard and a Arctic 
cooling fan I've come across a small problem that the RPM reading is 
sometimes incorrect, usually the incorrect reading is almost double the 
expected value and is only incorrect for 2 seconds (Next actual read from 
the chip). Looking at the tacho signal from the fan with an oscilloscope  I 
can see short pulses/dropouts which cause the incorrect reading. Looking 
through the data sheet I see that the nct6776f and nct6775f both support 
de-bouncing the fan rpm signal (logical device b address 0xf0 bit 1-5 for 
nct6776f or 1-4 for nct6775f). After enabling the rpm de-bounce for the CPU 
fan I've not seen any more miss readings. I tested for 24hours and usually I 
see a incorrect reading within 10-30 minutes.

The first question is, should we offer the possibility to enable rpm 
de-bounce for chips that support it? If yes then what interface should we 
use? I can see 3 possibilities:-
1) Through sysfs fanX_debounce (0/1). I already have a patch for this and 
the diff is about 60 lines of code
2) Through a module parameter (fan_debounce=X) where X could be 0/1 for 
disable/enable for all fans or a decimal value which is the bit pattern for 
the de-bounce to enable.
3) Always enable the fan de-bounce if the chip supports it.

Note enabling de-bounce does not appear to have any negative effects.

Regards
Ian Dobson

 


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Guenter Roeck]

Hi Ian,

On Sun, Mar 06, 2011 at 07:38:24AM -0500, Ian Dobson wrote:
> Hello All,
> 
> Firstly I'd like to thank Guenter for all his work adding support for the 
> nct6776f superIO chip.
> 
> During my testing of the driver on a Asus p8p67 pro motherboard and a Arctic 
> cooling fan I've come across a small problem that the RPM reading is 
> sometimes incorrect, usually the incorrect reading is almost double the 
> expected value and is only incorrect for 2 seconds (Next actual read from 
> the chip). Looking at the tacho signal from the fan with an oscilloscope  I 
> can see short pulses/dropouts which cause the incorrect reading. Looking 
> through the data sheet I see that the nct6776f and nct6775f both support 
> de-bouncing the fan rpm signal (logical device b address 0xf0 bit 1-5 for 
> nct6776f or 1-4 for nct6775f). After enabling the rpm de-bounce for the CPU 
> fan I've not seen any more miss readings. I tested for 24hours and usually I 
> see a incorrect reading within 10-30 minutes.
> 
> The first question is, should we offer the possibility to enable rpm 
> de-bounce for chips that support it? If yes then what interface should we 
> use? I can see 3 possibilities:-
> 1) Through sysfs fanX_debounce (0/1). I already have a patch for this and 
> the diff is about 60 lines of code
> 2) Through a module parameter (fan_debounce=X) where X could be 0/1 for 
> disable/enable for all fans or a decimal value which is the bit pattern for 
> the de-bounce to enable.
> 3) Always enable the fan de-bounce if the chip supports it.
> 
> Note enabling de-bounce does not appear to have any negative effects.
> 
Thanks a lot for the feedback and testing.

Since there will always be just one of those devices in a system, option 2) or 3)
seem to be better choices; I like to avoid adding new attributes if there is another
option and if the attribute would only be used by a single driver.

We could implement 3) for simplicity, but question is if this might have any
undesired side effects on other boards. So 2) might be the safer approach.

Thoughts, anyone ?

Thanks,
Guenter

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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Ian Dobson]

Hi Guenter,
--------------------------------------------------
From: "Guenter Roeck" <guenter.roeck@ericsson.com>
Sent: Sunday, March 06, 2011 6:07 PM
To: "Ian Dobson" <i.dobson@planet-ian.com>
Cc: <lm-sensors@lm-sensors.org>
Subject: Re: RFC: nct6776f support in the w83627ehf and fan RPM signal 
de-bounce

> Hi Ian,
>
> On Sun, Mar 06, 2011 at 07:38:24AM -0500, Ian Dobson wrote:
>> Hello All,
>>
>> Firstly I'd like to thank Guenter for all his work adding support for the
>> nct6776f superIO chip.
>>
>> During my testing of the driver on a Asus p8p67 pro motherboard and a 
>> Arctic
>> cooling fan I've come across a small problem that the RPM reading is
>> sometimes incorrect, usually the incorrect reading is almost double the
>> expected value and is only incorrect for 2 seconds (Next actual read from
>> the chip). Looking at the tacho signal from the fan with an oscilloscope 
>> I
>> can see short pulses/dropouts which cause the incorrect reading. Looking
>> through the data sheet I see that the nct6776f and nct6775f both support
>> de-bouncing the fan rpm signal (logical device b address 0xf0 bit 1-5 for
>> nct6776f or 1-4 for nct6775f). After enabling the rpm de-bounce for the 
>> CPU
>> fan I've not seen any more miss readings. I tested for 24hours and 
>> usually I
>> see a incorrect reading within 10-30 minutes.
>>
>> The first question is, should we offer the possibility to enable rpm
>> de-bounce for chips that support it? If yes then what interface should we
>> use? I can see 3 possibilities:-
>> 1) Through sysfs fanX_debounce (0/1). I already have a patch for this and
>> the diff is about 60 lines of code
>> 2) Through a module parameter (fan_debounce=X) where X could be 0/1 for
>> disable/enable for all fans or a decimal value which is the bit pattern 
>> for
>> the de-bounce to enable.
>> 3) Always enable the fan de-bounce if the chip supports it.
>>
>> Note enabling de-bounce does not appear to have any negative effects.
>>
> Thanks a lot for the feedback and testing.
>
> Since there will always be just one of those devices in a system, option 
> 2) or 3)
> seem to be better choices; I like to avoid adding new attributes if there 
> is another
> option and if the attribute would only be used by a single driver.
>
> We could implement 3) for simplicity, but question is if this might have 
> any
> undesired side effects on other boards. So 2) might be the safer approach.
>
> Thoughts, anyone ?
>
> Thanks,
> Guenter

I already have a patch for 1 or 2, just let me know what you want.

I can't imagine that enabling de-bounce should have any undesired side 
effects on other boards. I have afew contacts that have various Asus socket 
1155 boards with nct6776f chips, so maybe I can get them to test my 
de-bounce patch to see if there are any side effects.

Regards
Ian Dobson
 


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Guenter Roeck]

Hi Ian,

On Sun, Mar 06, 2011 at 12:21:48PM -0500, Ian Dobson wrote:
> 
> Hi Guenter,
> --------------------------------------------------
> From: "Guenter Roeck" <guenter.roeck@ericsson.com>
> Sent: Sunday, March 06, 2011 6:07 PM
> To: "Ian Dobson" <i.dobson@planet-ian.com>
> Cc: <lm-sensors@lm-sensors.org>
> Subject: Re: RFC: nct6776f support in the w83627ehf and fan RPM signal 
> de-bounce
> 
> > Hi Ian,
> >
> > On Sun, Mar 06, 2011 at 07:38:24AM -0500, Ian Dobson wrote:
> >> Hello All,
> >>
> >> Firstly I'd like to thank Guenter for all his work adding support for the
> >> nct6776f superIO chip.
> >>
> >> During my testing of the driver on a Asus p8p67 pro motherboard and a 
> >> Arctic
> >> cooling fan I've come across a small problem that the RPM reading is
> >> sometimes incorrect, usually the incorrect reading is almost double the
> >> expected value and is only incorrect for 2 seconds (Next actual read from
> >> the chip). Looking at the tacho signal from the fan with an oscilloscope 
> >> I
> >> can see short pulses/dropouts which cause the incorrect reading. Looking
> >> through the data sheet I see that the nct6776f and nct6775f both support
> >> de-bouncing the fan rpm signal (logical device b address 0xf0 bit 1-5 for
> >> nct6776f or 1-4 for nct6775f). After enabling the rpm de-bounce for the 
> >> CPU
> >> fan I've not seen any more miss readings. I tested for 24hours and 
> >> usually I
> >> see a incorrect reading within 10-30 minutes.
> >>
> >> The first question is, should we offer the possibility to enable rpm
> >> de-bounce for chips that support it? If yes then what interface should we
> >> use? I can see 3 possibilities:-
> >> 1) Through sysfs fanX_debounce (0/1). I already have a patch for this and
> >> the diff is about 60 lines of code
> >> 2) Through a module parameter (fan_debounce=X) where X could be 0/1 for
> >> disable/enable for all fans or a decimal value which is the bit pattern 
> >> for
> >> the de-bounce to enable.
> >> 3) Always enable the fan de-bounce if the chip supports it.
> >>
> >> Note enabling de-bounce does not appear to have any negative effects.
> >>
> > Thanks a lot for the feedback and testing.
> >
> > Since there will always be just one of those devices in a system, option 
> > 2) or 3)
> > seem to be better choices; I like to avoid adding new attributes if there 
> > is another
> > option and if the attribute would only be used by a single driver.
> >
> > We could implement 3) for simplicity, but question is if this might have 
> > any
> > undesired side effects on other boards. So 2) might be the safer approach.
> >
> > Thoughts, anyone ?
> >
> > Thanks,
> > Guenter
> 
> I already have a patch for 1 or 2, just let me know what you want.
> 
Why don't you send the patch for 2) to the list ? If it is ok, I'll
add it to the series.

> I can't imagine that enabling de-bounce should have any undesired side 
> effects on other boards. I have afew contacts that have various Asus socket 
> 1155 boards with nct6776f chips, so maybe I can get them to test my 
> de-bounce patch to see if there are any side effects.
> 
Me not either. Just playing safe.

As it is, I am really much more concerned that I am unable to get an
Acked-by: for the patch series, much less a Reviewed-by:, nor a Tested-by:
from anyone but you. That might result in the series not making it into 2.6.39,
which I think would be unfortunate.

Here are the requirements for Acked-by:

"If a person was not directly involved in the preparation or handling of a
 patch but wishes to signify and record their approval of it then they can
 arrange to have an Acked-by: line added to the patch's changelog.
 ...
 Acked-by: is not as formal as Signed-off-by:.  It is a record that the acker
 has at least reviewed the patch and has indicated acceptance.  Hence patch
 mergers will sometimes manually convert an acker's "yep, looks good to me"
 into an Acked-by:."

So, for anyone interested in seeing support for NCT6775F and NCT6776F in 2.6.39, 
consider the above. If you think the patch series and your review of it meets
above criteria, please consider sending me an Acked-by: for the series, or,
if you only reviewed individual patches, for the patches you reviewed.

Thanks,
Guenter

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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Ian Dobson]

Hi Guenter,

--------------------------------------------------
From: "Guenter Roeck" <guenter.roeck@ericsson.com>
Sent: Sunday, March 06, 2011 7:47 PM
To: "Ian Dobson" <i.dobson@planet-ian.com>
Cc: <lm-sensors@lm-sensors.org>
Subject: Re: RFC: nct6776f support in the w83627ehf and fan RPM signal 
de-bounce

> Hi Ian,
>
> On Sun, Mar 06, 2011 at 12:21:48PM -0500, Ian Dobson wrote:
>>
>> Hi Guenter,
>> --------------------------------------------------
>> From: "Guenter Roeck" <guenter.roeck@ericsson.com>
>> Sent: Sunday, March 06, 2011 6:07 PM
>> To: "Ian Dobson" <i.dobson@planet-ian.com>
>> Cc: <lm-sensors@lm-sensors.org>
>> Subject: Re: RFC: nct6776f support in the w83627ehf and fan RPM signal
>> de-bounce
>>
>> > Hi Ian,
>> >
>> > On Sun, Mar 06, 2011 at 07:38:24AM -0500, Ian Dobson wrote:
>> >> Hello All,
>> >>
>> >> Firstly I'd like to thank Guenter for all his work adding support for 
>> >> the
>> >> nct6776f superIO chip.
>> >>
>> >> During my testing of the driver on a Asus p8p67 pro motherboard and a
>> >> Arctic
>> >> cooling fan I've come across a small problem that the RPM reading is
>> >> sometimes incorrect, usually the incorrect reading is almost double 
>> >> the
>> >> expected value and is only incorrect for 2 seconds (Next actual read 
>> >> from
>> >> the chip). Looking at the tacho signal from the fan with an 
>> >> oscilloscope
>> >> I
>> >> can see short pulses/dropouts which cause the incorrect reading. 
>> >> Looking
>> >> through the data sheet I see that the nct6776f and nct6775f both 
>> >> support
>> >> de-bouncing the fan rpm signal (logical device b address 0xf0 bit 1-5 
>> >> for
>> >> nct6776f or 1-4 for nct6775f). After enabling the rpm de-bounce for 
>> >> the
>> >> CPU
>> >> fan I've not seen any more miss readings. I tested for 24hours and
>> >> usually I
>> >> see a incorrect reading within 10-30 minutes.
>> >>
>> >> The first question is, should we offer the possibility to enable rpm
>> >> de-bounce for chips that support it? If yes then what interface should 
>> >> we
>> >> use? I can see 3 possibilities:-
>> >> 1) Through sysfs fanX_debounce (0/1). I already have a patch for this 
>> >> and
>> >> the diff is about 60 lines of code
>> >> 2) Through a module parameter (fan_debounce=X) where X could be 0/1 
>> >> for
>> >> disable/enable for all fans or a decimal value which is the bit 
>> >> pattern
>> >> for
>> >> the de-bounce to enable.
>> >> 3) Always enable the fan de-bounce if the chip supports it.
>> >>
>> >> Note enabling de-bounce does not appear to have any negative effects.
>> >>
>> > Thanks a lot for the feedback and testing.
>> >
>> > Since there will always be just one of those devices in a system, 
>> > option
>> > 2) or 3)
>> > seem to be better choices; I like to avoid adding new attributes if 
>> > there
>> > is another
>> > option and if the attribute would only be used by a single driver.
>> >
>> > We could implement 3) for simplicity, but question is if this might 
>> > have
>> > any
>> > undesired side effects on other boards. So 2) might be the safer 
>> > approach.
>> >
>> > Thoughts, anyone ?
>> >
>> > Thanks,
>> > Guenter
>>
>> I already have a patch for 1 or 2, just let me know what you want.
>>
> Why don't you send the patch for 2) to the list ? If it is ok, I'll
> add it to the series.
>
>> I can't imagine that enabling de-bounce should have any undesired side
>> effects on other boards. I have afew contacts that have various Asus 
>> socket
>> 1155 boards with nct6776f chips, so maybe I can get them to test my
>> de-bounce patch to see if there are any side effects.
>>
> Me not either. Just playing safe.
>
> As it is, I am really much more concerned that I am unable to get an
> Acked-by: for the patch series, much less a Reviewed-by:, nor a Tested-by:
> from anyone but you. That might result in the series not making it into 
> 2.6.39,
> which I think would be unfortunate.
>
> Here are the requirements for Acked-by:
>
> "If a person was not directly involved in the preparation or handling of a
> patch but wishes to signify and record their approval of it then they can
> arrange to have an Acked-by: line added to the patch's changelog.
> ...
> Acked-by: is not as formal as Signed-off-by:.  It is a record that the 
> acker
> has at least reviewed the patch and has indicated acceptance.  Hence patch
> mergers will sometimes manually convert an acker's "yep, looks good to me"
> into an Acked-by:."
>
> So, for anyone interested in seeing support for NCT6775F and NCT6776F in 
> 2.6.39,
> consider the above. If you think the patch series and your review of it 
> meets
> above criteria, please consider sending me an Acked-by: for the series, 
> or,
> if you only reviewed individual patches, for the patches you reviewed.
>
> Thanks,
> Guenter

I've put out a request to the other people I know of who are using your 
standalone driver (with my de-bounce patch) to test it and let me know how 
they get along.

I'd rather wait abit with my de-bounce patch, I'd rather get the driver into 
.39 and then look at adding changes. You've done alot of work on this driver 
and it would be a shame if it doesn't make it into the next merge window.

I'll do a full code review tomorrow but as you've already covered the 
comments I've had I don't think I'll find anything new, you already have my 
tested-by:

Regards and Thanks
Ian Dobson
 


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Guenter Roeck]

Hi Ian,

On Sun, Mar 06, 2011 at 02:40:30PM -0500, Ian Dobson wrote:
[ ... ]
> 
> I've put out a request to the other people I know of who are using your 
> standalone driver (with my de-bounce patch) to test it and let me know how 
> they get along.
> 
Great!

> I'd rather wait abit with my de-bounce patch, I'd rather get the driver into 
> .39 and then look at adding changes. You've done alot of work on this driver 
> and it would be a shame if it doesn't make it into the next merge window.
> 
That is not really a problem. If you submit it, I'll be happy to review it and
sign it off. I could theoretically just push the rest of the patches as well,
but I don't like to do that without someone else at having a look.
Not that I don't trust my code, but I know that I am not perfect, and something
might have slipped by. Better safe than sorry.

> I'll do a full code review tomorrow but as you've already covered the 
> comments I've had I don't think I'll find anything new, you already have my 
> tested-by:
> 
Sounds good.

Thanks,
Guenter

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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Robert Kaiser]

Guenter Roeck schrieb:
> As it is, I am really much more concerned that I am unable to get an
> Acked-by: for the patch series, much less a Reviewed-by:, nor a Tested-by:
> from anyone but you. That might result in the series not making it into 2.6.39,
> which I think would be unfortunate.

If I had time, any knowledge of kernel code or even C, and it was easy 
to test this (without compiling a kernel myself, and with some nice doc 
telling all steps I need), then I'd look into helping there.
But then, right now, all of those factors are lacking, unfortunately - 
and my new Intel DH67CL board with something that is probably once of 
those chips creates other problems as well (thinking no display is 
connected), so sensors are not the most important factor, just a nice 
tool to play with... ;-)

Robert Kaiser


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Guenter Roeck]

On Sun, Mar 06, 2011 at 09:50:28PM -0500, Robert Kaiser wrote:
> Guenter Roeck schrieb:
> > As it is, I am really much more concerned that I am unable to get an
> > Acked-by: for the patch series, much less a Reviewed-by:, nor a Tested-by:
> > from anyone but you. That might result in the series not making it into 2.6.39,
> > which I think would be unfortunate.
> 
> If I had time, any knowledge of kernel code or even C, and it was easy 
> to test this (without compiling a kernel myself, and with some nice doc 
> telling all steps I need), then I'd look into helping there.
> But then, right now, all of those factors are lacking, unfortunately - 
> and my new Intel DH67CL board with something that is probably once of 
> those chips creates other problems as well (thinking no display is 
> connected), so sensors are not the most important factor, just a nice 
> tool to play with... ;-)
> 
This is a Sandy Bridge board, isn't it ? 

Maybe you can try a kernel from the -next tree; that might solve your problem.
That means you would have to download, compile and install the kernel, though.

To test a standalone driver, all you have to do is to download it, then run "make" 
followed by "sudo make install". You don't have to build the entire kernel.

Thanks,
Guenter

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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Robert Kaiser]

Guenter Roeck schrieb:
> This is a Sandy Bridge board, isn't it ?

Yes, it is.

> Maybe you can try a kernel from the -next tree; that might solve your problem.
> That means you would have to download, compile and install the kernel, though.

Hrm, exactly what I want to avoid, updating openSUSE Factory quite often 
already is experimental enough for me on a production machine, but I'm 
using Kernel:HEAD there, which is currently some recent 2.6.38-rc and I 
should be 2.6.39-rc once the merge window has closed.

Still, do you know something I don't on my error that you suggest that? 
Chris Wilson on intel-gfx was somewhat clueless as to why this happens...

> To test a standalone driver, all you have to do is to download it, then run "make"
> followed by "sudo make install". You don't have to build the entire kernel.

That sounds good.
Can I download your standalone driver in a git clone or similar way? 
Pulling the files one by one over http doesn't sound ideal to me. :)

Robert Kaiser


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Guenter Roeck]

On Mon, Mar 07, 2011 at 09:59:21AM -0500, Robert Kaiser wrote:
> Guenter Roeck schrieb:
> > This is a Sandy Bridge board, isn't it ?
> 
> Yes, it is.
> 
> > Maybe you can try a kernel from the -next tree; that might solve your problem.
> > That means you would have to download, compile and install the kernel, though.
> 
> Hrm, exactly what I want to avoid, updating openSUSE Factory quite often 
> already is experimental enough for me on a production machine, but I'm 
> using Kernel:HEAD there, which is currently some recent 2.6.38-rc and I 
> should be 2.6.39-rc once the merge window has closed.
> 
> Still, do you know something I don't on my error that you suggest that? 
> Chris Wilson on intel-gfx was somewhat clueless as to why this happens...
> 
All I know is that there is a sequence of patches in linux-next adding several
PCI IDs plus related code to the kernel which seem to be related to Sandy Bridge.
Look for PCI IDs with "DH89XXCC". I am kind of vague here; I was told that the added
PCI IDs match those of Sandy Bridge, but I have not seen the specification myself
so I don't really know for sure.

Do those changes address your problem ? No idea, but it might be worth a try.

> > To test a standalone driver, all you have to do is to download it, then run "make"
> > followed by "sudo make install". You don't have to build the entire kernel.
> 
> That sounds good.
> Can I download your standalone driver in a git clone or similar way? 
> Pulling the files one by one over http doesn't sound ideal to me. :)
> 
The driver is in the hwmon-staging branch of
	http://git.kernel.org/?p=linux/kernel/git/groeck/staging.git

But you'll still need the Makefile from the standalone driver.
	http://www.roeck-us.net/linux/drivers/w83627ehf/Makefile

The only other files you would need are
	http://www.roeck-us.net/linux/drivers/w83627ehf/lm75.h
	http://www.roeck-us.net/linux/drivers/w83627ehf/w83627ehf.c

Just downloading those with wget seems to be more straightforward than creating a git clone.

Thanks,
Guenter


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Robert Kaiser]

Guenter Roeck schrieb:
> All I know is that there is a sequence of patches in linux-next adding several
> PCI IDs plus related code to the kernel which seem to be related to Sandy Bridge.
> Look for PCI IDs with "DH89XXCC". I am kind of vague here; I was told that the added
> PCI IDs match those of Sandy Bridge, but I have not seen the specification myself
> so I don't really know for sure.
>
> Do those changes address your problem ? No idea, but it might be worth a try.

I'm looking forward to seeing if 2.6.39-rc does better, then, once the 
merge window has closed and openSUSE's Kernel:HEAD has it.

> Just downloading those with wget seems to be more straightforward than creating a git clone.

OK, did that (needed to switch to the other KERNEL_BUILD line in the 
Makefile, but fortunately I'm familiar enough with those Makefiles from 
Mozilla work).
FYI, here's the sensors output and used kernel version on my Intel 
DH67CL board:

# sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:      +52.0°C  (high = +80.0°C, crit = +98.0°C)

coretemp-isa-0001
Adapter: ISA adapter
Core 1:      +49.0°C  (high = +80.0°C, crit = +98.0°C)

coretemp-isa-0002
Adapter: ISA adapter
Core 2:      +54.0°C  (high = +80.0°C, crit = +98.0°C)

coretemp-isa-0003
Adapter: ISA adapter
Core 3:      +48.0°C  (high = +80.0°C, crit = +98.0°C)

nct6775-isa-0290
Adapter: ISA adapter
Vcore:                 +1.15 V  (min =  +0.00 V, max =  +1.74 V)
in1:                   +1.11 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
AVCC:                  +3.31 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
+3.3V:                 +3.31 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
in4:                   +1.02 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
in5:                   +1.05 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
in6:                   +1.08 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
3VSB:                  +3.41 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
Vbat:                  +3.38 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
fan1:                    0 RPM  (min =    0 RPM, div = 64)
fan2:                 1110 RPM  (min =    0 RPM, div = 32)  ALARM
fan3:                    0 RPM  (min =    0 RPM, div = 64)
fan4:                    0 RPM  (div = 64)
SYSTIN:                +39.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM 
  sensor = diode
CPUTIN:                +38.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor 
= diode
SMBUSMASTER 1:         +54.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor 
= diode
PCH_CHIP_CPU_MAX_TEMP: +65.0°C
SMBUSMASTER 2:          +0.0°C  (high = +80.0°C, hyst = +75.0°C)
cpu0_vid:             +2.050 V

# uname -a
Linux robert.box.kairo.at 2.6.38-rc7-18-desktop #1 SMP PREEMPT 
2011-03-08 01:01:25 +0100 x86_64 x86_64 x86_64 GNU/Linux


I hope those values are somewhat reasonable for what you'd expect. 
Thanks for your work on this!


Robert Kaiser



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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Guenter Roeck]

Hi Robert,

On Wed, Mar 09, 2011 at 07:25:43PM -0500, Robert Kaiser wrote:
> Guenter Roeck schrieb:
> > All I know is that there is a sequence of patches in linux-next adding several
> > PCI IDs plus related code to the kernel which seem to be related to Sandy Bridge.
> > Look for PCI IDs with "DH89XXCC". I am kind of vague here; I was told that the added
> > PCI IDs match those of Sandy Bridge, but I have not seen the specification myself
> > so I don't really know for sure.
> >
> > Do those changes address your problem ? No idea, but it might be worth a try.
> 
> I'm looking forward to seeing if 2.6.39-rc does better, then, once the 
> merge window has closed and openSUSE's Kernel:HEAD has it.
> 
> > Just downloading those with wget seems to be more straightforward than creating a git clone.
> 
> OK, did that (needed to switch to the other KERNEL_BUILD line in the 
> Makefile, but fortunately I'm familiar enough with those Makefiles from 
> Mozilla work).
> FYI, here's the sensors output and used kernel version on my Intel 
> DH67CL board:
> 
> # sensors
> coretemp-isa-0000
> Adapter: ISA adapter
> Core 0:      +52.0°C  (high = +80.0°C, crit = +98.0°C)
> 
> coretemp-isa-0001
> Adapter: ISA adapter
> Core 1:      +49.0°C  (high = +80.0°C, crit = +98.0°C)
> 
> coretemp-isa-0002
> Adapter: ISA adapter
> Core 2:      +54.0°C  (high = +80.0°C, crit = +98.0°C)
> 
> coretemp-isa-0003
> Adapter: ISA adapter
> Core 3:      +48.0°C  (high = +80.0°C, crit = +98.0°C)
> 
> nct6775-isa-0290
> Adapter: ISA adapter
> Vcore:                 +1.15 V  (min =  +0.00 V, max =  +1.74 V)
> in1:                   +1.11 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> AVCC:                  +3.31 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> +3.3V:                 +3.31 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> in4:                   +1.02 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> in5:                   +1.05 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> in6:                   +1.08 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> 3VSB:                  +3.41 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> Vbat:                  +3.38 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
> fan1:                    0 RPM  (min =    0 RPM, div = 64)
> fan2:                 1110 RPM  (min =    0 RPM, div = 32)  ALARM
> fan3:                    0 RPM  (min =    0 RPM, div = 64)
> fan4:                    0 RPM  (div = 64)
> SYSTIN:                +39.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM 
>   sensor = diode
> CPUTIN:                +38.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor 
> = diode
> SMBUSMASTER 1:         +54.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor 
> = diode
> PCH_CHIP_CPU_MAX_TEMP: +65.0°C
> SMBUSMASTER 2:          +0.0°C  (high = +80.0°C, hyst = +75.0°C)
> cpu0_vid:             +2.050 V
> 
> # uname -a
> Linux robert.box.kairo.at 2.6.38-rc7-18-desktop #1 SMP PREEMPT 
> 2011-03-08 01:01:25 +0100 x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> I hope those values are somewhat reasonable for what you'd expect. 
> Thanks for your work on this!
> 
Looks reasonable. There is one problem which I had wondered about - the ALARM 
which tends to show up for running fans.

I finally tracked that down. Turns out the chip has a "maximum RPM" register.
Apparently that register is not set, which causes the alarm.

There is a sysfs attribute for maximum RPM - fanX_max. The w83627ehf driver does not
support / use this attribute. Guess I'll have to add it .... that will have to be
a separate patch.

Thanks,
Guenter

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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Guenter Roeck]

Hi again,

On Wed, Mar 09, 2011 at 10:45:30PM -0500, Guenter Roeck wrote:
[ ... ] 
> > fan1:                    0 RPM  (min =    0 RPM, div = 64)
> > fan2:                 1110 RPM  (min =    0 RPM, div = 32)  ALARM
> > fan3:                    0 RPM  (min =    0 RPM, div = 64)
> > fan4:                    0 RPM  (div = 64)
> > 
[ ... ]
> Looks reasonable. There is one problem which I had wondered about - the ALARM 
> which tends to show up for running fans.
> 
> I finally tracked that down. Turns out the chip has a "maximum RPM" register.
> Apparently that register is not set, which causes the alarm.
> 
Actually, I am not sure if I got that right. Can you set the minimum speed of fan2
to something larger than 1110 rpm and check if that causes ALARM to go off ?

I suspect I might have misinterpreted the meaning of "Fan Count Limit". I thought
it is the low limit, but it might well be the high limit.

Thanks,
Guenter


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Ian Dobson]

Hi Guenter,

--------------------------------------------------
From: "Guenter Roeck" <guenter.roeck@ericsson.com>
Sent: Thursday, March 10, 2011 6:06 AM
To: "Robert Kaiser" <kairo@kairo.at>
Cc: <lm-sensors@lm-sensors.org>
Subject: Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan 
RPMsignal de-bounce

> Hi again,
>
> On Wed, Mar 09, 2011 at 10:45:30PM -0500, Guenter Roeck wrote:
> [ ... ]
>> > fan1:                    0 RPM  (min =    0 RPM, div = 64)
>> > fan2:                 1110 RPM  (min =    0 RPM, div = 32)  ALARM
>> > fan3:                    0 RPM  (min =    0 RPM, div = 64)
>> > fan4:                    0 RPM  (div = 64)
>> >
> [ ... ]
>> Looks reasonable. There is one problem which I had wondered about - the 
>> ALARM
>> which tends to show up for running fans.
>>
>> I finally tracked that down. Turns out the chip has a "maximum RPM" 
>> register.
>> Apparently that register is not set, which causes the alarm.
>>
> Actually, I am not sure if I got that right. Can you set the minimum speed 
> of fan2
> to something larger than 1110 rpm and check if that causes ALARM to go off 
> ?
>
> I suspect I might have misinterpreted the meaning of "Fan Count Limit". I 
> thought
> it is the low limit, but it might well be the high limit.
>
> Thanks,
> Guenter
>
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Are you sure, on my nct6776f the fan alarming appears to work correctly:-
HD:           532 RPM  (min =  200 RPM)
CPU:         1043 RPM  (min =  500 RPM)
Case Back:    990 RPM  (min =  500 RPM)
Case Front:   765 RPM  (min =  500 RPM)
fan5:           0 RPM  (min =    0 RPM)  ALARM

note those are exactly the minimum values I've entered into sensors3.conf 
and when the fan speed drops below these values I see an alarm.

Regards
Ian Dobson


 


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Guenter Roeck]

Hi Ian,

On Thu, Mar 10, 2011 at 12:20:23AM -0500, Ian Dobson wrote:
> Hi Guenter,
> 
> --------------------------------------------------
> From: "Guenter Roeck" <guenter.roeck@ericsson.com>
> Sent: Thursday, March 10, 2011 6:06 AM
> To: "Robert Kaiser" <kairo@kairo.at>
> Cc: <lm-sensors@lm-sensors.org>
> Subject: Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan 
> RPMsignal de-bounce
> 
> > Hi again,
> >
> > On Wed, Mar 09, 2011 at 10:45:30PM -0500, Guenter Roeck wrote:
> > [ ... ]
> >> > fan1:                    0 RPM  (min =    0 RPM, div = 64)
> >> > fan2:                 1110 RPM  (min =    0 RPM, div = 32)  ALARM
> >> > fan3:                    0 RPM  (min =    0 RPM, div = 64)
> >> > fan4:                    0 RPM  (div = 64)
> >> >
> > [ ... ]
> >> Looks reasonable. There is one problem which I had wondered about - the 
> >> ALARM
> >> which tends to show up for running fans.
> >>
> >> I finally tracked that down. Turns out the chip has a "maximum RPM" 
> >> register.
> >> Apparently that register is not set, which causes the alarm.
> >>
> > Actually, I am not sure if I got that right. Can you set the minimum speed 
> > of fan2
> > to something larger than 1110 rpm and check if that causes ALARM to go off 
> > ?
> >
> > I suspect I might have misinterpreted the meaning of "Fan Count Limit". I 
> > thought
> > it is the low limit, but it might well be the high limit.
> >
> > Thanks,
> > Guenter
> >
> >
> > _______________________________________________
> > lm-sensors mailing list
> > lm-sensors@lm-sensors.org
> > http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> 
> Are you sure, on my nct6776f the fan alarming appears to work correctly:-
> HD:           532 RPM  (min =  200 RPM)
> CPU:         1043 RPM  (min =  500 RPM)
> Case Back:    990 RPM  (min =  500 RPM)
> Case Front:   765 RPM  (min =  500 RPM)
> fan5:           0 RPM  (min =    0 RPM)  ALARM
> 
> note those are exactly the minimum values I've entered into sensors3.conf 
> and when the fan speed drops below these values I see an alarm.
> 
Obviously not ;). But there must be a reason for those ALARM responses.
You point me into the direction, though: Robert's output includes div,
meaning it looks like he does not have an nct6776f after all.

So first question is what chip he has.

Thanks,
Guenter

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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Guenter Roeck]

On Thu, Mar 10, 2011 at 06:35:53AM -0500, Guenter Roeck wrote:
> Hi Ian,
> 
> On Thu, Mar 10, 2011 at 12:20:23AM -0500, Ian Dobson wrote:
> > Hi Guenter,
> > 
> > --------------------------------------------------
> > From: "Guenter Roeck" <guenter.roeck@ericsson.com>
> > Sent: Thursday, March 10, 2011 6:06 AM
> > To: "Robert Kaiser" <kairo@kairo.at>
> > Cc: <lm-sensors@lm-sensors.org>
> > Subject: Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan 
> > RPMsignal de-bounce
> > 
> > > Hi again,
> > >
> > > On Wed, Mar 09, 2011 at 10:45:30PM -0500, Guenter Roeck wrote:
> > > [ ... ]
> > >> > fan1:                    0 RPM  (min =    0 RPM, div = 64)
> > >> > fan2:                 1110 RPM  (min =    0 RPM, div = 32)  ALARM
> > >> > fan3:                    0 RPM  (min =    0 RPM, div = 64)
> > >> > fan4:                    0 RPM  (div = 64)
> > >> >
> > > [ ... ]
> > >> Looks reasonable. There is one problem which I had wondered about - the 
> > >> ALARM
> > >> which tends to show up for running fans.
> > >>
> > >> I finally tracked that down. Turns out the chip has a "maximum RPM" 
> > >> register.
> > >> Apparently that register is not set, which causes the alarm.
> > >>
> > > Actually, I am not sure if I got that right. Can you set the minimum speed 
> > > of fan2
> > > to something larger than 1110 rpm and check if that causes ALARM to go off 
> > > ?
> > >
> > > I suspect I might have misinterpreted the meaning of "Fan Count Limit". I 
> > > thought
> > > it is the low limit, but it might well be the high limit.
> > >
> > > Thanks,
> > > Guenter
> > >
> > >
> > > _______________________________________________
> > > lm-sensors mailing list
> > > lm-sensors@lm-sensors.org
> > > http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> > 
> > Are you sure, on my nct6776f the fan alarming appears to work correctly:-
> > HD:           532 RPM  (min =  200 RPM)
> > CPU:         1043 RPM  (min =  500 RPM)
> > Case Back:    990 RPM  (min =  500 RPM)
> > Case Front:   765 RPM  (min =  500 RPM)
> > fan5:           0 RPM  (min =    0 RPM)  ALARM
> > 
> > note those are exactly the minimum values I've entered into sensors3.conf 
> > and when the fan speed drops below these values I see an alarm.
> > 
> Obviously not ;). But there must be a reason for those ALARM responses.
> You point me into the direction, though: Robert's output includes div,
> meaning it looks like he does not have an nct6776f after all.
> 
> So first question is what chip he has.
> 
... answer is NCT6775F, from Robert's log. It uses the "old" registers for the min
speed settings, so presumably that should be correct. Yet, there must be a reason
for the alarm. Maybe it is the "maximum RPM" register after all - the NCT6775F
has that set of registers as well.

Robert, can you play with the min speed setting a bit and see if you can get the alarm 
to disappear ?

Thanks,
Guenter


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[I.dobson]

Hi Guenter,

--------- Original Message --------
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: Ian Dobson <i.dobson@planet-ian.com>
Cc: lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan
RPMsignal de-bounce
Date: 03/10/11 12:35

> 
> Hi Ian,
> 
> On Thu, Mar 10, 2011 at 12:20:23AM -0500, Ian Dobson wrote:
> &gt; Hi Guenter,
> &gt; 
> &gt; --------------------------------------------------
> &gt; From: &quot;Guenter Roeck&quot; &lt;guenter.roeck@ericsson.com&gt;
> &gt; Sent: Thursday, March 10, 2011 6:06 AM
> &gt; To: &quot;Robert Kaiser&quot; &lt;kairo@kairo.at&gt;
> &gt; Cc: &lt;lm-sensors@lm-sensors.org&gt;
> &gt; Subject: Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and
fan 
> &gt; RPMsignal de-bounce
> &gt; 
> &gt; &gt; Hi again,
> &gt; &gt;
> &gt; &gt; On Wed, Mar 09, 2011 at 10:45:30PM -0500, Guenter Roeck wrote:
> &gt; &gt; [ ... ]
> &gt; &gt;&gt; &gt; fan1:                    0 RPM  (min =    0 RPM, div 64)
> &gt; &gt;&gt; &gt; fan2:                 1110 RPM  (min =    0 RPM, div 32)  ALARM
> &gt; &gt;&gt; &gt; fan3:                    0 RPM  (min =    0 RPM, div 64)
> &gt; &gt;&gt; &gt; fan4:                    0 RPM  (div = 64)
> &gt; &gt;&gt; &gt;
> &gt; &gt; [ ... ]
> &gt; &gt;&gt; Looks reasonable. There is one problem which I had wondered
about - the 
> &gt; &gt;&gt; ALARM
> &gt; &gt;&gt; which tends to show up for running fans.
> &gt; &gt;&gt;
> &gt; &gt;&gt; I finally tracked that down. Turns out the chip has a
&quot;maximum RPM&quot; 
> &gt; &gt;&gt; register.
> &gt; &gt;&gt; Apparently that register is not set, which causes the alarm.
> &gt; &gt;&gt;
> &gt; &gt; Actually, I am not sure if I got that right. Can you set the
minimum speed 
> &gt; &gt; of fan2
> &gt; &gt; to something larger than 1110 rpm and check if that causes ALARM
to go off 
> &gt; &gt; ?
> &gt; &gt;
> &gt; &gt; I suspect I might have misinterpreted the meaning of &quot;Fan
Count Limit&quot;. I 
> &gt; &gt; thought
> &gt; &gt; it is the low limit, but it might well be the high limit.
> &gt; &gt;
> &gt; &gt; Thanks,
> &gt; &gt; Guenter
> &gt; &gt;
> &gt; &gt;
> &gt; &gt; _______________________________________________
> &gt; &gt; lm-sensors mailing list
> &gt; &gt; lm-sensors@lm-sensors.org
> &gt; &gt; http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> &gt; 
> &gt; Are you sure, on my nct6776f the fan alarming appears to work
correctly:-
> &gt; HD:           532 RPM  (min =  200 RPM)
> &gt; CPU:         1043 RPM  (min =  500 RPM)
> &gt; Case Back:    990 RPM  (min =  500 RPM)
> &gt; Case Front:   765 RPM  (min =  500 RPM)
> &gt; fan5:           0 RPM  (min =    0 RPM)  ALARM
> &gt; 
> &gt; note those are exactly the minimum values I've entered into
sensors3.conf 
> &gt; and when the fan speed drops below these values I see an alarm.
> &gt; 
> Obviously not ;). But there must be a reason for those ALARM responses.
> You point me into the direction, though: Robert's output includes div,
> meaning it looks like he does not have an nct6776f after all.
> 
> So first question is what chip he has.
> 
> Thanks,
> Guenter
> 
> 
> 

Looking at other emails from robert he seems to have a nct6775.

Regards
Ian Dobson


________________________________________________________________
Message sent using Telaen Webmail 1.2.1



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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[I.dobson]

Hi Guenter,

--------- Original Message --------
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: Ian Dobson <i.dobson@planet-ian.com>
Cc: lm-sensors@lm-sensors.org, Robert Kaiser <kairo@kairo.at>
Subject: Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan
RPMsignal de-bounce
Date: 03/10/11 12:53

> 
> On Thu, Mar 10, 2011 at 06:35:53AM -0500, Guenter Roeck wrote:
> &gt; Hi Ian,
> &gt; 
> &gt; On Thu, Mar 10, 2011 at 12:20:23AM -0500, Ian Dobson wrote:
> &gt; &gt; Hi Guenter,
> &gt; &gt; 
> &gt; &gt; --------------------------------------------------
> &gt; &gt; From: &quot;Guenter Roeck&quot;
&lt;guenter.roeck@ericsson.com&gt;
> &gt; &gt; Sent: Thursday, March 10, 2011 6:06 AM
> &gt; &gt; To: &quot;Robert Kaiser&quot; &lt;kairo@kairo.at&gt;
> &gt; &gt; Cc: &lt;lm-sensors@lm-sensors.org&gt;
> &gt; &gt; Subject: Re: [lm-sensors] RFC: nct6776f support in the w83627ehf
and fan 
> &gt; &gt; RPMsignal de-bounce
> &gt; &gt; 
> &gt; &gt; &gt; Hi again,
> &gt; &gt; &gt;
> &gt; &gt; &gt; On Wed, Mar 09, 2011 at 10:45:30PM -0500, Guenter Roeck
wrote:
> &gt; &gt; &gt; [ ... ]
> &gt; &gt; &gt;&gt; &gt; fan1:                    0 RPM  (min =    0 RPM,
div = 64)
> &gt; &gt; &gt;&gt; &gt; fan2:                 1110 RPM  (min =    0 RPM,
div = 32)  ALARM
> &gt; &gt; &gt;&gt; &gt; fan3:                    0 RPM  (min =    0 RPM,
div = 64)
> &gt; &gt; &gt;&gt; &gt; fan4:                    0 RPM  (div = 64)
> &gt; &gt; &gt;&gt; &gt;
> &gt; &gt; &gt; [ ... ]
> &gt; &gt; &gt;&gt; Looks reasonable. There is one problem which I had
wondered about - the 
> &gt; &gt; &gt;&gt; ALARM
> &gt; &gt; &gt;&gt; which tends to show up for running fans.
> &gt; &gt; &gt;&gt;
> &gt; &gt; &gt;&gt; I finally tracked that down. Turns out the chip has a
&quot;maximum RPM&quot; 
> &gt; &gt; &gt;&gt; register.
> &gt; &gt; &gt;&gt; Apparently that register is not set, which causes the
alarm.
> &gt; &gt; &gt;&gt;
> &gt; &gt; &gt; Actually, I am not sure if I got that right. Can you set
the minimum speed 
> &gt; &gt; &gt; of fan2
> &gt; &gt; &gt; to something larger than 1110 rpm and check if that causes
ALARM to go off 
> &gt; &gt; &gt; ?
> &gt; &gt; &gt;
> &gt; &gt; &gt; I suspect I might have misinterpreted the meaning of
&quot;Fan Count Limit&quot;. I 
> &gt; &gt; &gt; thought
> &gt; &gt; &gt; it is the low limit, but it might well be the high limit.
> &gt; &gt; &gt;
> &gt; &gt; &gt; Thanks,
> &gt; &gt; &gt; Guenter
> &gt; &gt; &gt;
> &gt; &gt; &gt;
> &gt; &gt; &gt; _______________________________________________
> &gt; &gt; &gt; lm-sensors mailing list
> &gt; &gt; &gt; lm-sensors@lm-sensors.org
> &gt; &gt; &gt; http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> &gt; &gt; 
> &gt; &gt; Are you sure, on my nct6776f the fan alarming appears to work
correctly:-
> &gt; &gt; HD:           532 RPM  (min =  200 RPM)
> &gt; &gt; CPU:         1043 RPM  (min =  500 RPM)
> &gt; &gt; Case Back:    990 RPM  (min =  500 RPM)
> &gt; &gt; Case Front:   765 RPM  (min =  500 RPM)
> &gt; &gt; fan5:           0 RPM  (min =    0 RPM)  ALARM
> &gt; &gt; 
> &gt; &gt; note those are exactly the minimum values I've entered into
sensors3.conf 
> &gt; &gt; and when the fan speed drops below these values I see an alarm.
> &gt; &gt; 
> &gt; Obviously not ;). But there must be a reason for those ALARM
responses.
> &gt; You point me into the direction, though: Robert's output includes
div,
> &gt; meaning it looks like he does not have an nct6776f after all.
> &gt; 
> &gt; So first question is what chip he has.
> &gt; 
> .... answer is NCT6775F, from Robert's log. It uses the &quot;old&quot;
registers for the min
> speed settings, so presumably that should be correct. Yet, there must be a
reason
> for the alarm. Maybe it is the &quot;maximum RPM&quot; register after all
- the NCT6775F
> has that set of registers as well.
> 
> Robert, can you play with the min speed setting a bit and see if you can
get the alarm 
> to disappear ?
> 
> Thanks,
> Guenter
> 
> 
> 
> 
Looking in the specification for the 6775 that I have I see:-
SYSFANIN. A one indicates the fan count limit of SYSFANIN has been exceeded.
and
SYSFANIN Fan Count Limit
Note: It is the number of counts of the internal clock for the Limit of the
fan
speed.

So that count is the number of timer ticks per pulse from the fan (slower
fan -> higher count)
and the alarm is generated when the count exceeds the limit defined, ie when
the fan is running too slowly. Therefore if I understood the text the way it
was meant to be understood, the alarm is a minimum RPM alarm.

Regards
Ian Dobson

________________________________________________________________
Message sent using Telaen Webmail 1.2.1



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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Guenter Roeck]

On Thu, Mar 10, 2011 at 06:53:28AM -0500, Guenter Roeck wrote:
[ ... ]
> > 
> > So first question is what chip he has.
> > 
> ... answer is NCT6775F, from Robert's log. It uses the "old" registers for the min
> speed settings, so presumably that should be correct. Yet, there must be a reason
> for the alarm. Maybe it is the "maximum RPM" register after all - the NCT6775F
> has that set of registers as well.
> 
Doesn't look like the "maximum RPM" register is the culprit. I have a system with NCT6775F 
(not using its fan controls, though). Looks like one can not write into that register, so it
must be a status register. Maybe it reports the maximum RPM the chip has seen.

Guenter

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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Robert Kaiser]

Guenter Roeck schrieb:
> On Thu, Mar 10, 2011 at 06:53:28AM -0500, Guenter Roeck wrote:
> [ ... ]
>>>
>>> So first question is what chip he has.
>>>
>> ... answer is NCT6775F, from Robert's log. It uses the "old" registers for the min
>> speed settings, so presumably that should be correct. Yet, there must be a reason
>> for the alarm. Maybe it is the "maximum RPM" register after all - the NCT6775F
>> has that set of registers as well.
>>
> Doesn't look like the "maximum RPM" register is the culprit. I have a system with NCT6775F
> (not using its fan controls, though). Looks like one can not write into that register, so it
> must be a status register. Maybe it reports the maximum RPM the chip has seen.

OK, so here's a bit of shortened output of my tests:


# echo 5000 > /sys/devices/platform/w83627ehf.656/fan2_min
# sensors
[...]
fan2:                    0 RPM  (min = 5037 RPM, div = 4)
[...]

# sensors
[...]
fan2:                 1102 RPM  (min = 5113 RPM, div = 8)  ALARM
[...]

# sensors
[...]
fan2:                 1095 RPM  (min = 5113 RPM, div = 8)  ALARM
[...]

# sensors
[...]
fan2:                 1061 RPM  (min = 5113 RPM, div = 8)  ALARM
[...]

# echo 0 > /sys/devices/platform/w83627ehf.656/fan2_min
# sensors
[...]
fan2:                 1054 RPM  (min =    0 RPM, div = 8)
[...]

# sensors
[...]
fan2:                 1095 RPM  (min =    0 RPM, div = 8)
[...]

# sensors
[...]
fan2:                 1061 RPM  (min =    0 RPM, div = 8)
[...]


So, in short, it looks like it's correct that this is a minimum, but it 
might get triggered very early in the cycle or so and when re-setting 
the alarm due to that re-writing of the minimum, everything is OK.

Robert Kaiser


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan RPM

[Robert Kaiser]

Robert Kaiser schrieb:
> nct6775-isa-0290

> in1: +1.11 V (min = +0.00 V, max = +0.00 V) ALARM
> in4: +1.02 V (min = +0.00 V, max = +0.00 V) ALARM
> in5: +1.05 V (min = +0.00 V, max = +0.00 V) ALARM
> in6: +1.08 V (min = +0.00 V, max = +0.00 V) ALARM

So I guess we don't know what they are and therefore they have the 
default names and probably "bogus" values, right?

> fan2: 1110 RPM (min = 0 RPM, div = 32) ALARM

This is the CPU fan here, FWIW.

> SYSTIN: +39.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = diode
> CPUTIN: +38.0°C (high = +80.0°C, hyst = +75.0°C) sensor = diode
> SMBUSMASTER 1: +54.0°C (high = +80.0°C, hyst = +75.0°C) sensor = diode
> PCH_CHIP_CPU_MAX_TEMP: +65.0°C
> SMBUSMASTER 2: +0.0°C (high = +80.0°C, hyst = +75.0°C)

What do those actually mean? Is there some doc about them that an 
non-wizard like me can understand?

Robert Kaiser



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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Ian Dobson]

Hello Robert,

--------------------------------------------------
From: "Robert Kaiser" <kairo@kairo.at>
Sent: Thursday, March 10, 2011 9:08 PM
To: <lm-sensors@lm-sensors.org>
Subject: Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan 
RPMsignal de-bounce

> Robert Kaiser schrieb:
>> nct6775-isa-0290
>
>> in1: +1.11 V (min = +0.00 V, max = +0.00 V) ALARM
>> in4: +1.02 V (min = +0.00 V, max = +0.00 V) ALARM
>> in5: +1.05 V (min = +0.00 V, max = +0.00 V) ALARM
>> in6: +1.08 V (min = +0.00 V, max = +0.00 V) ALARM
>
> So I guess we don't know what they are and therefore they have the default 
> names and probably "bogus" values, right?
>

Any chance you can have a look in the BIOS and email the exact values you 
see there. The chip can only handle 0-2.048volts so the 5 and 12 volts go 
through a voltage divider before going to the chip. This voltage divider 
information needs to be added to the sensors3.conf. What motherboard do you 
have? Maybe the manufacturer has some documentation.

This is the configuration I'm using for my n6776f/asus board
chip "nct6775-*" "nct6776-*"
# nct6776 values for Asus p8p67 pro
    label in0 "Vcore"
    set in0_min  1 * 0.9
    set in0_max  1.2 * 1.05

    label in1 "+12V"
    compute in1 @ * 12, @ / 12
    set in1_min  12 * 0.90
    set in1_max  12 * 1.15

    label in2 "AVCC"
    set in2_min  3.3 * 0.90
    set in2_max  3.3 * 1.10

    label in3 "+3.3V"
    set in3_min  3.3 * 0.90
    set in3_max  3.3 * 1.10

    label in4 "+5V"
    compute in4 @ * 5, @ / 5
    set in4_min  5 * 0.90
    set in4_max  5 * 1.10

    ignore in5

    label in7 "3VSB"
    set in7_min  3.3 * 0.90
    set in7_max  3.3 * 1.10

    label in8 "Vbat"
    set in8_min  3.0 * 0.90
    set in8_max  3.0 * 1.15

Maybe something similar would be correct for your board. If you add this to 
your config file

>> fan2: 1110 RPM (min = 0 RPM, div = 32) ALARM
>
> This is the CPU fan here, FWIW.
>
>> SYSTIN: +39.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = diode
>> CPUTIN: +38.0°C (high = +80.0°C, hyst = +75.0°C) sensor = diode
>> SMBUSMASTER 1: +54.0°C (high = +80.0°C, hyst = +75.0°C) sensor = diode
>> PCH_CHIP_CPU_MAX_TEMP: +65.0°C
>> SMBUSMASTER 2: +0.0°C (high = +80.0°C, hyst = +75.0°C)
>
> What do those actually mean? Is there some doc about them that an 
> non-wizard like me can understand?
>
> Robert Kaiser
>
>
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Regards
Ian Dobson
 


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Robert Kaiser]

Ian Dobson schrieb:
> Any chance you can have a look in the BIOS and email the exact values
> you see there.

Ah, right, good idea, wrote a note and will do so tomorrow when I get up 
and boot the machine!

> What
> motherboard do you have? Maybe the manufacturer has some documentation.

As I mentioned in the first message where I posted this, I have an Intel 
DH67CL - as this is one of the relatively new Sandy Bridge 
graphics-enabled board, I guess we'll see those in wider circulation in 
the next months (esp. once the B3 version with the fixed SATA channels 
is available everywhere).

> Maybe something similar would be correct for your board. If you add this
> to your config file

I'll look into that - are your values better for those voltages that 
already get named (and calculated) by Guenther's standalone driver or 
are those just duplicates of what it already does by default?

Robert Kaiser


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Guenter Roeck]

On Thu, Mar 10, 2011 at 04:03:58PM -0500, Robert Kaiser wrote:
> Ian Dobson schrieb:
> > Any chance you can have a look in the BIOS and email the exact values
> > you see there.
> 
> Ah, right, good idea, wrote a note and will do so tomorrow when I get up 
> and boot the machine!
> 
> > What
> > motherboard do you have? Maybe the manufacturer has some documentation.
> 
> As I mentioned in the first message where I posted this, I have an Intel 
> DH67CL - as this is one of the relatively new Sandy Bridge 
> graphics-enabled board, I guess we'll see those in wider circulation in 
> the next months (esp. once the B3 version with the fixed SATA channels 
> is available everywhere).
> 
> > Maybe something similar would be correct for your board. If you add this
> > to your config file
> 
> I'll look into that - are your values better for those voltages that 
> already get named (and calculated) by Guenther's standalone driver or 
> are those just duplicates of what it already does by default?
> 
Hi Robert,

this is what I configured for my board (Intel DH57JG). Some of it is guessing,
some of it is common practice with Winbond/Nuvoton chips.

chip "nct6775-*"

    label in0 "VCore"
    label in1 "+12V"
    label in2 "AVCC"
    label in3 "+3.3V"
    label in4 "+5V"
    label in5 "+1.5V"
#    label in6 "VIN3"
    label in7 "VSB"
    label in8 "VBAT"

    compute in1 (16 *@) ,  (@/16)
    compute in4 (4*@) ,  (@/4)
    compute in5 (2*@) ,  (@/2)
#    compute in6 (5*@) ,  (@/5)

    set in0_min   0.5
    set in1_min   12*0.9
    set in1_max   12*1.1
    set in2_min   3.3*0.9
    set in2_max   3.3*1.1
    set in3_min   3.3*0.95
    set in3_max   3.3*1.05
    set in4_min   5*0.95
    set in4_max   5*1.05
    set in5_min   1.5*0.95
    set in5_max   1.5*1.05
    set in7_min  3.3 * 0.90
    set in7_max  3.3 * 1.10
    set in8_min  3.0 * 0.90
    set in8_max  3.0 * 1.10

    ignore in6

Regarding the temperature sensor labels - those are straight from the chip manual.
The NCT677x chips are quite flexible in temperature channel to fan control assignments.
SYSTIN, CPUIN, and AUXTIN are actual pins on the NCT6557F, the PCH_ values are
from the PCH (Sandy Bridge in your case), and then there are several PECI channel
values which come from the CPU. The complete list of possible temperature sources
for NCT6775F is

SYSTIN
CPUTIN
AUXTIN
AMD SB-TSI
PECI Agent 0
PECI Agent 1
PECI Agent 2
PECI Agent 3
PECI Agent 4
PECI Agent 5
PECI Agent 6
PECI Agent 7
PCH_CHIP_CPU_MAX_TEMP
PCH_CHIP_TEMP
PCH_CPU_TEMP
PCH_MCH_TEMP
PCH_DIMM0_TEMP
PCH_DIMM1_TEMP
PCH_DIMM2_TEMP
PCH_DIMM3_TEMP

Hope this helps,

Guenter


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Guenter Roeck]

Hi Robert,

On Thu, Mar 10, 2011 at 03:05:04PM -0500, Robert Kaiser wrote:
> Guenter Roeck schrieb:
> > On Thu, Mar 10, 2011 at 06:53:28AM -0500, Guenter Roeck wrote:
> > [ ... ]
> >>>
> >>> So first question is what chip he has.
> >>>
> >> ... answer is NCT6775F, from Robert's log. It uses the "old" registers for the min
> >> speed settings, so presumably that should be correct. Yet, there must be a reason
> >> for the alarm. Maybe it is the "maximum RPM" register after all - the NCT6775F
> >> has that set of registers as well.
> >>
> > Doesn't look like the "maximum RPM" register is the culprit. I have a system with NCT6775F
> > (not using its fan controls, though). Looks like one can not write into that register, so it
> > must be a status register. Maybe it reports the maximum RPM the chip has seen.
> 
> OK, so here's a bit of shortened output of my tests:
> 
> 
> # echo 5000 > /sys/devices/platform/w83627ehf.656/fan2_min
> # sensors
> [...]
> fan2:                    0 RPM  (min = 5037 RPM, div = 4)
> [...]
> 
> # sensors
> [...]
> fan2:                 1102 RPM  (min = 5113 RPM, div = 8)  ALARM
> [...]
> 
> # sensors
> [...]
> fan2:                 1095 RPM  (min = 5113 RPM, div = 8)  ALARM
> [...]
> 
> # sensors
> [...]
> fan2:                 1061 RPM  (min = 5113 RPM, div = 8)  ALARM
> [...]
> 
> # echo 0 > /sys/devices/platform/w83627ehf.656/fan2_min
> # sensors
> [...]
> fan2:                 1054 RPM  (min =    0 RPM, div = 8)
> [...]
> 
> # sensors
> [...]
> fan2:                 1095 RPM  (min =    0 RPM, div = 8)
> [...]
> 
> # sensors
> [...]
> fan2:                 1061 RPM  (min =    0 RPM, div = 8)
> [...]
> 
> 
> So, in short, it looks like it's correct that this is a minimum, but it 
> might get triggered very early in the cycle or so and when re-setting 
> the alarm due to that re-writing of the minimum, everything is OK.
> 
Looks like it.

Thanks a lot for the testing!

Guenter

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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Robert Kaiser]

Guenter Roeck schrieb:
> this is what I configured for my board (Intel DH57JG). Some of it is guessing,
> some of it is common practice with Winbond/Nuvoton chips.

I'll look into applying your settings and see how well they work, but 
I'll first get the BIOS reading tomorrow as Ian suggested.


> Regarding the temperature sensor labels - those are straight from the chip manual.

OK, so I have those:

SYSTIN:                +40.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM 
  sensor = diode

I guess this means "System temperature", whatever that means in practice 
as to where the sensor sits (I've never fully understood that one, even 
on older systems where it often was called "MB temp" or so).

CPUTIN:                +39.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor 
= diode

That one is probably "CPU temperature" from a CPU sensor in the style as 
it's existed for ages, even before the cores had their own additional 
sensors.

SMBUSMASTER 1:         +55.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor 
= diode

Hmm, that seems to be an "SMBUS MASTER", wherever that one really sits 
in practice (fun that it's hotter than the other two).

PCH_CHIP_CPU_MAX_TEMP: +65.0°C

Is that some allowed max temp of the CPU (i.e. where it shuts down) or 
the highest seen temp of the CPU?

SMBUSMASTER 2:          +0.0°C  (high = +80.0°C, hyst = +75.0°C)

Not sure what that is, given that it seems to be zero (and I'm sure 
nothing in my system is at freezing temperature, even if we had that 
outside a few times in the last week).

> PCH_MCH_TEMP
> PCH_DIMM0_TEMP
> PCH_DIMM1_TEMP
> PCH_DIMM2_TEMP
> PCH_DIMM3_TEMP

Now those would sound cool, but I guess it's not reporting them.

Robert Kaiser



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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Guenter Roeck]

On Thu, Mar 10, 2011 at 06:17:55PM -0500, Robert Kaiser wrote:
> Guenter Roeck schrieb:
> > this is what I configured for my board (Intel DH57JG). Some of it is guessing,
> > some of it is common practice with Winbond/Nuvoton chips.
> 
> I'll look into applying your settings and see how well they work, but 
> I'll first get the BIOS reading tomorrow as Ian suggested.
> 
> 
> > Regarding the temperature sensor labels - those are straight from the chip manual.
> 
> OK, so I have those:
> 
> SYSTIN:                +40.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM 
>   sensor = diode
> 
> I guess this means "System temperature", whatever that means in practice 
> as to where the sensor sits (I've never fully understood that one, even 
> on older systems where it often was called "MB temp" or so).
> 
> CPUTIN:                +39.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor 
> = diode
> 
> That one is probably "CPU temperature" from a CPU sensor in the style as 
> it's existed for ages, even before the cores had their own additional 
> sensors.
> 
That really depends on the board, but, yes, pretty likely.

> SMBUSMASTER 1:         +55.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor 
> = diode
> 
> Hmm, that seems to be an "SMBUS MASTER", wherever that one really sits 
> in practice (fun that it's hotter than the other two).
> 
> PCH_CHIP_CPU_MAX_TEMP: +65.0°C
> 
> Is that some allowed max temp of the CPU (i.e. where it shuts down) or 
> the highest seen temp of the CPU?
> 
> SMBUSMASTER 2:          +0.0°C  (high = +80.0°C, hyst = +75.0°C)
> 
> Not sure what that is, given that it seems to be zero (and I'm sure 
> nothing in my system is at freezing temperature, even if we had that 
> outside a few times in the last week).
> 
> > PCH_MCH_TEMP
> > PCH_DIMM0_TEMP
> > PCH_DIMM1_TEMP
> > PCH_DIMM2_TEMP
> > PCH_DIMM3_TEMP
> 
> Now those would sound cool, but I guess it's not reporting them.
> 
Agreed. But you might be able to see the DIMM temperatures (if you have DDR3)
by loading the "jc42" module.

Actually, I just had a look at the code again. Turns out there is a bug; you see
the labels associated with NCT6776F, not NCT6775F. Real values should be "PECI Agent 0"
instead of "SMBUSMASTER 1", "PECI Agent 1" instead of "SMBUSMASTER 2",
and "PCH_CHIP_TEMP" instead of "PCH_CHIP_CPU_MAX_TEMP". I'll fix that immediately.
So the temperatures you see as "SMBUSxxx" are really temperatures reported by the CPU.
Just don't ask me why the CPU would report 0 degrees C ;).

Thanks,
Guenter

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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Robert Kaiser]

Guenter Roeck schrieb:
> Agreed. But you might be able to see the DIMM temperatures (if you have DDR3)
> by loading the "jc42" module.

Hmm, doesn't seem to work, after loading jc43, I don't see anything new 
appearing in sensors output.

> Actually, I just had a look at the code again. Turns out there is a bug; you see
> the labels associated with NCT6776F, not NCT6775F. Real values should be "PECI Agent 0"
> instead of "SMBUSMASTER 1", "PECI Agent 1" instead of "SMBUSMASTER 2",
> and "PCH_CHIP_TEMP" instead of "PCH_CHIP_CPU_MAX_TEMP". I'll fix that immediately.

Ah, that makes sense, even if it's interesting that the PCH Chip is so 
much hotter than the CPU, but then it doesn't have a fan attached to it 
and still enough work, so sounds reasonable. And "PECI Agent 0" being 
similar to the values from coretemp is also probably reasonable, as IIRC 
PECI means something similar to that, right?

> So the temperatures you see as "SMBUSxxx" are really temperatures reported by the CPU.
> Just don't ask me why the CPU would report 0 degrees C ;).

The i7-2600K is just an incredibly cool CPU, I guess. ;-)

Robert Kaiser


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Guenter Roeck]

Hi Robert,

On Thu, Mar 10, 2011 at 07:04:55PM -0500, Robert Kaiser wrote:
> Guenter Roeck schrieb:
> > Agreed. But you might be able to see the DIMM temperatures (if you have DDR3)
> > by loading the "jc42" module.
> 
> Hmm, doesn't seem to work, after loading jc43, I don't see anything new 
> appearing in sensors output.
> 
jc42, not jc43.

> > Actually, I just had a look at the code again. Turns out there is a bug; you see
> > the labels associated with NCT6776F, not NCT6775F. Real values should be "PECI Agent 0"
> > instead of "SMBUSMASTER 1", "PECI Agent 1" instead of "SMBUSMASTER 2",
> > and "PCH_CHIP_TEMP" instead of "PCH_CHIP_CPU_MAX_TEMP". I'll fix that immediately.
> 
> Ah, that makes sense, even if it's interesting that the PCH Chip is so 
> much hotter than the CPU, but then it doesn't have a fan attached to it 
> and still enough work, so sounds reasonable. And "PECI Agent 0" being 
> similar to the values from coretemp is also probably reasonable, as IIRC 
> PECI means something similar to that, right?
> 
No idea, but I guess so.

> > So the temperatures you see as "SMBUSxxx" are really temperatures reported by the CPU.
> > Just don't ask me why the CPU would report 0 degrees C ;).
> 
> The i7-2600K is just an incredibly cool CPU, I guess. ;-)
> 
Yes, and if you wire it up correctly you may be able to use it as refrigerator heat pump ;).

I copied a new version of the standalone driver to http://www.roeck-us.net/linux/drivers/w83627ehf/,
in case you want to give it a try.

Thanks,
Guenter

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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Robert Kaiser]

Guenter Roeck schrieb:
> On Thu, Mar 10, 2011 at 07:04:55PM -0500, Robert Kaiser wrote:
>> Guenter Roeck schrieb:
>>> Agreed. But you might be able to see the DIMM temperatures (if you have DDR3)
>>> by loading the "jc42" module.
>>
>> Hmm, doesn't seem to work, after loading jc43, I don't see anything new
>> appearing in sensors output.
>>
> jc42, not jc43.

Right. I actually did a |modprobe jc42| and that didn't bring anything 
new up in |sensors| output - but of course then I made a typo in here...

>>> So the temperatures you see as "SMBUSxxx" are really temperatures reported by the CPU.
>>> Just don't ask me why the CPU would report 0 degrees C ;).
>>
>> The i7-2600K is just an incredibly cool CPU, I guess. ;-)
>>
> Yes, and if you wire it up correctly you may be able to use it as refrigerator heat pump ;).

Hmm, I guess I have to look up _those_ plans! ;-)

> I copied a new version of the standalone driver to http://www.roeck-us.net/linux/drivers/w83627ehf/,
> in case you want to give it a try.

Tested and works, thanks!

Robert Kaiser


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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Guenter Roeck]

On Thu, Mar 10, 2011 at 07:58:44PM -0500, Robert Kaiser wrote:
> Guenter Roeck schrieb:
> > On Thu, Mar 10, 2011 at 07:04:55PM -0500, Robert Kaiser wrote:
> >> Guenter Roeck schrieb:
> >>> Agreed. But you might be able to see the DIMM temperatures (if you have DDR3)
> >>> by loading the "jc42" module.
> >>
> >> Hmm, doesn't seem to work, after loading jc43, I don't see anything new
> >> appearing in sensors output.
> >>
> > jc42, not jc43.
> 
> Right. I actually did a |modprobe jc42| and that didn't bring anything 
> new up in |sensors| output - but of course then I made a typo in here...
> 
Too bad. So either you don't have DDR3 (unlikely), or Intel didn't wire it up to an i2c bus.

> >>> So the temperatures you see as "SMBUSxxx" are really temperatures reported by the CPU.
> >>> Just don't ask me why the CPU would report 0 degrees C ;).
> >>
> >> The i7-2600K is just an incredibly cool CPU, I guess. ;-)
> >>
> > Yes, and if you wire it up correctly you may be able to use it as refrigerator heat pump ;).
> 
> Hmm, I guess I have to look up _those_ plans! ;-)
> 
> > I copied a new version of the standalone driver to http://www.roeck-us.net/linux/drivers/w83627ehf/,
> > in case you want to give it a try.
> 
> Tested and works, thanks!
> 
Thank you!

Guenter

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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Robert Kaiser]

Ian Dobson schrieb:
> Any chance you can have a look in the BIOS and email the exact values
> you see there.

Right at initial boot of the day I had this there (thought I'd give you 
all values and not just voltages, in case other settings warrant a 
comparison as well):

CPU Fan               1028 RPM
Front Fan                0 RPM
Rear Fan                 0 RPM

Processor Temperature   61°C
PCH Temperature         43°C
Memory Temperature      24°C
VR Temperature          31°C

+12.0V               12.23 V
+5.0V                 5.03 V
+3.3V                 3.32 V
Memory Vcc            1.57 V
Processor Vcc         1.20 V
PCH Vcc               1.08 V
+3.3 Standby          3.42 V

Now, a few hours later (sorry, didn't get to it right away), sensors 
gives me the following:

nct6775-isa-0290
Adapter: ISA adapter
Vcore:         +1.16 V  (min =  +0.00 V, max =  +1.74 V)
in1:           +1.11 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
AVCC:          +3.31 V  (min =  +2.98 V, max =  +3.63 V)
+3.3V:         +3.31 V  (min =  +2.98 V, max =  +3.63 V)
in4:           +1.02 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
in5:           +1.05 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
in6:           +1.08 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
3VSB:          +3.41 V  (min =  +2.98 V, max =  +3.63 V)
Vbat:          +3.38 V  (min =  +2.70 V, max =  +3.30 V)   ALARM
fan1:            0 RPM  (min =    0 RPM, div = 128)
fan2:         1081 RPM  (min =    0 RPM, div = 32)  ALARM
fan3:            0 RPM  (min =    0 RPM, div = 128)
fan4:            0 RPM  (div = 128)
SYSTIN:        +40.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM  sensor 
= diode
CPUTIN:        +39.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = diode
PECI Agent 0:  +55.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor = diode
PCH_CHIP_TEMP: +66.0°C
PECI Agent 1:   +0.0°C  (high = +80.0°C, hyst = +75.0°C)
cpu0_vid:     +2.050 V

(Just for future reference in case anyone else looks up this message 
independent of the thread, this is an Intel DH67CL board.)

Robert Kaiser



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

Re: [lm-sensors] RFC: nct6776f support in the w83627ehf and fan

[Guenter Roeck]

On Fri, Mar 11, 2011 at 12:09:22PM -0500, Robert Kaiser wrote:
> Ian Dobson schrieb:
> > Any chance you can have a look in the BIOS and email the exact values
> > you see there.
> 
> Right at initial boot of the day I had this there (thought I'd give you 
> all values and not just voltages, in case other settings warrant a 
> comparison as well):
> 
> CPU Fan               1028 RPM
> Front Fan                0 RPM
> Rear Fan                 0 RPM
> 
> Processor Temperature   61°C
> PCH Temperature         43°C
> Memory Temperature      24°C
> VR Temperature          31°C
> 
> +12.0V               12.23 V
> +5.0V                 5.03 V
> +3.3V                 3.32 V
> Memory Vcc            1.57 V
> Processor Vcc         1.20 V
> PCH Vcc               1.08 V
> +3.3 Standby          3.42 V
> 
> Now, a few hours later (sorry, didn't get to it right away), sensors 
> gives me the following:
> 

My wild guess:

> nct6775-isa-0290
> Adapter: ISA adapter
> Vcore:         +1.16 V  (min =  +0.00 V, max =  +1.74 V)
> in1:           +1.11 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
	= 12V (*11)

> AVCC:          +3.31 V  (min =  +2.98 V, max =  +3.63 V)
> +3.3V:         +3.31 V  (min =  +2.98 V, max =  +3.63 V)
> in4:           +1.02 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
	= 5V (*5)

> in5:           +1.05 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
	= Memory Vcc (*1.5)

> in6:           +1.08 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
	= PCH Vcc

> 3VSB:          +3.41 V  (min =  +2.98 V, max =  +3.63 V)
> Vbat:          +3.38 V  (min =  +2.70 V, max =  +3.30 V)   ALARM

Guenter

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