FAQ/Chapter3

Go back to FAQ

Problems

  1. My fans report exactly half/double their values compared to the BIOS?
  2. Fans sometimes/always read 0!!
  3. I doubled the fan divisor and the fan still reads 7000!
  4. Why do my two LM75's report "-48 degrees"?
  5. Why do I have two Vcore readings, I have only one processor!
  6. How do those ALARMS work? The current value is within range but there is …
  7. My voltage readings seem to drift a bit. Is something wrong?
  8. Some measurements are way out of range. What happened?
  9. -5V and -12V readings are way out of range!
  10. What are VID lines? Why is the VID reading wrong?
  11. I read sensor values several times a second, but they are only updated …
  12. It sometimes seems to take almost a second before I see the sensor reading …
  13. Can I be alerted when an ALARM occurs?
  14. SMBus transactions on my PIIX4 simply don't work (timeouts happen). Why?
  15. My BIOS reports a much higher CPU temperature than your modules!
  16. I try to read the raw /proc files, but the values are strange?!?
  17. How do I set new limits?
  18. I set new limits and it didn't work?
  19. Some sensors are doubly detected?
  20. I ran sensors-detect, but now I get very strange readings?!?
  21. Bad readings from particular chips
    1. Bad readings from the AS99127F!
    2. Bad readings from the VIA 686A!
    3. Bad readings from the MTP008!
    4. Bad temperature readings from the SIS5595!
    5. Bad readings from a w8378[12]d!
    6. Bus hangs on Ali 1543 on Asus P5A boards!
    7. Bad readings from LM75!
    8. Bad readings from LM78!
    9. Bad readings from LM80!
  22. How do I configure two chips (LM87) differently?
  23. Dmesg says Upgrade BIOS! I don't want to!
  24. Dmesg says use force_addr=0xaddr! What address do I use?
  25. Sensors says Can't access procfs/sysfs file
  26. Sensors says No sensors found!
  27. Sensors output is not correct!
  28. What is at I2C address XXX?
    1. What is at I2C address 0x69?
    2. What is at I2C addresses 0x50 - 0x57?
    3. What is at I2C addresses 0x30 - 0x37?
  29. Sensors-detect doesn't work at all
    1. Sensors-detect says "Couldn't open /proc/bus/i2c?!?"
    2. Sensors-detect says "Can't open /dev/i2c[-/]0"
    3. Sensors-detect doesn't find any sensors!
  30. Sensors says Error: Line xxx: zzzzzzz
  31. Sensors only gives the name and adapter for my chip
  32. Sensors says ERROR: Can't get xxxxx data!
  33. Sensors doesn't find any sensors, just eeproms.
  34. Inserting modules hangs my board
  35. Inserting modules slows down my board
  36. Problems on particular motherboards
    1. Asus P4B
    2. Tyan 2460, 2462
    3. Tyan 2466
    4. Tyan 2688
    5. Asus server boards
  37. Problems on particular systems
  38. Problems on 2.6 kernels
  39. My sensors have stopped working in kernel 2.6.31
  40. My sensors have stopped working in kernel 3.3 / 3.2.2 / 3.0.18
  41. AMD K8 support in 2.6.33 and 2.6.34 kernels
  42. coretemp returns unrealistic values
  43. My sensors have stopped working in kernel 3.4
  44. How do I clear the chassis intrusion alarm?

My fans report exactly half/double their values compared to the BIOS?

The problem with much of the sensor data is that it is impossible to properly interpret some of the readings without knowing what the hardware configuration is. Some fans report one 'tick' each rotation, some report two 'ticks' each rotation. It is easy to resolve this through the configuration file /etc/sensors.conf:

chip "lm78-*"                # Or whatever chip this relates to

     compute fan1 2*@,@/2    # This will double the fan1 reading
                             # -- or --
     compute fan1 @/2,2*@    # This will halve the fan1 reading

See doc/fan-divisors in our package for further information.

Fans sometimes/always read 0!!

You may not have a three-wire fan, which is required.

You may need to increase the 'fan divisor'. See doc/fan-divisors in our package for further information.

I doubled the fan divisor and the fan still reads 7000!

Believe it or not, doubling the 'fan divisor' will not halve the fan reading. You have to add a compute line in /etc/sensors.conf. See My fans report exactly half/double their values compared to the BIOS, and see doc/fan-divisors in our package for further information.

Why do my two LM75's report "-48 degrees"?

For starters, those aren't LM75's. Your mainboard actually has the Winbond W83781D which emulates two LM75's, but many systems which use the Winbond chip (such as the Asus P2B) don't have the thermo-resisters connected to the chip resulting in these strange -48 degree readings.

In upcoming versions, you will be able to disable non-interesting readings.

Why do I have two Vcore readings, I have only one processor!

The LM78 has seven voltage sensors. The default way of connecting them is used in the configuration file. This includes a VCore2, even if you do not have one. You can easily edit the configuration file to give it another name, or make this reading disappear using an ignore line.

Note that Vcore2 is often the same as Vcore on motherboards which only support one processor. Another possibility is that Vcore2 is not connected at all and will not have a valid reading at all. A third possibility, is that Vcore2 monitors something else, so you should not be too surprised if the values are completely different.

How do those ALARMS work? The current value is within range but there is still an ALARM warning!

The ALARM indications in sensors are those reported by the sensor chip itself. They are NOT calculated by sensors. sensors simply reads the ALARM bits and reports them.

An ALARM will go off when a minimum or maximum limit is crossed. The ALARM is then latched - that is, it will stay there until the chip's registers are next accessed - which will be the next time you read these values, but not within (usually) 1.5 seconds since the last update.

Reading the registers clears the ALARMS, unless the current value is still out of range.

The purpose of this scheme is to tell you if there has been a problem and report it to the user. Voltage or temperature spikes get detected without having to read the sensor chip hundreds of times a second. The implemetation details depend a bit on the kind of chip. See the specific chip documentation in doc/chips/ and the chip datasheet for more information.

My voltage readings seem to drift a bit. Is something wrong?

No, probably not. If your motherboard heats up a bit, the sensed voltages will drift a bit. If your power supply is loaded (because a disk gets going, for example), the voltages may get a bit lower. Heavy processor activity, in particular, dramatically increases core voltage supply load which will often cause variation in the other supplies. As long as they stay within a sensible range (say 5% of the nominal value for CPU core voltages, and 10% for other voltages), there is no reason to worry.

Some measurements are way out of range. What happened?

Each module tries to set limits to sensible values on initialization, but a module does not know how a chip is actually connected. This is described in the configuration file, which is not read by kernel modules. So limits can be strange, if the chip is connected in a non-standard way.

Readings can also be strange; there are several reasons for this. Temperature sensors, for example, can simply not be present, even though the chip supports them. Also, it can be that the input is used in a non-standard way. You can use the configuration file to describe how this measurement should be interpreted; see the comments the example file for more information.

-5V and -12V readings are way out of range!

It's very frequent that negative voltage lines are not wired because motherboard manufacturers don't think they're worth monitoring (they are mostly unused these days). You can just add ignore inN lines to /etc/sensors.conf to hide them.

Another possibility is that these lines are used to monitor different voltages. Only the motherboard manufacturer can tell for sure. Taking a look at what voltage values the BIOS displays may provide valuable hints though.

What are VID lines? Why is the VID reading wrong?

These describe the core voltage for your processor. They are supported for most processors, however they are not always correctly connected to the sensor chip, so the readings may be invalid. A reading of 0V, +3.5V or +2.05V is especially suspect. If this is the case, add a line ignore vid to /etc/sensors.conf, and change the min and max settings for the Processor Core voltage (often in0_min and in0_max) in that file so that they don't depend on vid.

The CPU nominal voltage is computed from VID lines according to a formula that depends on the CPU type. Most chips that report a VID value can be configured to use either VRM 8.2 (for Pentium III) or VRM 9.0 (for Pentium 4 and Athlon). You chose which one you want through /etc/sensors.conf. See doc/vid for more information.

I read sensor values several times a second, but they are only updated only each second or so. Why?

If we would read the registers more often, it would not find the time to update them. So we only update our readings once each 1.5 seconds (the actual delay is chip-specific; for some chips, it may not be needed at all).

It sometimes seems to take almost a second before I see the sensor reading results. Why?

ISA bus access is fast, but SMBus access is really slow. If you have a lot of sensors, it just takes a lot of time to access them. Fortunately, this has almost no impact on the system as a whole, as another job can run while we are waiting for the transaction to finish.

Can I be alerted when an ALARM occurs?

No, you can't; and it may well be never supported.

Almost no mainboard we have encountered have actually connected the IRQ-out pin of sensor chips. That means that we could enable IRQ reporting, but nothing would happen. Also, even if a motherboard has it connected, it is unclear what interrupt number would be triggered. And IRQ lines are a scarce facility, which means that almost nobody would be able to use it anyway.

The SMI interrupt is only available on a few types of chips. It is really a very obscure way to handle interrupts, and supporting it under Linux might be quite hard to do.

Your best bet would be to poll the alarm file with a user-land daemon which alerts you if an alarm is raised. I am not aware of any program which does the job, though you might want to examine one of the graphical monitor programs under X, see wiki:UsefulLinks for addresses.

SMBus transactions on my PIIX4 simply don't work (timeouts happen). Why?

Some chips which mainboard makers connect to the SMBus are not SMBus devices. An example is the 91xx clock generator chips. When read, these devices can lock up the SMBus until the next hard reboot. This is because they have a similar serial interface (like the I2C), but don't conform to Intel's SMBus standard.

Why did they connect these devices to the SMBus if they aren't compatible? Good question! :') Actually, these devices may support being written to, but lock things up when they are read.

My BIOS reports a much higher CPU temperature than your modules!

We display the actual temperature of the sensor. This may not be the temperature you are interested in, though. If a sensor should measure the CPU temperature, it must be in thermal contact with it. In practice, it may be just somewhere nearby. Your BIOS may correct for this (by adding, for example, thirty degrees to the measured temperature). The correction factor is regrettably different for each mainboard, so we can not do this in the module itself. You can do it through the configuration file, though:

chip "lm75-*-49"                         # Or whatever chip this relates to

     label temp "Processor"
     compute temp @*1.2+13,(@-13)/1.2    # Or whatever formula

However, the offset you are introducing might not be necessary. If you tried to have Linux idle temperature and BIOS "idle" temperature match, you may be misguided. We have a Supermicro (370DLE) motherboard and we know that its BIOS has a closed, almost undelayed while(1) loop that keeps the CPU busy all the time. Linux reads 26 degrees idle, BIOS reads 38 degrees. Linux at full load is in the 35-40 degrees range so this makes sense.

I try to read the raw /proc files, but the values are strange?!?

Remember, these values do not take the configuration file compute lines in account. This is especially obvious for voltage readings (usually called in? or vin?). Use a program linked to libsensors (like the provided sensors program) instead.

How do I set new limits?

Change the limit values in /etc/sensors.conf and then run sensors -s.

I set new limits and it didn't work?

You forgot to run sensors -s. Put it in a /etc/rc.d/... file after the modprobe lines to run at startup.

Some sensors are doubly detected?

Yes, this is still a problem. It is partially solved by alias detection and confidence values in sensors-detect, but it is really tough.

Double detections can be caused by two things: sensors can be detected to both the ISA and the SMBus (and if you have loaded the approprate adapter drivers, it will be detected on both), and some chips simulate other chips (the Winbond W83781D simulates LM75 chips on the SMBus, for example). Remove the offending adapter or chip driver, or run sensors-detect and add the ignore= modprobe parameters it suggests.

I ran sensors-detect, but now I get very strange readings?!?

Your SMBus (PIIX4?) is probably crashed or hung. There are some mainboards which connect a clock chip to the SMBus. Unfortunately, this clock chip hangs the PIIX4 if it is read (it is an I2C device, but not SMBus compatible). We have found no way of solving this, except for rebooting your computer. Next time when you run sensors-detect, you may want to exclude addresses 0x69 and/or 0x6a, by entering s when you are asked whether you want to scan the PIIX4.

Bad readings from particular chips

See below for some particularly troublesome chips. Also be sure and check doc/chips/xxxx for the particular driver.

Bad readings from the AS99127F!

The Asus AS99127F is a modified version of the Winbond W83781D. Asus will not release a datasheet. The driver was developed by tedious experimentation. We've done the best we can. If you want to make adjustments to the readings please edit /etc/sensors.conf. Please don't ask us to fix the driver. Ask Asus to release a datasheet.

Bad readings from the VIA 686A!

The Via 686A datasheet is incomplete. Via will not release details. The driver was developed by tedious experimentation. We've done the best we can. If you want to make adjustments to the readings please edit /etc/sensors.conf. Please don't ask us to fix the driver. Ask Via to release a better datasheet. Also, don't forget to modprobe i2c-isa.

Bad readings from the MTP008!

The MTP008 has programmable temperature sensor types. If your sensor type does not match the default, you will have to change it. See doc/chips/mtp008 for details. Also, MTP008 chips seem to randomly refuse to respond, for unknown reasons. You can see this as 'XX' entries in i2cdump.

Bad temperature readings from the SIS5595!

This chip can use multiple thermistor types and there are also two different versions of the chip. We are trying to get the driver working better and develop formulas for different thermistors but we aren't there yet. Sorry. Also, many times the chip isn't really a sis5595 but it was misidentified. We are working on improving that too.

Bad readings from a w8378[12]d!

Do you own an ASUS motherboard? Perhaps your chip is being misidentified. Look on the motherboard for a 'Winbond' or Asus chip. Often the real device is an Asus as99127f. If so, the driver can be forced to recognize the as99127f with force_as99127f=BUS,0x2d where BUS is your i2c bus number. Cat /proc/bus/i2c to see a list of bus numbers. Read the w83781d module documentation (doc/chips/w83781d) for more details.

Bus hangs on Ali 1543 on Asus P5A boards!

The SMBus tends to hang on this board and it seems to get worse at higher temperatures. Use ISA accesses to reliably use the w83781d monitor chip on this board and use the ignore=1,0x2d or similar option to the w83781d module to prevent i2c accesses.

Bad readings from LM75!

The LM75 detection is poor and other hardware is often misdetected as an LM75. Figure out what you really have See What chips are on motherboard XYZ.

Bad readings from LM78!

The LM78 is no longer manufactured by National Semiconductor. You probably don't have a real LM78 but something similar that we do not recogize or support. Figure out what you really have See What chips are on motherboard XYZ.

Bad readings from LM80!

The LM80 detection is poor and other hardware is often misdetected as an LM80. Figure out what you really have See What chips are on motherboard XYZ.

How do I configure two chips (LM87) differently?

There is a SuperMicro? board with two LM87's on it that are not hooked up in the same way, so they need different defaults. For example, both CPU temperatures go to one LM87.

Make two different sections in /etc/sensors.conf as follows:

chip "lm87-i2c-*-2c"
         # put configuration for the chip at 0x2c here

chip "lm87-i2c-*-2d"
         # put configuration for the chip at 0x2d here

There is a commented example in sensors.conf.eg which should be helpful.

Dmesg says Upgrade BIOS! I don't want to!

If the problem is a PCI device is not present in lspci, the solution is complex. For the ALI M7101 device, there is a solution which uses the 2.4 kernel's hotplug facility. See prog/hotplug in our package. For other PCI devices, you can try to modify the m7101 solution in prog/hotplug.

If dmesg says try force_addr, see below. Other drivers generally do not support the force_addr parameter. Sorry. Check the documentation for your driver in doc/ and if we don't support it you can send us your request.

Dmesg says use force_addr=0xaddr! What address do I use?

If the problem is a PCI device whose base address is not set, you may be able to set the address with a force parameter. The via686a and sis5595 chip drivers, and some bus drivers, support the command line modprobe via686a force_addr=0xADDRESS where ADDRESS is the I/O address. You must select an address that is not in use. cat /proc/ioports to check (carefully) for conflicts. A high number like 0xf000 is generally safe.

Sensors says Can't access procfs/sysfs file

  • Linux 2.6
  • Did you modprobe i2c_sensor? Check lsmod.
  • Do you have sysfs support in your kernel and /sys mounted (is /sys there and populated)? Create /sys with mkdir /sys if needed. Then add the following line to /etc/fstab:
    sys              /sys             sysfs       default          0   0
    

and mount /sys.

  • Linux 2.4
  • Did you modprobe i2c-proc? Check lsmod.
  • Do you have procfs support in your kernel and /proc mounted (is /proc there and populated)? Create /proc with mkdir /proc if needed. Then add the following line to /etc/fstab:
    proc             /proc            proc        defaults         0   0
    

and mount /proc.

  • If you did sensors -s, did you run it as root?

