FAQ/Chapter2

Go back to FAQ

Chapter 2: Installation and Management

Why so many modules, and how do I cope with them?

We tried to make this package as modular as possible. This makes it easy to add new drivers, and unused drivers will take no precious kernel space. On the other hand, it can be a bit confusing at first.

Here are two simple guidelines:

  • Run sensors-detect and do what it tells you.
  • Always use modprobe, not insmod.

Further information is in doc/modules.

How do I know which chips I own?

We have an excellent program that scans all your hardware. It is called sensors-detect and is installed in /usr/local/sbin by make install. Just execute this script, and it will tell you.

Chip detection in the drivers is fairly good. That means that it is usually harmless to insert more chip drivers than you need. However, this can still lead to problems, so we do not recommend it.

If sensors-detect didn't find any sensors, either you don't have any, or the ones you have, we don't support. (Look at your motherboard for candidates, then see Help)

What chips are on motherboard XYZ?

!!!!!!!!! YES THIS IS THE MOST FREQUENT QUESTION WE GET !!!!!!!!!

We have no idea. Here is what you should do:

  1. Run sensors-detect. If that doesn't work read on:
  2. Look at your motherboard.
  3. Check the manufacturer's website or ask their support
  4. Check the Motherboard Monitor website and the "links" page on our website some good cross-references.

Or you may try our Installation wizard

Do you support motherboard XYZ?

We don't support boards, we support chips. See What chips are on motherboard XYZ.

Do you support chip XYZ?

This we have good answers for.

Anybody working on a driver for chip XYZ?

Newest Driver Status?

Which modules should I insert?

sensors-detect will tell you. Take the modprobe lines it recommends and paste them into the appropriate /etc/rc.d/xxxx file to be executed at startup.

You need one module for each sensor chip and bus adapter you own; if there are sensor chips on the ISA bus, you also need i2c-isa.o. for each type of chip you own. That's all. On my computer, I could use the following lines:

modprobe i2c-isa
modprobe i2c-piix4
modprobe lm78
modprobe lm75
modprobe i2c-dev
sensors -s

Help, I do not have smbus-arp!

You don't need it. This driver has not much use except for testing SMBus 2.0 ARP and PEC support in the i2c layer.

Do I need the configuration file /etc/sensors.conf?

Yes, for any applications that use libsensors, including the sensors application included in our package. It tells libsensors how to translate the values the chip measures to real-world values. This is especially important for voltage inputs. The default configuration file should usually do the trick. It is automatically installed as /etc/sensors.conf, but it will not overwrite any existing file with that name.

The labels for the voltage and temperature readings in sensors are incorrect!

Every motherboard is different. You can customize the labels in the file /etc/sensors.conf. That's why it exists! The default labelling (in lib/chips.c and /etc/sensors.conf) is just a template.

The min and max for the readings in sensors are incorrect!

You can customize them in the file /etc/sensors.conf. See above.

The min and max settings in /etc/sensors.conf didn't take effect!

You forgot to run sensors -s. See above.

One sensor isn't hooked up on my board!

Use an ignore line in /etc/sensors.conf so it isn't displayed in sensors.

I need help with sensors.conf!

There is detailed help at the top of that file.

Do you have a database of sensors.conf entries for specific boards?

No. Good idea though. If you would like to set one up on your website send us mail and we will set up a link to it.

What about the No such file or directory warnings when I compile?

Don't worry about them. The dependency files (which tell which files should be recompiled when certain files change) are created dynamically. They are not distributed with the package. The make program notices they are not there, and warns about that - and the first thing it will do is generate them. So all is well.

I get all kinds of weird compilation errors?

Check that the correct i2c header files are used. Depending on how you installed, they should be under either /usr/local/include or /usr/src/linux*/include. Try to edit the Makefile for the other setting.

No rule to make target xxxx needed by xxxx - how to fix?

  • See I get all kinds of weird compilation errors, also try make clean in lm_sensors.
  • If that doesn't work, try make clean in i2c.
  • If that doesn't work, try make clean in the kernel.
  • Also make sure /usr/include/linux points to /usr/src/linux/include/linux.

It still does not compile or patch!

Have you installed the matching version of the i2c package? Remember, compilation is not enough, you also need to install it for the header files to be found!

If you want to patch the kernel, you will have to apply the i2c patches first!

make install fails on Mandrake kernels

Mandrake uses a non-standard version.h file which confuses our Makefile. Edit our Makefile on the MODDIR := line to hard-code the module directory.

I get unresolved symbols when I modprobe modules (Red Hat especially)

Example:

 *** Unresolved symbols in /lib/modules/2.4.5/kernel/drivers/i2c/i2c-i810.o

     i2c_bit_add_bus_R8c3bc60e

     i2c_bit_del_bus_R92b18f49

You can also run depmod -a -e to see all unresolved symbols.

These are module versioning problems. Generally you did not compile against the kernel you are running. Sometimes the Red Hat source you have is not for the kernel you are running. You must compile our package against the source for the kernel you are running with something like make LINUX=/usr/src/linux-2.4.14.

Try the following to be sure:

  • nm --extern MODULE.o Filter out the kernel symbols, like kmalloc, printk etc. and note the number code behind them, like printk_R1b7d4074. If there is no numeric code after them, note this too.
  • grep SYMBOL /proc/ksyms Substitute SYMBOL by the basename of the symbols above, like kmalloc, printk etc. Note the number code behind them, or the lack thereof.
  • Compare both sets of symbols. Are they the same? If so, the problem lies somewhere else. Are they different? If so, you have a module versioning problem.

I2C_DRIVERID_ADM1024 undefined (Red Hat especially)

In some versions of Redhat, an RPM is included to provide i2c support. However, this RPM does not place the header files in the kernel directory structure. When you update kernels, they may persist. To get rid of these obsolete header files, at a command prompt:

  1. rpm -qa | grep i2c
  1. Look for kernel-i2c, or a similar rpm in the output
  1. <as root> rpm -ev kernel-i2c (or the name of the similar package) If this complains about dependencies, you can try adding --nodeps, but this *MAY* break something else. Not likely, as you have upgraded kernels, and nothing should be using the old i2c stuff anymore anyway. Just don't use it with abandon.
  1. Try (in the build directory of lm_sensors)
make clean

make

  1. If you still have problems, you may have to replace the include paths in the .c/.h files with absolute paths to the header files. More of a workaround than a real fix, but at least you can get it to work.