[lm-sensors] ASUS NCCH-DR confusing 83792 vs. 83627THF

[lm-sensors] ASUS NCCH-DR confusing 83792 vs. 83627THF

[J. W. Andersen]

Hi list - I am as confused as I ever want to be, hope someone can help.

I have build a brand new server for SuSE 10, using ASUS NCCH-DR, and 
everything
works fine, apart from the HW monitoring.

The only "likely" chip I can see on the board is a Winbond W83627THF, 
but according
to ASUS support the HW monitoring chip should be W83792D (even if I 
can't find it).

The block diagram  (attached) in the users manual however shows both the 
mentioned chips.
W83792 is on the SMbus providing HW monitoring functions for fans, PSU 
and eeprom,
whereas the W83627THF is on the LPC bus, providing keyboard, FDD, serial 
and mouse ports.
Both busses are on an Intel 6300ESB ICH.

sensors-detect finds and setup drivers for i2c-i810, i2c-isa, i2c-dev, 
eeprom and w83627hf.
It does not find w83792d, and does not even test for it, according to 
output. When running
sensors, i get a number of rather weird values:

w83627thf-isa-0290
Adapter: ISA adapter
VCore:     +1.94 V  (min =  +1.94 V, max =  +1.94 V)             
+12V:      +7.60 V  (min = +10.82 V, max = +13.19 V)       ALARM 
+3.3V:     +3.34 V  (min =  +3.14 V, max =  +3.47 V)             
+5V:       +4.96 V  (min =  +4.75 V, max =  +5.25 V)             
-12V:      +6.06 V  (min = -10.80 V, max = -13.18 V)       ALARM 
V5SB:      +5.00 V  (min =  +4.76 V, max =  +5.24 V)             
VBat:      +0.00 V  (min =  +2.40 V, max =  +3.60 V)       ALARM 
fan1:        0 RPM  (min = 4891 RPM, div = 2)              ALARM 
CPU Fan:     0 RPM  (min = 37500 RPM, div = 2)              ALARM 
fan3:        0 RPM  (min = 28125 RPM, div = 2)              ALARM 
M/B Temp:    -48?C  (high =  +104?C, hyst =    +0?C)   sensor = 
thermistor          
CPU Temp:  -48.0?C  (high =   +80?C, hyst =   +75?C)   sensor = 
thermistor          
temp3:     -48.0?C  (high =   +80?C, hyst =   +75?C)   sensor = 
thermistor          
alarms:   Chassis intrusion detection                      ALARM
beep_enable:
          Sound alarm enabled

The other thing that puzzles me: In an X86_64 system, I would expect to find
the libsensor libraries in a the /lib64 directory, but they actually get 
nstalled
in /usr/local/lib. What must I do to get these libraries in the proper 
place ?

Regards, Joern.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: NCCH-DR.pdf
Type: application/pdf
Size: 15194 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060614/80d13307/attachment-0001.pdf 

[lm-sensors] ASUS NCCH-DR confusing 83792 vs. 83627THF

[Rudolf Marek]

Hi J.

> I have build a brand new server for SuSE 10, using ASUS NCCH-DR, and
> everything
> works fine, apart from the HW monitoring.

Lets fix it.

> The only "likely" chip I can see on the board is a Winbond W83627THF,
> but according
> to ASUS support the HW monitoring chip should be W83792D (even if I
> can't find it).

It is "hidden" using the multiplexer. Please upgrade to latest BIOS.
If sensors-detect cannot find it - we have a contact at ASUS and they will fix it.

> w83627thf-isa-0290
> Adapter: ISA adapter
> VCore:     +1.94 V  (min =  +1.94 V, max =  +1.94 V)            
> +12V:      +7.60 V  (min = +10.82 V, max = +13.19 V)       ALARM
> +3.3V:     +3.34 V  (min =  +3.14 V, max =  +3.47 V)            
> +5V:       +4.96 V  (min =  +4.75 V, max =  +5.25 V)            
> -12V:      +6.06 V  (min = -10.80 V, max = -13.18 V)       ALARM
> V5SB:      +5.00 V  (min =  +4.76 V, max =  +5.24 V)            
> VBat:      +0.00 V  (min =  +2.40 V, max =  +3.60 V)       ALARM
> fan1:        0 RPM  (min = 4891 RPM, div = 2)              ALARM CPU
> Fan:     0 RPM  (min = 37500 RPM, div = 2)              ALARM
> fan3:        0 RPM  (min = 28125 RPM, div = 2)              ALARM M/B
> Temp:    -48?C  (high =  +104?C, hyst =    +0?C)   sensor > thermistor          CPU Temp:  -48.0?C  (high =   +80?C, hyst =  
> +75?C)   sensor = thermistor          temp3:     -48.0?C  (high =  
> +80?C, hyst =   +75?C)   sensor = thermistor          alarms:   Chassis
> intrusion detection                      ALARM
> beep_enable:
>          Sound alarm enabled
>

This chip is known to be unused for the fans/temps. You dont need to load this
driver.

> The other thing that puzzles me: In an X86_64 system, I would expect to
> find
> the libsensor libraries in a the /lib64 directory, but they actually get
> nstalled
> in /usr/local/lib. What must I do to get these libraries in the proper
> place ?
> 

# You should not need to change this. It is the directory into which the

# library files (both static and shared) will be installed.

LIBDIR := $(PREFIX)/lib

maybe you can change this to lib64 so the dir will be /usr/local/lib64 but I
dont know if such directory can exist.

You may also change the PREFIX to / to get it to /lib64 if you like. (all in top
Makefile)

Hope it helps,

Regards
Rudolf

[lm-sensors] ASUS NCCH-DR confusing 83792 vs. 83627THF

[Jean Delvare]

> > The other thing that puzzles me: In an X86_64 system, I would expect to
> > find the libsensor libraries in a the /lib64 directory, but they actually
> > get installed in /usr/local/lib. What must I do to get these libraries
> > in the proper place ?
> 
> # You should not need to change this. It is the directory into which the
> 
> # library files (both static and shared) will be installed.
> 
> LIBDIR := $(PREFIX)/lib
> 
> maybe you can change this to lib64 so the dir will be /usr/local/lib64 but I
> dont know if such directory can exist.

I can't get why some distributions invented these lib64 directories. On
32-bit systems we have lib, not lib32, so why make it different on
64-bit systems? It may make sense to have a lib32 directory on 64-bit
systems for libraries which are only available in 32-bit format, Gentoo
is doing it almost this way (lib is a link to lib64, and there is lib32
for the 32-bit libraries), but doing it the other way around sounds
weird to me.

However if most distributions do that... Maybe we should detect 64-bit
systems and change the default in this case. Anyone wants to give it a
try?

At any rate, nothing will break if you install your 64-bit
libsensors.so under /usr/local/lib, I'm doing this and it works just
fine.

I wonder why you are installing it by yourself, rather that using the
suse package which would put everything in the right place for you?

> You may also change the PREFIX to / to get it to /lib64 if you like. (all in top
> Makefile)

This would be a very bad idea. /lib (and /lib64) are meant for
libraries fundamental to the system, libsensors sure doesn't qualify.

-- 
Jean Delvare

[lm-sensors] ASUS NCCH-DR confusing 83792 vs. 83627THF

[J. W. Andersen]

Hi rudolf, thanks a lot for your quick reply - and for clearing me up 
about the chip hidden
in the mulriplexor.

Rudolf Marek wrote:
> It is "hidden" using the multiplexer. Please upgrade to latest BIOS.
> If sensors-detect cannot find it - we have a contact at ASUS and they will fix it.
>
>   
BIOS is already version 1005,  which is the latest - and presumably 
greatest - according to ASUS
download pages.  Looks like we need your ASUS contact anyway...
>>     
>
> This chip is known to be unused for the fans/temps. You dont need to load this
> driver.
>
>   
Duly noted.
>> The other thing that puzzles me: In an X86_64 system, I would expect to
>> find
>> the libsensor libraries in a the /lib64 directory, but they actually get
>> nstalled
>> in /usr/local/lib. What must I do to get these libraries in the proper
>> place ?
>>
>>     
>
> # You should not need to change this. It is the directory into which the
>
> # library files (both static and shared) will be installed.
>
> LIBDIR := $(PREFIX)/lib
>
> maybe you can change this to lib64 so the dir will be /usr/local/lib64 but I
> dont know if such directory can exist.
>
> You may also change the PREFIX to / to get it to /lib64 if you like. (all in top
> Makefile)
>
>   

Well, I am not sure of the significance of this. Probably the system 
will just look in the  normal library
path (such as /usr/local/lib) if it cannot find the libraries in 
/usr/lib64. Will try to figure that out from here.

Going on standby till you get the news from ASUS - tnx again !

Regards, Joern.

[lm-sensors] ASUS NCCH-DR confusing 83792 vs. 83627THF

[J. W. Andersen]

Thanks, Jean, for clearing this up for me.

Joern.

Jean Delvare wrote:
>>> The other thing that puzzles me: In an X86_64 system, I would expect to
>>> find the libsensor libraries in a the /lib64 directory, but they actually
>>> get installed in /usr/local/lib. What must I do to get these libraries
>>> in the proper place ?
>>>       
>> # You should not need to change this. It is the directory into which the
>>
>> # library files (both static and shared) will be installed.
>>
>> LIBDIR := $(PREFIX)/lib
>>
>> maybe you can change this to lib64 so the dir will be /usr/local/lib64 but I
>> dont know if such directory can exist.
>>     
>
> I can't get why some distributions invented these lib64 directories. On
> 32-bit systems we have lib, not lib32, so why make it different on
> 64-bit systems? It may make sense to have a lib32 directory on 64-bit
> systems for libraries which are only available in 32-bit format, Gentoo
> is doing it almost this way (lib is a link to lib64, and there is lib32
> for the 32-bit libraries), but doing it the other way around sounds
> weird to me.
>
> However if most distributions do that... Maybe we should detect 64-bit
> systems and change the default in this case. Anyone wants to give it a
> try?
>
> At any rate, nothing will break if you install your 64-bit
> libsensors.so under /usr/local/lib, I'm doing this and it works just
> fine.
>
> I wonder why you are installing it by yourself, rather that using the
> suse package which would put everything in the right place for you?
>
>   
>> You may also change the PREFIX to / to get it to /lib64 if you like. (all in top
>> Makefile)
>>     
>
> This would be a very bad idea. /lib (and /lib64) are meant for
> libraries fundamental to the system, libsensors sure doesn't qualify.
>
>   

[lm-sensors] ASUS NCCH-DR confusing 83792 vs. 83627THF

[Henrik Brix Andersen]

On Wed, Jun 14, 2006 at 06:04:37PM +0200, Jean Delvare wrote:
> I can't get why some distributions invented these lib64 directories. On
> 32-bit systems we have lib, not lib32, so why make it different on
> 64-bit systems? It may make sense to have a lib32 directory on 64-bit
> systems for libraries which are only available in 32-bit format, Gentoo
> is doing it almost this way (lib is a link to lib64, and there is lib32
> for the 32-bit libraries), but doing it the other way around sounds
> weird to me.

The distributions didn't invent this - it's part of the FHS:
http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64

I don't think the lm_sensors Makefile should attempt to be smart and
install to lib64 on 64bit systems. This should be left up to the
package manager of the distribution. If users wish to have libsensors
installed to another directory, they are free to overload the library
path on the make commandline ("make LIBDIR=/lib64 user_install").

Regards,
Brix
-- 
Henrik Brix Andersen <brix at gentoo.org>
Gentoo Metadistribution | Mobile computing herd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060614/63642d50/attachment-0001.bin 

[lm-sensors] ASUS NCCH-DR confusing 83792 vs. 83627THF

[Rudolf Marek]

> BIOS is already version 1005,  which is the latest - and presumably 
> greatest - according to ASUS
> download pages.  Looks like we need your ASUS contact anyway...
>>>     

Hello I'm sending you in private the latest beta BIOS which works in ASUS lab.
(If anyone else needs this BIOS let me know)

-- 
Thanks,
Rudolf

SYSGO | Real-Time Solutions | ELinOS Embedded Linux | http://www.sysgo.com