[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: lm-sensors problems



On 18 May 2001, David Z Maze <dmaze@debian.org> wrote:

>Philipp Lehman <lehman@gmx.net> writes:
>PL> In order to access the hardware sensors on my motherboard, I
>PL> installed the lm-sensors-source package and the corresponding
>PL> userland utilities. I need the i2c-viapro kernel module for my MB
>PL> (VIA KT133A/82c686b chipset).
>PL> 
>PL> Now, when I try to patch the kernel (stricly following the
>PL> instructions in the README and INSTALL files) not all lm-sensors
>PL> modules are offered when I try to make menuconfig afterwards. The
>PL> patches are applied fine without any errors, but the module I need
>PL> just doesn't show up in the I²C section of the kernel
>PL> configuration.
>
>You shouldn't need to patch the kernel; doing that probably just makes 
>a mess.  When I've built i2c modules, I've done them completely
>externally and it works fine.

Patching the kernel worked fine for me in the past, but I'll follow
your advice.

>PL> BTW: I also tried building the modules outside of the kernel source
>PL> tree, but compiling fails with an error message. I found an open bug
>PL> report filed against lm-sensors-source describing the same problem, so
>PL> I guess it's not just me overlooking something in this case.
>
>What's the error message?  I recently uploaded a new version of the
>lm-sensors package that cleaned up a couple of the more serious
>problems with it, so you might see if this solves your problem.  (In
>particular, it solves the "package doesn't actually contain modules"
>and the "build process tries to drop the package in the root
>directory" problems, the latter with a current kernel-package.)

I gave it another try, here's what I did. This is lm-sensors-source
2.4.4-1 and kernel 2.2.19 (built from kernel-source-2.2.19-3).

1. check Makefile in ./i2c
2. make in i2c using the lm-sensors method (that's completely outside
   the of the kernel source tree without versioning info, right?)
3. make install, depmod -a
4. check Makefile in ./lm_sensors2
5. make in lm_sensors2
6. it bails out (long):

In file included from kernel/sensors.c:32:
kernel/include/sensors.h:34: warning: `struct i2c_client' declared
inside parameter list
kernel/include/sensors.h:34: warning: its scope is only this
definition or declaration, which                                                                                                 
 is probably not what you want.
kernel/include/sensors.h:76: warning: `struct i2c_client' declared
inside parameter list
kernel/include/sensors.h:328: warning: `struct i2c_adapter' declared
inside parameter list
kernel/include/sensors.h:336: warning: `struct i2c_adapter' declared
inside parameter list
kernel/sensors.c:48: warning: `struct i2c_adapter' declared inside
parameter list
kernel/sensors.c:84: warning: initialization from incompatible pointer
type
kernel/sensors.c:108: warning: `struct i2c_adapter' declared inside
parameter list
kernel/sensors.c:109: conflicting types for `sensors_create_name'
kernel/sensors.c:48: previous declaration of `sensors_create_name'
kernel/sensors.c: In function `sensors_create_name':
kernel/sensors.c:112: dereferencing pointer to incomplete type
kernel/sensors.c:112: `I2C_ALGO_ISA' undeclared (first use in this
function)
kernel/sensors.c:112: (Each undeclared identifier is reported only
once
kernel/sensors.c:112: for each function it appears in.)
kernel/sensors.c: At top level:
kernel/sensors.c:138: conflicting types for `sensors_register_entry'
kernel/include/sensors.h:76: previous declaration of
`sensors_register_entry'
kernel/sensors.c: In function `sensors_register_entry':
kernel/sensors.c:144: dereferencing pointer to incomplete type
kernel/sensors.c:145: dereferencing pointer to incomplete type
kernel/sensors.c: In function `sensors_dir_fill_inode':
kernel/sensors.c:264: dereferencing pointer to incomplete type
kernel/sensors.c:266: dereferencing pointer to incomplete type
kernel/sensors.c: In function `sensors_proc_real':
kernel/sensors.c:368: warning: passing arg 1 of pointer to function
from incompatible pointer                                                                                                 
 type
kernel/sensors.c:378: warning: passing arg 1 of pointer to function
from incompatible pointer                                                                                                 
 type
kernel/sensors.c:384: warning: passing arg 1 of pointer to function
from incompatible pointer                                                                                                 
 type
kernel/sensors.c: In function `sensors_sysctl_real':
kernel/sensors.c:406: warning: passing arg 1 of pointer to function
from incompatible pointer                                                                                                 
 type
kernel/sensors.c:423: warning: passing arg 1 of pointer to function
from incompatible pointer                                                                                                 
 type
kernel/sensors.c: At top level:
kernel/sensors.c:602: warning: `struct i2c_adapter' declared inside
parameter list
kernel/sensors.c:603: conflicting types for `sensors_detect'
kernel/include/sensors.h:336: previous declaration of `sensors_detect'
kernel/sensors.c: In function `sensors_detect':
kernel/sensors.c:606: dereferencing pointer to incomplete type
kernel/sensors.c:606: `I2C_ALGO_ISA' undeclared (first use in this
function)
kernel/sensors.c:610: `I2C_FUNC_SMBUS_QUICK' undeclared (first use in
this function)
kernel/sensors.c:633: warning: passing arg 1 of pointer to function
from incompatible pointer                                                                                                 
 type
kernel/sensors.c:761: `I2C_SMBUS_QUICK' undeclared (first use in this
function)
kernel/sensors.c:762: warning: passing arg 1 of pointer to function
from incompatible pointer                                                                                                 
 type
make: *** [kernel/sensors.o] Error 1


-- 
Philipp Lehman <lehman@gmx.net>



Reply to: