Go back to FAQ

How to Ask for Help

What to send us when asking for help

We are always willing to answer questions if things don't work out. Post your question to our discussion list, and not the individual authors, unless you have something private to say.

Instead of using email, you can also use the web-based support area, at Support page You will be helped just as fast, and others may profit from the answer too. You will be emailed automatically when your question has been answered.

Here's what you should send us:

• The dmesg or syslog output if applicable

• The output of (as root) prog/detect/sensors-detect

• The output of lsmod

• If a PCI chip problem:

• The output of lspci -n

• If an I2C sensor chip problem:

• The output of (as root) prog/detect/i2cdetect X where X = the bus number (run i2cdetect with no arguments to list the busses) (please send this only if it's not all XX)

• The output of (as root) prog/dump/i2cdump X 0xXX where XX = the address of each chip you see in the output of i2cdetect. (run once for each chip) (please send this only if it's not all ff)

• If an ISA sensor chip problem:

• The output of (as root) prog/dump/isadump 0x295 0x296 (only if it's not all XX)

• Part numbers of chips on your motherboard you think are the sensor chips (look at your motherboard)

• Motherboard type

• Sensors version

• Kernel version

What to do if a module won't insert?

Did you use modprobe instead of insmod??? Don't use insmod.

Were there unresolved symbols? Did you run depmod -a? Run depmod -a -e to see where the symbol problem is.

ALWAYS inspect the output of dmesg. That's where the error messages come out!!! Don't rely on the generic message from modprobe. If you still can't figure it out, send us the information listed above.

What to do if it inserts, but nothing happens?

For an ISA sensor chip, did you also modprobe i2c-isa? It must be inserted.

For an I2C sensor chip, did you also modprobe i2c-xxx where xxx is your I2C bus adapter? It must be inserted.

Always inspect the output of dmesg. That's where the error messages come out. If you still can't figure it out, send us the information listed above.

What to do if I read only bogus information?

It may be that this was a mis-detection: the chip may not be present. If you are convinced there is something wrong, verify that you indeed have the devices on your motherboard that you think you do. Look at the motherboard and make sure. If you are still stuck, please send us the usual information (see Help)

What to do if you have other problems?

Again, send the output listed above.

What if it just works like a charm?

Drop us a mail if you feel like it, mentioning the mainboard and detected chip type. That way, we have some positive feedback, too!

Why did you decide not to support undocumented chips?

There are several reasons why we are generally not interested in writing drivers for undocumented chips:

• Writing a driver without a datasheet is much harder, as you have to guess most things. Remember that, most of the time, we write drivers for fun and for free, so there is no reason we would write a driver in conditions that promise more pain than fun.

• If we hit a problem, we are certain never to get any support from the chip manufacturer. This means that we may spend days on code which will finally never work.

• There are several chips out there which are fully documented and lack a driver. This is natural for us to give these the priority when we finally have some spare time to spend on driver coding.

• Hardware monitoring chips are not toys. Misprogramming them can result in data loss or hardware breakage. This is obviously more likely to happen with undocumented chips. This is a responsability we do not want to endorse (the GPL is pretty clear than we are not legally liable, but still).

There are also several reasons why we do not want to support such drivers, even if they were written by other people:

• Problems are much more likely to happen with such drivers. This means increased needs of support. User support if very time-consuming and we are usually short of time.

• Support should be done by the driver author (as only him/her knows the driver and chip) but in the reality of facts, people will always ask us for help if the driver is part of our package. Redirecting all user requests to the driver's author manually is boring.

• The lack of datasheet usually results in an original driver which works relatively fine for its author, but will happen not to work completely for other users. This means that the driver will need many more additions and fixes than other drivers do, resulting in an increased maitainance workload, which we can hardly afford. Of course this too should be handled by the original driver author, but we never know whether he/she will actually do the work.

Lastly, there are other considerations, some of which are deliberately political:

• We do not want to trick hardware buyers into thinking that a chip is fully supported under Linux when in fact it is only partly supported by a driver which was written without a datasheet. Clearly stating that such chips are not supported makes it much easier for anyone who really needs fully working hardware monitoring under Linux to avoid motherboards with these partly supported chips.

• Drivers written without a datasheet are a pain for developers and users, but are a complete win for the manufacturers of these chips: they don't have to write the driver, they don't have to help us, they don't have to support the users, and they still sell their hardware. We do not want to encourage such a selfish behavior.

That being said, authors of such drivers can still submit their code to the Linux kernel folks for inclusion into Linux 2.6. Their driver may be accepted there, under conditions.

If such a driver is ever accepted into the Linux 2.6 tree, and someone provides a patch to libsensors and/or sensors to add support for this driver, we will apply it. This generic code is unlikely to cause trouble.