Sensors says No sensors found!

  • Did sensors-detect find sensors? (If not see Sensors-detect doesnt find any sensors)
  • Did you do what sensors-detect said?
  • Did you modprobe your sensor modules?
  • Did you modprobe your I2C adapter modules?
  • Did you modprobe i2c-isa if you have ISA sensor chips?
  • Check lsmod.

Sensors output is not correct!

What specifically is the trouble?

  • Labels: See The labels for the voltage and temperature readings in sensors are incorrect.
  • Min/max readings: See The min and max for the readings in sensors are incorrect, and See The min and max settings didnt take effect.
  • AS99127F: See I ran sensors-detect but now I get very strange readings?.
  • Via 686A: See I ran sensors-detect but now I get very strange readings?.
  • Other specific chips: See I ran sensors-detect but now I get very strange readings?.
  • No output for a particular sensors chip: See What to do if it inserts but nothing happens.
  • No output at all: See Sensors says No sensors found, See What to do if it inserts but nothing happens.
  • Completely bad output for a particular sensor chip: See What to do if I read only bogus information.
  • One particular sensor readings:
  • Maybe it isn't hooked up? - tell 'sensors' to ignore it. See One sensor isnt hooked up on my board.
  • Maybe it is hooked up differently on your motherboard? - adjust sensors.conf calculation.

What is at I2C address XXX?

In general, we don't know. Start by running sensors-detect. If it doesn't recognize it, try running i2cdump. A partial list of manufacturers' IDs are at the bottom of doc/chips/SUMMARY.

What is at I2C address 0x69?

A clock chip. Often, accessing these clock chips in the wrong way will instantly crash your computer. Sensors-detect carefully avoids these chips, and you should do too. You have been warned.

What is at I2C addresses 0x50 - 0x57?

EEPROMs on your SDRAM DIMMs. Load the eeprom module to look at some basic data in sensors or use the program prog/eeprom/decode-dimms.pl to get more information than you ever wanted.

What is at I2C addresses 0x30 - 0x37?

These are often 'shadows' of your EEPROMs on your SDRAM DIMMs at addresses 0x50 - 0x57. They are the 'software write-protect' registers of the SDRAM Serial Presence Detect EEPROMs. If you try and do a i2cdump on them to read the location, you won't get anything, because they contain a single write-only register. This register can be used to permanently write-protect the contents of the eeprom.

Sensors-detect doesn't work at all

It could be many things. What was the problem? See Problems on particular motherboards.

Sensors-detect says "Couldn't open /proc/bus/i2c?!?"

You don't have i2c support in your kernel, or the i2c-core module was not loaded and you did not run sensors-detect as root.

Sensors-detect says "Can't open /dev/i2c[-/]0"

Your /dev/i2c-0, /dev/i2c0, or /dev/i2c/0 files do not exist or you did not run sensors-detect as root. Run the script prog/mkdev/mkdev.sh to create the /dev/i2c-x files. Run devfs in the kernel to get the /dev/i2c/x files.

Sensors-detect doesn't find any sensors!

Either

  1. The board doesn't have any sensors.
  1. We don't support the sensors on the board.
  1. The sensors it has are on an I2C bus connected to an I2C bus adapter that we don't support.
  1. You don't have the latest version of lm_sensors.

But in any case you should figure out what is on the board:

  1. Look at your motherboard.
  1. Check the manufacturer's website.

When you know what chips you have, check the Devices page to see if support has been added for your chip in a later release or in SVN.

Sensors says Error: Line xxx: zzzzzzz

These are errors from the libsensors library in reading the /etc/sensors.conf configuration file. Go to that line number and fix it. If you have a parse error, perhaps you have to put the feature name in double quotes.

Sensors only gives the name and adapter for my chip

If sensors only says this, for example, and doesn't provide any actual data at all:

it87-isa-0290
Adapter: ISA adapter

Your chip is not currently supported by sensors and so all it does is print out that information. Get the latest release and be sure you are running the sensors program it installed and not some older sensors.

Sensors says ERROR: Can't get xxxxx data!

  • (Linux 2.6) Make sure you are using one of the recommended kernel/lm_sensors combination.
  • You have a libsensors/sensors mismatch. sensors is unable to get a data entry from libsensors. You probably have an old libsensors in your /etc/ld.so.conf path. Make sure you did (as root) a make install (Linux 2.4) or make user_install (Linux 2.6) followed by a ldconfig. Then check the output of ldconfig -v | grep libsensors to verify that there is only ONE libsensors entry and that it matches the libsensors that was built in the lib/ directory in lm_sensors2.

Sensors doesn't find any sensors, just eeproms.

See Sensors-detect doesnt work at all, if sensors-detect failed to find any sensors.

If sensors-detect did find sensors, did you insert your modules? For chips on the ISA bus, did you insert i2c-isa?

See What to do if a module wont insert, if the modules didn't insert, also Sensors says No sensors found.

Inserting modules hangs my board

There are several possible causes:

  1. Bus driver problems. Insert the bus driver first, before you have inserted any chip drivers, to verify.
  1. Wrong chip driver. Verify that you have a chip supported by the chip driver, see What chips are on motherboard XYZ.
  1. The chip driver is reinitializing the chip, which undoes critical initialization done by the BIOS. Try the parameter init=0 for the w83781d driver; this is the only driver supporting this parameter.
  1. Some chips on the bus don't like to be probed at all. After inserting the bus driver (but not the chip drivers), run i2cdetect on the bus, then i2cdump on each address responding to i2cdetect. This may find the culprit. Do not i2cdump address 0x69, the clock chip.
  1. The chip driver is incorrectly finding a second chip on the bus and is accessing it. For example, with the Tyan 2688 with a w83781d at 0x29, use modprobe ignore_range=0,0x00,0x28,0,0x2a,0x7f to prevent access to other addresses. (init=0 also req'd for the Tyan 2688).

Inserting modules slows down my board

Generally this is caused by an overtemperature alarm output from the sensor chip. This triggers hardware on the board which automatically slows down the CPU clock. Be sure that your temperature limits are above the temperature reading. Put the new limits in /etc/sensors.conf and run sensors -s.

Problems on particular motherboards

The following boards have unique problems and solutions.

Asus P4B

See prog/hotplug/README.p4b if your SMBus master is not found. (fixme)

Tyan 2460, 2462

See support tickets 805, 765, 781, 812, 813, and 867 for information. (fixme)

Tyan 2466

See support tickets 941, 840, and 841 for information. (fixme)

Tyan 2688

For board hangs, see support ticket 721 for information. Also Inserting modules hangs my board. (fixme)

Asus server boards

BIOS update may be neccessary to access the W83792D chip.

Problems on particular systems

For IBM systems, see README.thinkpad.

Problems on 2.6 kernels

Not all drivers have been ported to 2.6. If your favorite driver is not in 2.6, the reason is that nobody has ported it, or the ported code did not get a proper review yet. If you would like to port the driver, see the file Documentation/i2c/porting-clients in the 2.6 kernel tree for help, then send us the ported driver when you are done.

4.33.1 i2c-viapro and via686a

Until kernel 2.6.11, there was a PCI resource conflict between i2c-viapro (the SMBus driver for VIA bridges) and via686a (the integrated sensors driver for VIA bridges). This caused the second loaded driver to silently fail working. So do not load both i2c-viapro and via686a together unless you have a recent kernel.

4.33.2 Where are my EEPROMs?

The 2.6.14-rc1 kernel introduced the hwmon class, which groups all hardware monitoring drivers in a logical way. The goal was to help libsensors grab the relevant sensors information in /sys. In particular:

  • libsensors will no more need to know about the underlying bus types (I2C/SMBus, ISA or other);
  • libsensors will no more list non-hardware monitoring chips.

This explains why EEPROMs are no more displayed by sensors: they are no hardware monitoring chips. The medium term plan is to drop eeprom support for all Linux 2.6 kernels, as it didn't fit well in the library code in the first place.

Note that you can still obtain information about your EEPROMs by using the dedicated perl scripts in prog/eeprom: ddcmon, decode-dimms.pl, decode-edid.pl and decode-vaio.pl.

My sensors have stopped working in kernel 2.6.31

in the mainline 2.6.31 kernel, there is a change which causes hardware monitoring to no longer work on some motherboards. If this is happening for your motherboard, then when the lm_sensors service is starting you are probably getting an error like this:

FATAL: Error inserting it87
(/lib/modules/2.6.29-15.fc11.x86_64/kernel/drivers/hwmon/it87.ko): Device or
resource busy

And if you look at the kernel messages (using the dmesg command in a terminal for example) you will probably see something like this:

ACPI: I/O resource it87 [0x295-0x296] conflicts with ACPI region IP__
[0x295-0x296]
ACPI: Device needs an ACPI driver

With previous kernels hwmon drivers used to drive IO ranges which were potentially used by the ACPI code in your BIOS (which is active not only during but also after boot), we now explicitly check for this and if the ACPI code claims the IO-ports used by the hwmon chip, we no longer allow the hwmon driver to load.

Banging IO-ports of a chip from 2 different drivers, the Linux hwmon driver and the ACPI code is a really bad idea and can cause all sort of issues (including things like changing CPU / RAM voltage or clock speed). So the old behaviour was a really bad idea.

So even though this change in behaviour makes some people unhappy as to old behaviour happened to work without problems in their case (by sheer luck really), this change is really for the best!

If you have an Asus motherboard, chances are good there is an ACPI interface to read your sensors, which is safe, and no more sensors.conf tweaking needed for conversion formulas! Make sure you have the asus_atk0110 driver enabled in your kernel configuration to use this. You will also need lm-sensors version 3.1.0 or later.

If you want to restore the old behaviour (which might be dangerous) add: "acpi_enforce_resources=lax" to the kernel cmdline when booting (or add it in grub.conf to make this permanent).

Notes:

1) This change actually first appeared in the mainline 2.6.30 kernel, but due to a bug in 2.6.30, it didn't take effect until 2.6.31, see:  http://bugzilla.kernel.org/show_bug.cgi?id=13967

2) Some distributions have made this change earlier (e.g. Fedora has this change since kernel 2.6.29)

My sensors have stopped working in kernel 3.3 / 3.2.2 / 3.0.18

This is the same problem as above. The ACPI resource check was accidentally dropped in kernel 2.6.39. It was reintroduced in kernel 3.3, and the fix was then backported to stable kernels 3.2.2 and 3.0.18.

AMD K8 support in 2.6.33 and 2.6.34 kernels

Support for some rev. G desktop models of AMD K8 processor (driver k8temp) is broken on kernels 2.6.33 and 2.6.34. Unfortunately these kernels won't see any further stable updates, so you have to fix the problem yourself. Affected processors are models 108, 124 and 193 in AM2 socket format. If you are building your own kernel, simply add  the missing fix. If not, you have to add the following to your libsensors configuration file as a workaround:

chip "k8temp-*"

    compute temp1 @+21, @-21
    compute temp2 @+21, @-21
    compute temp3 @+21, @-21
    compute temp4 @+21, @-21

Don't forget to remove this once you upgrade to kernel 2.6.35 or later!

coretemp returns unrealistic values

The temperature value returned by the coretemp driver isn't absolute. It's a thermal margin from the critical limit, and the greater the margin, the worse the accuracy. It isn't really returning degrees Celsius. At high temperatures, the (small) thermal margin is almost expressed in degrees Celsius, but at low temperature, the (high) thermal margin is no longer expressed in actual degrees Celsius.

So, if the temperature value reported by coretemp is unrealistically low, all it means is that you are far away from the critical limit so your systems are running totally fine and cool and you don't have to worry at all. Unfortunately, there is no way to improve the readings, this is a hardware limitation.

Additionally, the critical limit value may be wrong on come CPU models. We may be able to address this problem over time, but again it's not really a problem in the first place. All that really matters is how far the measurement is from that limit. If the difference is above 40 pseudo degrees Celsius (again these are not real degrees Celsius!) then you're safe.

My sensors have stopped working in kernel 3.4

A change in the sysfs implementation in kernel 3.4 breaks the way libsensors used to detect whether sysfs is mounted or not. This is fixed in lm-sensors 3.3.2. For older versions you must backport r6017.

How do I clear the chassis intrusion alarm?

You could add a set statement in your configuration file, for example:

chip "w83795adg-*"

   set intrusion0_alarm 0

But that would unconditionally reset the alarm whenever "sensors -s" is run, which may not be desirable. If you only want to clear the alarm once, the easiest way is to write to the sysfs attribute directly. Assuming you have a single intrusion detection switch in the system, the following should do:

$ echo 0 > /sys/class/hwmon/hwmon*/device/intrusion0_alarm

In the future, we may add an option to sensors or write a separate tool to let the users deal with intrusion alarms in a more friendly way.