diff --git a/CHANGES b/CHANGES index c41543aa..45bc46ec 100644 --- a/CHANGES +++ b/CHANGES @@ -2,6 +2,7 @@ lm-sensors CHANGES file ----------------------- SVN-HEAD + documentation: Delete the FAQ, now maintained on the wiki libsensors: Use __func__ instead of __FUNCTION__ Parse the configuration file in C locale Late compute statements override early ones diff --git a/README b/README index e5a2dc78..e58aae50 100644 --- a/README +++ b/README @@ -92,8 +92,8 @@ The developers of this package can be reached through a mailing-list (see http://www.lm-sensors.org/wiki/AuthorsAndContributors). Do not hesitate to mail us if you have questions, suggestions, problems, want to contribute, or just want to report it works for you. But please try to -read the documentation and FAQ before you ask any questions! It's all -under doc/. +read the documentation before you ask any questions! It's all under doc/. +Also make sure you read the FAQ at http://www.lm-sensors.org/wiki/FAQ. The latest version of this package can always be found at: http://www.lm-sensors.org/wiki/Download. Pre-release versions can be diff --git a/doc/FAQ b/doc/FAQ deleted file mode 100644 index 1b98231d..00000000 --- a/doc/FAQ +++ /dev/null @@ -1,1577 +0,0 @@ -Short Contents -************** - -lm_sensors -1 PC and Sensor Overview -2 Sensor and Bus Basics -3 Installation and Management -4 Problems -5 How to Ask for Help -6 How to Contribute -Appendix A Revision History of This Document - - -Table of Contents -***************** - -lm_sensors -1 PC and Sensor Overview - 1.1 What sensors are available on my PC? - 1.2 What can a sensor chip like the "LM78" do? - 1.3 Where do I find out more about any of these chips? -2 Sensor and Bus Basics - 2.1 How are these sensors read? - 2.2 What is the SMBus? And the I2C bus? - 2.3 I don't have an ISA bus! - 2.4 What sensors do processors have? - 2.5 How often are the sensor values updated? - 2.6 How are alarms triggered? -3 Installation and Management - 3.1 Why so many modules, and how do I cope with them? - 3.2 How do I know which chips I own? - 3.2.1 What chips are on motherboard XYZ? - 3.2.2 Do you support motherboard XYZ? - 3.2.3 Do you support chip XYZ? - 3.2.4 Anybody working on a driver for chip XYZ? - 3.3 Which modules should I insert? - 3.4 Do I need the configuration file `/etc/sensors.conf'? - 3.4.1 The labels for the voltage and temperature readings in `sensors' are incorrect! - 3.4.2 The min and max for the readings in `sensors' are incorrect! - 3.4.3 The min and max settings in `/etc/sensors.conf' didn't take effect! - 3.4.4 One sensor isn't hooked up on my board! - 3.4.5 I need help with `sensors.conf'! - 3.4.6 Do you have a database of `sensors.conf' entries for specific boards? - 3.5 What about the `No such file or directory' warnings when I compile? - 3.6 I get all kinds of weird compilation errors? - 3.6.1 `No rule to make target xxxx needed by xxxx' - how to fix? - 3.7 It still does not compile or patch! - 3.8 `make install' fails on Mandrake kernels - 3.9 I get unresolved symbols when I `modprobe' modules (Red Hat especially) - 3.10 I2C_DRIVERID_ADM1024 undefined (Red Hat especially) -4 Problems - 4.1 My fans report exactly half/double their values compared to the BIOS? - 4.1.1 Fans sometimes/always read 0!! - 4.1.2 I doubled the fan divisor and the fan still reads 7000! - 4.2 Why do my two LM75's report "-48 degrees"? - 4.3 Why do I have two Vcore readings, I have only one processor! - 4.4 How do those ALARMS work? The current value is within range but there is still an ALARM warning! - 4.5 My voltage readings seem to drift a bit. Is something wrong? - 4.6 Some measurements are way out of range. What happened? - 4.6.1 -5V and -12V readings are way out of range! - 4.7 What are VID lines? Why is the VID reading wrong? - 4.8 I read sensor values several times a second, but they are only updated only each second or so. Why? - 4.9 It sometimes seems to take almost a second before I see the sensor reading results. Why? - 4.10 Can I be alerted when an ALARM occurs? - 4.11 SMBus transactions on my PIIX4 simply don't work (timeouts happen). Why? - 4.12 My BIOS reports a much higher CPU temperature than your modules! - 4.13 I try to read the raw `/proc' files, but the values are strange?!? - 4.14 How do I set new limits? - 4.14.1 I set new limits and it didn't work? - 4.15 Some sensors are doubly detected? - 4.16 I ran sensors-detect, but now I get very strange readings?!? - 4.17 Bad readings from particular chips - 4.17.1 Bad readings from the AS99127F! - 4.17.2 Bad readings from the VIA 686A! - 4.17.3 Bad readings from the MTP008! - 4.17.4 Bad temperature readings from the SIS5595! - 4.17.5 Bad readings from a w8378[12]d! - 4.17.6 Bus hangs on Ali 1543 on Asus P5A boards! - 4.17.7 Bad readings from LM75! - 4.17.8 Bad readings from LM78! - 4.17.9 Bad readings from LM80! - 4.18 How do I configure two chips (LM87) differently? - 4.19 Dmesg says `Upgrade BIOS'! I don't want to! - 4.19.1 Dmesg says `use force_addr=0xaddr'! What address do I use? - 4.20 Sensors says `Can't access procfs/sysfs file' - 4.21 Sensors says `No sensors found!' - 4.22 Sensors output is not correct! - 4.23 What is at I2C address XXX? - 4.23.1 What is at I2C address 0x69? - 4.23.2 What is at I2C addresses 0x50 - 0x57? - 4.23.3 What is at I2C addresses 0x30 - 0x37? - 4.24 Sensors-detect doesn't work at all - 4.24.1 Sensors-detect says "Couldn't open /proc/bus/i2c?!?" - 4.24.2 Sensors-detect says "Can't open /dev/i2c[-/]0" - 4.24.3 Sensors-detect doesn't find any sensors! - 4.25 Sensors says `Error: Line xxx: zzzzzzz' - 4.26 Sensors only gives the name and adapter for my chip - 4.27 Sensors says `ERROR: Can't get xxxxx data!' - 4.28 Sensors doesn't find any sensors, just eeproms. - 4.29 Inserting modules hangs my board - 4.30 Inserting modules slows down my board - 4.31 Problems on particular motherboards - 4.31.1 Asus P4B - 4.31.2 Tyan 2460, 2462 - 4.31.3 Tyan 2466 - 4.31.4 Tyan 2688 - 4.32 Problems on 2.6 kernels - 4.32.1 i2c-viapro and via686a - 4.32.2 Where are my EEPROMs? -5 How to Ask for Help - 5.1 What to send us when asking for help - 5.2 What to do if a module won't insert? - 5.3 What to do if it inserts, but nothing happens? - 5.4 What to do if I read only bogus information? - 5.5 What to do if you have other problems? - 5.6 What if it just works like a charm? - 5.7 How do I update a ticket? - 5.8 How do I follow up on a ticket? - 5.9 Why did you decide not to support undocumented chips? -6 How to Contribute - 6.1 How to write a driver - 6.2 How to get SVN access - 6.3 How to donate hardware to the project - 6.4 How to join the project mailing lists - 6.5 How to access mailing list archives - 6.6 How to submit a patch - 6.7 How to REALLY help - 6.8 How to get release announcements -Appendix A Revision History of This Document - - -lm_sensors -********** - -The lm_sensors package includes a collection of modules for general -SMBus access and hardware monitoring. NOTE: this requires special -support which is not in standard 2.2-vintage kernels. - -1 PC and Sensor Overview -************************ - -1.1 What sensors are available on my PC? -======================================== - -Most PC's built since late 1997 now come with a hardware health -monitoring chip. This chip may be accessed via the ISA bus or the -SMBus, depending on the motherboard. - - Some motherboard chipsets, notably the Via 686 and the SiS 5595, -contain hardware monitor functions. - - This FAQ frequently refers to the "LM78". This chip has been -obsoleted by National Semiconductor. Most motherboards today contain a -chip with similar functions. - -1.2 What can a sensor chip like the "LM78" do? -============================================== - -The LM78 is a chip made by National Semiconductor which can monitor 7 -voltages (5 positive, 2 negative) from 0 to 4.08V. The inputs are -usually in series with voltage dividers which lower the +/- 12V and +/- -5V supplies to measurable range. Therefore, the readings for such -inputs need to be re-scaled appropriately by software. - - The LM78 also has 3 fan speed monitoring inputs, an internal -temperature sensor, a chassis intrusion sensor, and a couple maskable -interrupt inputs. The LM78 can also relay the processor's (P6 or Pent -II) VID lines which are hardwired and used to indicate to the power -regulator (usually on the mainboard close to the processor socket/slot) -what voltage to supply to the processor. - - The LM78 can be interfaced to a system via the ISA bus and/or the -SMBus. - - Most other sensor chips have comparable functionality. Each supported -chip is documented in the `doc/chips' directory. - -1.3 Where do I find out more about any of these chips? -====================================================== - -Most semiconductor companies have comprehensive documentation, -including complete datasheets, on their websites. Analog Devices, -Dallas Semiconductor, Maxim, and National Semiconductor have the widest -selection of sensor chips. Their websites are: - - * `http://www.analog.com' - - * `http://www.dalsemi.com' - - * `http://www.maxim-ic.com' - - * `http://www.national.com' - - Please see the file `http://www.lm-sensors.org/wiki/UsefulLinks' for -links to other companies' websites. - -2 Sensor and Bus Basics -*********************** - -2.1 How are these sensors read? -=============================== - -Sensor chips reside on either the ISA bus, the SMBus, or both. See the -file `doc/chips/SUMMARY' in our package for a list. - - To communicate with chips on the ISA bus, the software uses simple -I/O reads and writes. - - To communicate with chips on the SMBus, the software must use an -SMBus interface device, explained below. - -2.2 What is the SMBus? And the I2C bus? -======================================= - -The SMBus is the "System Management Bus". More specifically, it is a -2-wire, low-speed serial communication bus used for basic health -monitoring and hardware management. It is a specific implementation of -the more general I2C (pronunciation: I-squared-C) bus. In fact, both -I2C devices and SMBus devices may be connected to the same (I2C) bus. - - The SMBus (or I2C bus) starts at the host controller, used for -starting transactions on the SMBus. From the host interface, the -devices communicated with are the "slave" devices. Each slave device -has a unique 7-bit address which the host uses to refer to that device. - - For each supported SMBus host, there is a separate kernel module -which implements the communication protocol with the host. Some SMBus -hosts really operate on the SMBus level; these hosts can not cope with -pure I2C devices. Other hosts are in fact I2C hosts: in this case, we -implement the SMBus protocol in terms of I2C operations. But these -hosts can also talk to pure I2C devices. - -2.3 I don't have an ISA bus! -============================ - -We promise, you do, even if you don't have any old ISA slots. The "ISA -Bus" exists in your computer even if you don't have ISA slots; it is -simply a memory-mapped area, 64KB in size (0x0000 - 0xFFFF) where many -"legacy" functions, such as keyboard and interrupt controllers, are -found. It isn't necessarily a separate physical bus. See the file -`/proc/ioports' for a list of devices living on the "ISA Bus" in your -system. If you don't like the term "ISA Bus" think "I/O Space". - -2.4 What sensors do processors have? -==================================== - -Most new processors contain a thermal diode on the die itself. The -electical properties of all diodes and transistors vary slightly with -temperature. The thermal diode is exceptionally accurate because it is -directly on the die. Newer temperature sensor chips, like the Analog -Devices ADM1021 and clones, and the Winbond chips, have circuitry for -measuring the the electrical properties of an external diode and -converting this data to a temperature. Any sensor chip listed in -`doc/chips/SUMMARY' in our package which has support for more than one -temperature supports external temperature sensing. - - Older motherboards and processors without this feature generally use -an LM75 placed close to the processor. This is much less accurate. - - The Pentium 2 'boxed' processor usually has an LM75 very close to the -base of the box. It can be read through the SMBus to report the -approximate temperature of the processor. The processor also contains -an internal temperature sensor (of low accuracy) used as a fail-safe to -disable the processor in case it gets much too hot (usually around 130 -degrees C). And, the Pentium 2 also has a hard-wired signal (VID -lines) on it's SEC (single edge connector) which indicates what power -supply is required to operate the processor. - - The P6 (Pentium-Pro) may have an LM75 in or just under the socket. -P6's also have VID lines. - - Pentiums and Pentium w/ MMX do not have VID lines, and sometimes have -LM75's under the sockets (depends on the mainboard, and how 'modern' the -mainboard is). - - The P2 Xeon was the first Intel processor to include the SMBus -interface on the P2 Xeon SEC. - -2.5 How often are the sensor values updated? -============================================ - -The LM78, and most other sensor chips like it, reads its sensors one by -one. A complete scanning sweep will take about 1.5 seconds. The LM78 -stops readings sensors if you try to access it, so if you access it -very often (by reading sensor values; writing new limits is safe) it -will not find the time to update its sensor values at all! Fortunately, -the kernel module takes care not to do this, and only reads new values -each 1.5 seconds. If you read the values again, you will get the 'old' -values again. - -2.6 How are alarms triggered? -============================= - -It is possible to monitor each sensor and have an alarm go off if it -crosses some pre-determined limits. There are two sorts of interrupts -which can be generated by sensor chips if this happens (it depends a -bit on the actual chip if both are supported; the LM80, for example, -has only IRQ interrupts): IRQ interrupts and SMI interrupts. IRQ -stands for Interrupt Request and are the interrupt lines you can find -in `/proc/interrupts'. SMI stands for System Management Interrupt, and -is a special interrupt which puts the processor in a secure environment -independent of any other things running. SMI is currently not -supported by the Linux kernel. IRQs are supported, of course. - - Even if no interrupt is generated, some bits in a status register -will be set until the register is read the next time. If the alarm -condition persists after that, the bits will be set on the next -scanning sweep, etc. - - Most drivers in our package do not support interrupts at this time. - -3 Installation and Management -***************************** - -3.1 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'. - -3.2 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 *note Help::) - -3.2.1 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: - 2. Look at your motherboard. - - 3. Check the manufacturer's website or ask their support - - 4. Check the "links" (http://www.lm-sensors.org/wiki/UsefulLinks) - page on our website (http://www.lm-sensors.org) some good - cross-references. - -3.2.2 Do you support motherboard XYZ? -------------------------------------- - -We don't support boards, we support chips. *Note What chips are on -motherboard XYZ: Section 3.2.1. - -3.2.3 Do you support chip XYZ? ------------------------------- - -This we have good answers for. - * Sorted by Manufacturer: `README' - - * Sorted by Manufacturer: `http://www.lm-sensors.org/wiki/Devices' - - * Sorted by Sensor Driver: `doc/chips/SUMMARY' - -3.2.4 Anybody working on a driver for chip XYZ? ------------------------------------------------ - -Newest Driver Status: `http://www.lm-sensors.org/wiki/Devices' - -3.3 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' - -3.4 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. - -3.4.1 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. - -3.4.2 The min and max for the readings in `sensors' are incorrect! ------------------------------------------------------------------- - -You can customize them in the file `/etc/sensors.conf'. See above. - -3.4.3 The min and max settings in `/etc/sensors.conf' didn't take effect! -------------------------------------------------------------------------- - -You forgot to run `sensors -s'. See above. - -3.4.4 One sensor isn't hooked up on my board! ---------------------------------------------- - -Use an `ignore' line in `/etc/sensors.conf' so it isn't displayed in -`sensors'. - -3.4.5 I need help with `sensors.conf'! --------------------------------------- - -There is detailed help at the top of that file. - -3.4.6 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. - -3.5 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. - -3.6 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. - -3.6.1 `No rule to make target xxxx needed by xxxx' - how to fix? ----------------------------------------------------------------- - - * *Note I get all kinds of weird compilation errors: Section 3.6, - 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'. - -3.7 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! - -3.8 `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. - -3.9 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. - -3.10 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' - - 2. Look for `kernel-i2c,' or a similar rpm in the output - - 3. `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. - - 4. Try (in the build directory of `lm_sensors)' - `make clean' - `make' - - 5. _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. - -4 Problems -********** - -4.1 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. - -4.1.1 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. - -4.1.2 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'. *Note -My fans report exactly half/double their values compared to the BIOS: -Section 4.1, and see `doc/fan-divisors' in our package for further -information. - -4.2 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. - -4.3 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. - -4.4 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. - -4.5 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. - -4.6 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. - -4.6.1 -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. - -4.7 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. Since Linux 2.6.9, the right -formula is selected automatically. See `doc/vid' for more information. - -4.8 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). - -4.9 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. - -4.10 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 -`http://www.lm-sensors.org/wiki/UsefulLinks' for addresses. - -4.11 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. - -4.12 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. - -4.13 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. - -4.14 How do I set new limits? -============================= - -Change the limit values in `/etc/sensors.conf' and then run `sensors --s'. - -4.14.1 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. - -4.15 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. - -4.16 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. - -4.17 Bad readings from particular chips -======================================= - -See below for some particularly troublesome chips. Also be sure and -check `doc/chips/xxxxx' for the particular driver. - -4.17.1 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. - -4.17.2 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'. - -4.17.3 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. - -4.17.4 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. - -4.17.5 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. - -4.17.6 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. - -4.17.7 Bad readings from LM75! ------------------------------- - -The LM75 detection is poor and other hardware is often misdetected as -an LM75. Figure out what you really have *Note What chips are on -motherboard XYZ: Section 3.2.1. - -4.17.8 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 *Note What chips -are on motherboard XYZ: Section 3.2.1. - -4.17.9 Bad readings from LM80! ------------------------------- - -The LM80 detection is poor and other hardware is often misdetected as -an LM80. Figure out what you really have *Note What chips are on -motherboard XYZ: Section 3.2.1. - -4.18 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. - -4.19 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/[chips,busses]' and if we don't support it you -can send us your request. - -4.19.1 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. - -4.20 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? - -4.21 Sensors says `No sensors found!' -===================================== - - * Did `sensors-detect' find sensors? (If not *note 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'. - -4.22 Sensors output is not correct! -=================================== - -What specifically is the trouble? - * Labels: *Note The labels for the voltage and temperature readings - in sensors are incorrect: Section 3.4.1. - - * Min/max readings: *Note The min and max for the readings in - sensors are incorrect: Section 3.4.2, and *Note The min and max - settings didnt take effect: Section 3.4.3. - - * AS99127F: *Note I ran sensors-detect but now I get very strange - readings?: Section 4.16. - - * Via 686A: *Note I ran sensors-detect but now I get very strange - readings?: Section 4.16. - - * Other specific chips: *Note I ran sensors-detect but now I get - very strange readings?: Section 4.16. - - * No output for a particular sensors chip: *Note What to do if it - inserts but nothing happens: Section 5.3. - - * No output at all: *Note Sensors says No sensors found: Section - 4.21, *Note What to do if it inserts but nothing happens: Section - 5.3. - - * Completely bad output for a particular sensor chip: *Note What to - do if I read only bogus information: Section 5.4. - - * One particular sensor readings: - * Maybe it isn't hooked up? - tell 'sensors' to ignore it. - *Note One sensor isnt hooked up on my board: Section 3.4.4. - - * Maybe it is hooked up differently on your motherboard? - - adjust `sensors.conf' calculation. - -4.23 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'. - -4.23.1 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. - -4.23.2 What is at I2C addresses 0x50 - 0x57? --------------------------------------------- - -EEPROMs on your SDRAM DIMMs. Load the eeprom module and use the script -`decode-dimms.pl' (in the i2c-tools package) to get more information -than you ever wanted. - -4.23.3 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. - -4.24 Sensors-detect doesn't work at all -======================================= - -It could be many things. What was the problem? *Note Problems on -particular motherboards: Section 4.31. - -4.24.1 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. - -4.24.2 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. Use `MAKEDEV' or `mknod' to -create the `/dev/i2c-x' files. Run `devfs' in the kernel to get the -`/dev/i2c/x' files. - -4.24.3 Sensors-detect doesn't find any sensors! ------------------------------------------------ - -Either - 1. The board doesn't have any sensors. - - 2. We don't support the sensors on the board. - - 3. The sensors it has are on an I2C bus connected to an I2C bus - adapter that we don't support. - - 4. 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. - - 2. Check the manufacturer's website. - - When you know what chips you have, check the Driver Status -(http://www.lm-sensors.org/wiki/Devices) web page to see if support has -been added for your chip in a later release or in SVN. - -4.25 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. - -4.26 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'. - -4.27 Sensors says `ERROR: Can't get xxxxx data!' -================================================ - - * (Linux 2.6) Make sure you are using one of the recommended - kernel/lm_sensors combination - (http://www.lm-sensors.org/wiki/Kernel2.6). - - * 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'. - -4.28 Sensors doesn't find any sensors, just eeproms. -==================================================== - -*Note Sensors-detect doesnt work at all: Section 4.24, 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? - - *Note What to do if a module wont insert: Section 5.2, if the -modules didn't insert, also *Note Sensors says No sensors found: -Section 4.21. - -4.29 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. - - 2. Wrong chip driver. Verify that you have a chip supported by the - chip driver, see *Note What chips are on motherboard XYZ: Section - 3.2.1. - - 3. 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. - - 4. 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. - - 5. 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). - -4.30 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'. - -4.31 Problems on particular motherboards -======================================== - -The following boards have unique problems and solutions. - -4.31.1 Asus P4B ---------------- - -See `prog/hotplug/README.p4b' if your SMBus master is not found. - -4.31.2 Tyan 2460, 2462 ----------------------- - -See support tickets 805, 765, 781, 812, 813, and 867 for information. - -4.31.3 Tyan 2466 ----------------- - -See support tickets 941, 840, and 841 for information. - -4.31.4 Tyan 2688 ----------------- - -For board hangs, see support ticket 721 for information. Also *Note -Inserting modules hangs my board: Section 4.29. - -4.32 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.32.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.32.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 the i2c-tools package: `ddcmon', -`decode-dimms.pl', `decode-edid.pl' and `decode-vaio.pl'. - -5 How to Ask for Help -********************* - -5.1 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 -(http://lists.lm-sensors.org/mailman/listinfo/lm-sensors), 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 `http://www.lm-sensors.org/wiki/FeedbackAndSupport'. 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 - -5.2 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. - -5.3 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. - -5.4 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 (*note Help::) - -5.5 What to do if you have other problems? -========================================== - -Again, send the output listed above. - -5.6 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! - -5.7 How do I update a ticket? -============================= - -You can't. Only developers can. Follow up by emailing us and reference -your ticket number in the subject. Please don't enter a new ticket with -follow-up information, email us instead. Thanks. - -5.8 How do I follow up on a ticket? -=================================== - -Follow up by emailing us and reference your ticket number in the -subject. - -5.9 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. - -6 How to Contribute -******************* - -6.1 How to write a driver -========================= - -See `doc/developers/new_drivers' in our package for instructions. - -6.2 How to get SVN access -========================= - -For anonymous SVN read access, see the instructions on our download -page (http://www.lm-sensors.org/wiki/Download). - - For write access, please contact us. - -6.3 How to donate hardware to the project -========================================= - -Contact us (http://www.lm-sensors.org/wiki/FeedbackAndSupport). - -6.4 How to join the project mailing lists -========================================= - -There are two lists you can subscribe to: - - * A general discussion list - (http://lists.lm-sensors.org/mailman/listinfo/lm-sensors), meant - for both development and user support. You do not need to be - subscribed to post. - - * A CVS commits list - (http://lists.lm-sensors.org/mailman/listinfo/lm-sensors-commit), - for watching the changes made to the CVS repositories. This list - is read-only. - -6.5 How to access mailing list archives -======================================= - -The primary mailing list archive is at: -`http://lists.lm-sensors.org/pipermail/lm-sensors/'. It contains -messages since October 28, 2001. - - There is another mailing list archive at: -`http://news.gmane.org/gmane.linux.drivers.sensors'. It contains -messages since December 31, 2004. This archive may also be accessed -via a news reader: `nntp://news.gmane.org/gmane.linux.drivers.sensors' -and RSS: `http://rss.gmane.org/gmane.linux.drivers.sensors'. - - And last there is a legacy archive at: -`http://archives.andrew.net.au/lm-sensors'. It contains messages from -October 28, 2001 through May 16, 2005. - -6.6 How to submit a patch -========================= - -Check out the latest from CVS, then copy the directory to another -directory, and make your changes. Generate the diff with `diff -u2 -r -DIR1 DIR2'. Or you can generate the diff in CVS with `cvs diff -u2'. -Send us the patch in an email and tell us what it does. - -6.7 How to REALLY help -====================== - -Believe it or not, what we really need help with are: - * Answering email - - * Answering support tickets - - * Porting drivers to Linux 2.6 - - * Creating a sensors.conf database - - * Reviewing patches - - If you are willing to help, simply join our discussion list -(http://lists.lm-sensors.org/mailman/listinfo/lm-sensors), and we'll -help you help us. - -6.8 How to get release announcements -==================================== - -We don't have a separate release announcement mailing list; however, we -put all our releases on freshmeat: `http://freshmeat.net' and you can -register on our freshmeat project page -`http://freshmeat.net/projects/lm_sensors' to 'subscribe to new -releases' and then freshmeat will email you announcement. - -Appendix A Revision History of This Document -******************************************** - - * Rev 2.18 (JD) Removed version 1 specifics part, 2005-12-17 - - * Rev 2.17 (JD) Added 5.9 (why we don't support undocumented chips), - removed 6.9 (doesn't apply to the new mailing list), 2005-10-05 - - * Rev 2.16 (JD) Added 4.33.2, 2005-09-06 - - * Rev 2.15 (JD) Updates, including mailing-list change, 2005-05-21 - - * Rev 2.14 (MDS) Updated 4.12, 2004-11-26 - - * Rev 2.13 (JD) Added 4.6.1, updated 4.7, 2004-06-23 - - * Rev 2.12 (JD) Updated 4.27, 2004-04-11 - - * Rev 2.11 (JD) Various updates, 2004-01-18 - - * Rev 2.10 (MDS) Various updates, 2004-01-03 - - * Rev 2.9 (CP) Converted to Gnu texinfo format, 2002-09-10 - - * Rev 2.8 (MDS) Minor updates 2002-07-10, released with lm_sensors - 2.6.4 - - * Rev 2.7 (MDS) Minor updates 2002-04-25 - - * Rev 2.6 (MDS) Minor updates 2002-01-15, released with lm_sensors - 2.6.3 - - * Rev 2.5 (MDS) Minor updates 2001-11-11, released with lm_sensors - 2.6.2 - - * Rev 2.4 (MDS) Minor updates 2001-07-22 - - * Rev 2.3 (MDS) General update, 2001-02-24, released with lm_sensors - 2.6.0. - - * Rev 2.2 (Frodo) Corrections for lm_sensors 2.4, 1999-09-20 - - * Rev 2.1 (Frodo) Corrections for lm_sensors 2.2, 1999-01-12 - - * Rev 2.0 (Frodo) Major revision for lm_sensors 2.1, 1998-12-29 - - * Rev 1.10 (Frodo) Modified 3.8, updated some other things, - 1998-09-24 - - * Rev 1.9 (Frodo) Added 3.15, 1998-09-06 - - * Rev 1.8 (Frodo) Added 3.14, 1998-09-05 - - * Rev 1.7 (Phil) Added 3.13 and some other minor changes, 1998-09-01 - - * Rev 1.6 (Frodo) Added 4, 4.1, 4.2, 4.3, 4.4, 4.5, 1998-09-01 - - * Rev 1.5 (Frodo) Added 2.3, 2.4, 3.9, 3.10, 3.11, 1998-08-26 - - * Rev 1.4 (Frodo) Added some more Winbond information, and 3.5-3.8, - 1998-08-17 - - * Rev 1.3 (Phil) Added info on the Winbond chip, 1998-08-16 - - * Rev 1.2 (Frodo) Adapation, 1998-08-10 - - * Rev 1.1 (Phil) Modifications, 1998-08-09 - - * Rev 1.0 (Phil) First version, 1998-08-03 - diff --git a/doc/Makefile b/doc/Makefile deleted file mode 100644 index 5cf507ed..00000000 --- a/doc/Makefile +++ /dev/null @@ -1,19 +0,0 @@ -# -# quick makefile for the FAQ. -# So that both the text and html FAQ are accessible on the web -# (the website points into CVS for the FAQ), -# they are checked into CVS along with the .texi source. -# Don't forget to update version.texi. -# Run 'make' and then check in all 4 files after editing the .texi source. -# Or do 'make ci' -# -all:: lm_sensors-FAQ.html FAQ - -%.html: %.texi version.texi - makeinfo --html --no-split --number-sections $< - -FAQ: lm_sensors-FAQ.texi - makeinfo --no-headers --number-sections -o FAQ $< - -ci: all - cvs ci lm_sensors-FAQ.texi lm_sensors-FAQ.html FAQ version.texi diff --git a/doc/lm_sensors-FAQ.html b/doc/lm_sensors-FAQ.html deleted file mode 100644 index 3ce911ad..00000000 --- a/doc/lm_sensors-FAQ.html +++ /dev/null @@ -1,2351 +0,0 @@ - - -Sensors FAQ for lm_sensors version 2.18 - - - - - - - - - -

Sensors FAQ for lm_sensors version 2.18

-Copyright (C) 1998 - 2005
-Frodo Looijaard,
-Philip Edelbrock,
-Mark D. Studebaker
-and
-Jean Delvare
- -
-

Short Contents

- -
- -
-

Table of Contents

- -
- -
-

- -Next: , -Up: (dir) - -
- -

lm_sensors

- -

The lm_sensors package includes a collection of modules for general SMBus -access and hardware monitoring. NOTE: this requires special support which -is not in standard 2.2-vintage kernels. - -

- -
-

- -Next: , -Previous: Top, -Up: Top - -
- -

1 PC and Sensor Overview

- - - -
-

- - -Next: , -Up: Overview - -
- -

1.1 What sensors are available on my PC?

- -

Most PC's built since late 1997 now come with a -hardware health monitoring chip. This chip may be accessed via the -ISA bus or the SMBus, depending on the motherboard. - -

Some motherboard chipsets, notably the Via 686 and the SiS 5595, -contain hardware monitor functions. - -

This FAQ frequently refers to the "LM78". This chip has been -obsoleted by National Semiconductor. Most motherboards today contain -a chip with similar functions. - -

-

- - -Next: , -Previous: Section 1.1, -Up: Overview - -
- -

1.2 What can a sensor chip like the "LM78" do?

- -

The LM78 is a chip made by National Semiconductor which can monitor 7 -voltages (5 positive, 2 negative) from 0 to 4.08V. The inputs are usually in -series with voltage dividers which lower the +/- 12V and +/- 5V supplies to -measurable range. Therefore, the readings for such inputs need to be -re-scaled appropriately by software. - -

The LM78 also has 3 fan speed monitoring inputs, an internal -temperature sensor, a chassis intrusion sensor, and a couple maskable interrupt -inputs. The LM78 can also relay the processor's (P6 or Pent II) VID lines -which are hardwired and used to indicate to the power regulator (usually on -the mainboard close to the processor socket/slot) what voltage to supply to -the processor. - -

The LM78 can be interfaced to a system via the ISA bus and/or the -SMBus. - -

Most other sensor chips have comparable functionality. Each supported -chip is documented in the doc/chips directory. - -

-

- - -Previous: Section 1.2, -Up: Overview - -
- -

1.3 Where do I find out more about any of these chips?

- -

Most semiconductor companies have comprehensive documentation, -including complete datasheets, on their websites. Analog Devices, -Dallas Semiconductor, Maxim, and National Semiconductor have the widest selection -of sensor chips. Their websites are: - -

- -

Please see the file http://www.lm-sensors.org/wiki/UsefulLinks -for links to other companies' websites. - -

-

- -Next: , -Previous: Overview, -Up: Top - -
- -

2 Sensor and Bus Basics

- - - -
-

- - -Next: , -Up: Basics - -
- -

2.1 How are these sensors read?

- -

Sensor chips reside on either the ISA bus, the SMBus, or both. -See the file doc/chips/SUMMARY in our package for a list. - -

To communicate with chips on the ISA bus, the software uses -simple I/O reads and writes. - -

To communicate with chips on the SMBus, the software must -use an SMBus interface device, explained below. - -

-

- - -Next: , -Previous: Section 2.1, -Up: Basics - -
- -

2.2 What is the SMBus? And the I2C bus?

- -

The SMBus is the "System Management Bus". More specifically, it is a -2-wire, low-speed serial communication bus used for basic health monitoring -and hardware management. It is a specific implementation of the more -general I2C (pronunciation: I-squared-C) bus. In fact, both I2C devices -and SMBus devices may be connected to the same (I2C) bus. - -

The SMBus (or I2C bus) starts at the host controller, used for -starting transactions on the SMBus. From the host interface, the -devices communicated with are the slave devices. Each slave device has a -unique 7-bit address which the host uses to refer to that device. - -

For each supported SMBus host, there is a separate kernel module -which implements the communication protocol with the host. Some SMBus hosts -really operate on the SMBus level; these hosts can not cope with pure I2C -devices. Other hosts are in fact I2C hosts: in this case, we implement -the SMBus protocol in terms of I2C operations. But these hosts can also -talk to pure I2C devices. - -

-

- - -Next: , -Previous: Section 2.2, -Up: Basics - -
- -

2.3 I don't have an ISA bus!

- -

We promise, you do, even if you don't have any old ISA slots. -The "ISA Bus" exists in your computer even if you don't have ISA slots; -it is simply a memory-mapped area, 64KB in size (0x0000 - 0xFFFF) -where many "legacy" functions, such as keyboard and interrupt controllers, -are found. It isn't necessarily a separate physical bus. -See the file /proc/ioports for a list of devices living on -the "ISA Bus" in your system. If you don't like the term "ISA Bus" -think "I/O Space". - -

-

- - -Next: , -Previous: Section 2.3, -Up: Basics - -
- -

2.4 What sensors do processors have?

- -

Most new processors contain a thermal diode on the die itself. -The electical properties of all diodes and transistors vary -slightly with temperature. The thermal diode is exceptionally accurate -because it is directly on the die. Newer temperature sensor chips, -like the Analog Devices ADM1021 and clones, and the Winbond chips, -have circuitry for measuring the the electrical properties of -an external diode and converting this data to a temperature. -Any sensor chip listed in doc/chips/SUMMARY in our package which -has support for more than one temperature supports external temperature sensing. - -

Older motherboards and processors without this feature generally use -an LM75 placed close to the processor. This is much less accurate. - -

The Pentium 2 'boxed' processor usually has an LM75 very close to the -base of the box. It can be read through the SMBus to report the approximate -temperature of the processor. The processor also contains an internal -temperature sensor (of low accuracy) used as a fail-safe to disable the -processor in case it gets much too hot (usually around 130 degrees C). And, -the Pentium 2 also has a hard-wired signal (VID lines) on it's SEC (single -edge connector) which indicates what power supply is required to operate the -processor. - -

The P6 (Pentium-Pro) may have an LM75 in or just under the socket. -P6's also have VID lines. - -

Pentiums and Pentium w/ MMX do not have VID lines, and sometimes have -LM75's under the sockets (depends on the mainboard, and how 'modern' the -mainboard is). - -

The P2 Xeon was the first Intel processor to include the SMBus -interface on the P2 Xeon SEC. - -

-

- - -Next: , -Previous: Section 2.4, -Up: Basics - -
- -

2.5 How often are the sensor values updated?

- -

The LM78, and most other sensor chips like it, reads its sensors one -by one. A complete scanning sweep will take about 1.5 seconds. The LM78 stops -readings sensors if you try to access it, so if you access it very often -(by reading sensor values; writing new limits is safe) it will not find the -time to update its sensor values at all! Fortunately, the kernel module takes -care not to do this, and only reads new values each 1.5 seconds. If you -read the values again, you will get the 'old' values again. - -

-

- - -Previous: Section 2.5, -Up: Basics - -
- -

2.6 How are alarms triggered?

- -

It is possible to monitor each sensor and have an alarm go off if -it crosses some pre-determined limits. There are two sorts of interrupts -which can be generated by sensor chips if this happens (it depends a bit on -the actual chip if both are supported; the LM80, for example, has only -IRQ interrupts): IRQ interrupts and SMI interrupts. IRQ stands for -Interrupt Request and are the interrupt lines you can find in /proc/interrupts. -SMI stands for System Management Interrupt, and is a special interrupt which -puts the processor in a secure environment independent of any other things -running. SMI is currently not supported by the Linux kernel. IRQs are -supported, of course. - -

Even if no interrupt is generated, some bits in a status register -will be set until the register is read the next time. If the alarm condition -persists after that, the bits will be set on the next scanning sweep, etc. - -

Most drivers in our package do not support interrupts at this time. - -

-

- -Next: , -Previous: Basics, -Up: Top - -
- -

3 Installation and Management

- - - -
-

- - -Next: , -Up: Installation - -
- -

3.1 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: -

- -

Further information is in doc/modules. - -

-

-

- - -Next: , -Previous: Section 3.1, -Up: Installation - -
- -

3.2 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) - -

- -

3.2.1 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: -

    -
  1. Look at your motherboard. -
  2. Check the manufacturer's website or ask their support -
  3. Check the -"links" -page on our website some good cross-references. -
- -

- -

3.2.2 Do you support motherboard XYZ?

- -

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

- -

3.2.3 Do you support chip XYZ?

- -

This we have good answers for. -

- -

- -

3.2.4 Anybody working on a driver for chip XYZ?

- -

Newest Driver Status: http://www.lm-sensors.org/wiki/Devices - -

-

- - -Next: , -Previous: Section 3.2, -Up: Installation - -
- -

3.3 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: -

- -
-

- - -Next: , -Previous: Section 3.3, -Up: Installation - -
- -

3.4 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. - -

- -

3.4.1 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. - -

- -

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

- -

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

- -

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

- -

You forgot to run sensors -s. See above. - -

- -

3.4.4 One sensor isn't hooked up on my board!

- -

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

- -

3.4.5 I need help with sensors.conf!

- -

There is detailed help at the top of that file. - -

- -

3.4.6 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. - -

-

- - -Next: , -Previous: Section 3.4, -Up: Installation - -
- -

3.5 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. - -

-

- - -Next: , -Previous: Section 3.5, -Up: Installation - -
- -

3.6 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. - -

- -

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

- - - -
-

- - -Next: , -Previous: Section 3.6, -Up: Installation - -
- -

3.7 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! - -

-

- - -Next: , -Previous: Section 3.7, -Up: Installation - -
- -

3.8 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. - -

-

- - -Next: , -Previous: Section 3.8, -Up: Installation - -
- -

3.9 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: - -

- -
-

- - -Previous: Section 3.9, -Up: Installation - -
- -

3.10 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 -
  2. Look for kernel-i2c, or a similar rpm in the output -
  3. <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. -
  4. Try (in the build directory of lm_sensors) - 
              make clean
-          make
-
    -
  5. 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. -
- -
-

- -Next: , -Previous: Installation, -Up: Top - -
- -

4 Problems

- - - -
-

- - -Next: , -Up: Problems - -
- -

4.1 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. - -

- -

4.1.1 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. - -

- -

4.1.2 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. - -

-

- - -Next: , -Previous: Section 4.1, -Up: Problems - -
- -

4.2 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. - -

-

- - -Next: , -Previous: Section 4.2, -Up: Problems - -
- -

4.3 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. - -

-

- - -Next: , -Previous: Section 4.3, -Up: Problems - -
- -

4.4 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. - -

-

- - -Next: , -Previous: Section 4.4, -Up: Problems - -
- -

4.5 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. - -

-

- - -Next: , -Previous: Section 4.5, -Up: Problems - -
- -

4.6 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. - -

- -

4.6.1 -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. - -

-

- - -Next: , -Previous: Section 4.6, -Up: Problems - -
- -

4.7 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. Since Linux 2.6.9, the right formula is -selected automatically. -See doc/vid for more information. - -

-

- - -Next: , -Previous: Section 4.7, -Up: Problems - -
- -

4.8 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). - -

-

- - -Next: , -Previous: Section 4.8, -Up: Problems - -
- -

4.9 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. - -

-

- - -Next: , -Previous: Section 4.9, -Up: Problems - -
- -

4.10 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 http://www.lm-sensors.org/wiki/UsefulLinks for addresses. - -

-

- - -Next: , -Previous: Section 4.10, -Up: Problems - -
- -

4.11 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. - -

-

- - -Next: , -Previous: Section 4.11, -Up: Problems - -
- -

4.12 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. - -

-

- - -Next: , -Previous: Section 4.12, -Up: Problems - -
- -

4.13 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. - -

-

- - -Next: , -Previous: Section 4.13, -Up: Problems - -
- -

4.14 How do I set new limits?

- -

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

- -

4.14.1 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. - -

-

- - -Next: , -Previous: Section 4.14, -Up: Problems - -
- -

4.15 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. - -

-

- - -Next: , -Previous: Section 4.15, -Up: Problems - -
- -

4.16 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. - -

-

- - -Next: , -Previous: Section 4.16, -Up: Problems - -
- -

4.17 Bad readings from particular chips

- -

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

- -

4.17.1 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. - -

- -

4.17.2 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. - -

- -

4.17.3 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. - -

- -

4.17.4 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. - -

- -

4.17.5 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. - -

- -

4.17.6 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. - -

- -

4.17.7 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. - -

- -

4.17.8 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. - -

- -

4.17.9 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. - -

-

- - -Next: , -Previous: Section 4.17, -Up: Problems - -
- -

4.18 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. - -

-

- - -Next: , -Previous: Section 4.18, -Up: Problems - -
- -

4.19 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/[chips,busses] and if we don't support it -you can send us your request. - -

- -

4.19.1 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. - -

-

- - -Next: , -Previous: Section 4.19, -Up: Problems - -
- -

4.20 Sensors says `Can't access procfs/sysfs file'

- - - -
-

- - -Next: , -Previous: Section 4.20, -Up: Problems - -
- -

4.21 Sensors says `No sensors found!'

- - - -
-

- - -Next: , -Previous: Section 4.21, -Up: Problems - -
- -

4.22 Sensors output is not correct!

- -

What specifically is the trouble? -

- -
-

- - -Next: , -Previous: Section 4.22, -Up: Problems - -
- -

4.23 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. - -

- -

4.23.1 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. - -

- -

4.23.2 What is at I2C addresses 0x50 - 0x57?

- -

EEPROMs on your SDRAM DIMMs. Load the eeprom module and use the script -decode-dimms.pl (in the i2c-tools package) -to get more information than you ever wanted. - -

- -

4.23.3 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. - -

-

- - -Next: , -Previous: Section 4.23, -Up: Problems - -
- -

4.24 Sensors-detect doesn't work at all

- -

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

- -

4.24.1 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. - -

- -

4.24.2 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. -Use MAKEDEV or mknod to create the /dev/i2c-x files. -Run devfs in the kernel to get the /dev/i2c/x files. - -

- -

4.24.3 Sensors-detect doesn't find any sensors!

- -

Either -

    -
  1. The board doesn't have any sensors. -
  2. We don't support the sensors on the board. -
  3. The sensors it has are on an I2C bus connected to an I2C bus adapter that we don't support. -
  4. 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. -
  2. Check the manufacturer's website. -
- -

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

-

- - -Next: , -Previous: Section 4.24, -Up: Problems - -
- -

4.25 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. - -

-

- - -Next: , -Previous: Section 4.25, -Up: Problems - -
- -

4.26 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. - -

-

- - -Next: , -Previous: Section 4.26, -Up: Problems - -
- -

4.27 Sensors says `ERROR: Can't get xxxxx data!'

- - - -
-

- - -Next: , -Previous: Section 4.27, -Up: Problems - -
- -

4.28 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. - -

-

- - -Next: , -Previous: Section 4.28, -Up: Problems - -
- -

4.29 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. -
  2. Wrong chip driver. Verify that you have a chip supported by the chip driver, see What chips are on motherboard XYZ. -
  3. 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. -
  4. 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. -
  5. 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). -
- -
-

- - -Next: , -Previous: Section 4.29, -Up: Problems - -
- -

4.30 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. - -

-

- - -Next: , -Previous: Section 4.30, -Up: Problems - -
- -

4.31 Problems on particular motherboards

- -

The following boards have unique problems and solutions. - -

- -

4.31.1 Asus P4B

- -

See prog/hotplug/README.p4b if your SMBus master is not found. - -

- -

4.31.2 Tyan 2460, 2462

- -

See support tickets 805, 765, 781, 812, 813, and 867 for information. - -

- -

4.31.3 Tyan 2466

- -

See support tickets 941, 840, and 841 for information. - -

- -

4.31.4 Tyan 2688

- -

For board hangs, see support ticket 721 for information. -Also Inserting modules hangs my board. - -

-

- - -Previous: Section 4.31, -Up: Problems - -
- -

4.32 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.32.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.32.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: -

- 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 the i2c-tools package: ddcmon, -decode-dimms.pl, decode-edid.pl and -decode-vaio.pl. - -

-

- -Next: , -Previous: Problems, -Up: Top - -
- -

5 How to Ask for Help

- - - -
-

- - -Next: , -Up: Help - -
- -

5.1 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 http://www.lm-sensors.org/wiki/FeedbackAndSupport. 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: - -

- -
-

- - -Next: , -Previous: Section 5.1, -Up: Help - -
- -

5.2 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. - -

-

- - -Next: , -Previous: Section 5.2, -Up: Help - -
- -

5.3 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. - -

-

- - -Next: , -Previous: Section 5.3, -Up: Help - -
- -

5.4 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) - -

-

- - -Next: , -Previous: Section 5.4, -Up: Help - -
- -

5.5 What to do if you have other problems?

- -

Again, send the output listed above. - -

-

- - -Next: , -Previous: Section 5.5, -Up: Help - -
- -

5.6 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! - -

-

- - -Next: , -Previous: Section 5.6, -Up: Help - -
- -

5.7 How do I update a ticket?

- -

You can't. Only developers can. Follow up by emailing us -and reference your ticket number -in the subject. Please don't enter a new ticket with -follow-up information, email us instead. Thanks. - -

-

- - -Next: , -Previous: Section 5.7, -Up: Help - -
- -

5.8 How do I follow up on a ticket?

- -

Follow up by emailing us -and reference your ticket number in the subject. - -

-

- - -Previous: Section 5.8, -Up: Help - -
- -

5.9 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: - -

- -

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

- -

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

- -

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. - -

-

- -Next: , -Previous: Help, -Up: Top - -
- -

6 How to Contribute

- - - -
-

- - -Next: , -Up: Contribute - -
- -

6.1 How to write a driver

- -

See doc/developers/new_drivers in our package for instructions. - -

-

- - -Next: , -Previous: Section 6.1, -Up: Contribute - -
- -

6.2 How to get SVN access

- -

For anonymous SVN read access, see the instructions on our -download page. - -

For write access, please contact us. - -

-

- - -Next: , -Previous: Section 6.2, -Up: Contribute - -
- -

6.3 How to donate hardware to the project

- -

Contact us. - -

-

- - -Next: , -Previous: Section 6.3, -Up: Contribute - -
- -

6.4 How to join the project mailing lists

- -

There are two lists you can subscribe to: - -

- -
-

- - -Next: , -Previous: Section 6.4, -Up: Contribute - -
- -

6.5 How to access mailing list archives

- -

The primary mailing list archive is at: -http://lists.lm-sensors.org/pipermail/lm-sensors/. -It contains messages since October 28, 2001. - -

There is another mailing list archive at: -http://news.gmane.org/gmane.linux.drivers.sensors. -It contains messages since December 31, 2004. -This archive may also be accessed via a news reader: -nntp://news.gmane.org/gmane.linux.drivers.sensors -and RSS: -http://rss.gmane.org/gmane.linux.drivers.sensors. - -

And last there is a legacy archive at: -http://archives.andrew.net.au/lm-sensors. -It contains messages from October 28, 2001 through May 16, 2005. - -

-

- - -Next: , -Previous: Section 6.5, -Up: Contribute - -
- -

6.6 How to submit a patch

- -

Check out the latest from CVS, then copy the directory to another -directory, and make your changes. Generate the diff with -diff -u2 -r DIR1 DIR2. Or you can generate the diff in CVS with -cvs diff -u2. Send us the patch in an email and tell us what it does. - -

-

- - -Next: , -Previous: Section 6.6, -Up: Contribute - -
- -

6.7 How to REALLY help

- -

Believe it or not, what we really need help with are: -

- -

If you are willing to help, simply join our -discussion list, -and we'll help you help us. - -

-

- - -Previous: Section 6.7, -Up: Contribute - -
- -

6.8 How to get release announcements

- -

We don't have a separate release announcement mailing list; -however, we put all our releases on freshmeat: http://freshmeat.net -and you can register on our freshmeat project page http://freshmeat.net/projects/lm_sensors -to 'subscribe to new releases' and then freshmeat -will email you announcement. - -

-

- -Previous: Contribute, -Up: Top - -
- -

Appendix A Revision History of This Document

- - - - - diff --git a/doc/lm_sensors-FAQ.texi b/doc/lm_sensors-FAQ.texi deleted file mode 100644 index e9894f66..00000000 --- a/doc/lm_sensors-FAQ.texi +++ /dev/null @@ -1,1616 +0,0 @@ -\input texinfo.tex @c -*-texinfo-*- - -@c %**start of header -@setfilename lm_sensors-FAQ.info -@include version.texi -@settitle Sensors FAQ for lm_sensors version @value{VERSION} -@comment %**end of header - -@titlepage -@center @titlefont{This is the FAQ for the @command{lm_sensors} program, @value{VERSION}} -@sp 3 -@center Copyright (C) 1998 - 2005 -@sp 1 -@center Frodo Looijaard, -@center Philip Edelbrock, -@center Mark D. Studebaker, -@center and -@center Jean Delvare -@end titlepage - -@ifhtml -Copyright (C) 1998 - 2005@* -Frodo Looijaard,@* -Philip Edelbrock,@* -Mark D. Studebaker@* -and@* -Jean Delvare@* -@end ifhtml - -@dircategory Utilities -@direntry -* lm_sensors-FAQ: (lm_sensors-FAQ) The lm_sensors FAQ -@end direntry - -@summarycontents -@contents - -@ifnottex -@node Top -@top lm_sensors - -The lm_sensors package includes a collection of modules for general SMBus -access and hardware monitoring. NOTE: this requires special support which -is not in standard 2.2-vintage kernels. - -@end ifnottex - -@menu -* Overview:: PC and Sensor Overview -* Basics:: Sensor and Bus Basics -* Installation:: Installation and Management -* Problems:: Problems -* Help:: How to Ask for Help -* Contribute:: How to Contribute -* Document Revisions:: Revision History of This Document -@end menu - - -@node Overview, Basics, Top, Top -@chapter PC and Sensor Overview - -@menu -* Section 1.1:: What sensors are available on my PC? -* Section 1.2:: What can a sensor chip like the "LM78" do? -* Section 1.3:: Where do I find out more about any of these chips? -@end menu - -@node Section 1.1, Section 1.2, , Overview -@section What sensors are available on my PC? - -Most PC's built since late 1997 now come with a -hardware health monitoring chip. This chip may be accessed via the -ISA bus or the SMBus, depending on the motherboard. - -Some motherboard chipsets, notably the Via 686 and the SiS 5595, -contain hardware monitor functions. - -This FAQ frequently refers to the "LM78". This chip has been -obsoleted by National Semiconductor. Most motherboards today contain -a chip with similar functions. - - -@node Section 1.2, Section 1.3, Section 1.1, Overview -@section What can a sensor chip like the "LM78" do? - -The LM78 is a chip made by National Semiconductor which can monitor 7 -voltages (5 positive, 2 negative) from 0 to 4.08V. The inputs are usually in -series with voltage dividers which lower the +/- 12V and +/- 5V supplies to -measurable range. Therefore, the readings for such inputs need to be -re-scaled appropriately by software. - -The LM78 also has 3 fan speed monitoring inputs, an internal -temperature sensor, a chassis intrusion sensor, and a couple maskable interrupt -inputs. The LM78 can also relay the processor's (P6 or Pent II) VID lines -which are hardwired and used to indicate to the power regulator (usually on -the mainboard close to the processor socket/slot) what voltage to supply to -the processor. - -The LM78 can be interfaced to a system via the ISA bus and/or the -SMBus. - -Most other sensor chips have comparable functionality. Each supported -chip is documented in the @file{doc/chips} directory. - - -@node Section 1.3, , Section 1.2, Overview -@section Where do I find out more about any of these chips? - -Most semiconductor companies have comprehensive documentation, -including complete datasheets, on their websites. Analog Devices, -Dallas Semiconductor, Maxim, and National Semiconductor have the widest selection -of sensor chips. Their websites are: - -@itemize @bullet - @item @uref{http://www.analog.com} - @item @uref{http://www.dalsemi.com} - @item @uref{http://www.maxim-ic.com} - @item @uref{http://www.national.com} -@end itemize - -Please see the file @uref{http://www.lm-sensors.org/wiki/UsefulLinks} -for links to other companies' websites. - - - -@node Basics, Installation, Overview, Top -@chapter Sensor and Bus Basics - -@menu -* Section 2.1:: What sensors are available on my PC? -* Section 2.2:: What can a sensor chip like the "LM78" do? -* Section 2.3:: Where do I find out more about any of these chips? -* Section 2.4:: What sensors are available on my PC? -* Section 2.5:: What can a sensor chip like the "LM78" do? -* Section 2.6:: Where do I find out more about any of these chips? -@end menu - - -@node Section 2.1, Section 2.2, , Basics -@section How are these sensors read? - -Sensor chips reside on either the ISA bus, the SMBus, or both. -See the file @file{doc/chips/SUMMARY} in our package for a list. - -To communicate with chips on the ISA bus, the software uses -simple I/O reads and writes. - -To communicate with chips on the SMBus, the software must -use an SMBus interface device, explained below. - - -@node Section 2.2, Section 2.3, Section 2.1, Basics -@section What is the SMBus? And the I2C bus? - -The SMBus is the "System Management Bus". More specifically, it is a -2-wire, low-speed serial communication bus used for basic health monitoring -and hardware management. It is a specific implementation of the more -general I2C (pronunciation: I-squared-C) bus. In fact, both I2C devices -and SMBus devices may be connected to the same (I2C) bus. - -The SMBus (or I2C bus) starts at the host controller, used for -starting transactions on the SMBus. From the host interface, the -devices communicated with are the @dfn{slave} devices. Each slave device has a -unique 7-bit address which the host uses to refer to that device. - -For each supported SMBus host, there is a separate kernel module -which implements the communication protocol with the host. Some SMBus hosts -really operate on the SMBus level; these hosts can not cope with pure I2C -devices. Other hosts are in fact I2C hosts: in this case, we implement -the SMBus protocol in terms of I2C operations. But these hosts can also -talk to pure I2C devices. - - -@node Section 2.3, Section 2.4, Section 2.2, Basics -@section I don't have an ISA bus! - -We promise, you do, even if you don't have any old ISA slots. -The "ISA Bus" exists in your computer even if you don't have ISA slots; -it is simply a memory-mapped area, 64KB in size (0x0000 - 0xFFFF) -where many "legacy" functions, such as keyboard and interrupt controllers, -are found. It isn't necessarily a separate physical bus. -See the file @file{/proc/ioports} for a list of devices living on -the "ISA Bus" in your system. If you don't like the term "ISA Bus" -think "I/O Space". - - -@node Section 2.4, Section 2.5, Section 2.3, Basics -@section What sensors do processors have? - -Most new processors contain a thermal diode on the die itself. -The electical properties of all diodes and transistors vary -slightly with temperature. The thermal diode is exceptionally accurate -because it is directly on the die. Newer temperature sensor chips, -like the Analog Devices ADM1021 and clones, and the Winbond chips, -have circuitry for measuring the the electrical properties of -an external diode and converting this data to a temperature. -Any sensor chip listed in @file{doc/chips/SUMMARY} in our package which -has support for more than one temperature supports external temperature sensing. - -Older motherboards and processors without this feature generally use -an LM75 placed close to the processor. This is much less accurate. - -The Pentium 2 'boxed' processor usually has an LM75 very close to the -base of the box. It can be read through the SMBus to report the approximate -temperature of the processor. The processor also contains an internal -temperature sensor (of low accuracy) used as a fail-safe to disable the -processor in case it gets much too hot (usually around 130 degrees C). And, -the Pentium 2 also has a hard-wired signal (VID lines) on it's SEC (single -edge connector) which indicates what power supply is required to operate the -processor. - -The P6 (Pentium-Pro) may have an LM75 in or just under the socket. -P6's also have VID lines. - -Pentiums and Pentium w/ MMX do not have VID lines, and sometimes have -LM75's under the sockets (depends on the mainboard, and how 'modern' the -mainboard is). - -The P2 Xeon was the first Intel processor to include the SMBus -interface on the P2 Xeon SEC. - - -@node Section 2.5, Section 2.6, Section 2.4, Basics -@section How often are the sensor values updated? - -The LM78, and most other sensor chips like it, reads its sensors one -by one. A complete scanning sweep will take about 1.5 seconds. The LM78 stops -readings sensors if you try to access it, so if you access it very often -(by reading sensor values; writing new limits is safe) it will not find the -time to update its sensor values at all! Fortunately, the kernel module takes -care not to do this, and only reads new values each 1.5 seconds. If you -read the values again, you will get the 'old' values again. - - -@node Section 2.6, , Section 2.5, Basics -@section How are alarms triggered? - -It is possible to monitor each sensor and have an alarm go off if -it crosses some pre-determined limits. There are two sorts of interrupts -which can be generated by sensor chips if this happens (it depends a bit on -the actual chip if both are supported; the LM80, for example, has only -IRQ interrupts): IRQ interrupts and SMI interrupts. IRQ stands for -Interrupt Request and are the interrupt lines you can find in @file{/proc/interrupts}. -SMI stands for System Management Interrupt, and is a special interrupt which -puts the processor in a secure environment independent of any other things -running. SMI is currently not supported by the Linux kernel. IRQs are -supported, of course. - -Even if no interrupt is generated, some bits in a status register -will be set until the register is read the next time. If the alarm condition -persists after that, the bits will be set on the next scanning sweep, etc. - -Most drivers in our package do not support interrupts at this time. - - - -@node Installation, Problems, Basics, Top -@chapter Installation and Management - -@menu -* Section 3.1:: Why so many modules, and how do I cope with them? -* Section 3.2:: How do I know which chips I own? -* Section 3.3:: Which modules should I insert? -* Section 3.4:: Do I need the configuration file @file{/etc/sensors.conf}? -* Section 3.5:: What about the @samp{No such file or directory} warnings -* Section 3.6:: I get all kinds of weird compilation errors? -* Section 3.7:: It still does not compile or patch! -* Section 3.8:: @command{make install} fails on Mandrake kernels -* Section 3.9:: I get unresolved symbols when I @command{modprobe} modules -* Section 3.10:: I2C_DRIVERID_ADM1024 undefined (Red Hat especially) -@end menu - -@node Section 3.1, Section 3.2, , Installation -@section 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: -@itemize - @item Run @command{sensors-detect} and do what it tells you. - @item Always use @command{modprobe}, not @command{insmod}. -@end itemize - -Further information is in @file{doc/modules}. - - -@anchor{How do I know which chips I own} -@node Section 3.2, Section 3.3, Section 3.1, Installation -@section How do I know which chips I own? - -We have an excellent program that scans all your hardware. -It is called @file{sensors-detect} and is installed in @file{/usr/local/sbin} -by @command{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 @pxref{Help}) - - -@anchor{Section 3.2.1} -@subsection What chips are on motherboard XYZ? - - @strong{!!!!!!!!! YES THIS IS THE MOST FREQUENT QUESTION WE GET !!!!!!!!!} - -We have no idea. Here is what you should do: -@enumerate - @item Run sensors-detect. -@end enumerate - -If that doesn't work: -@enumerate 2 -@item Look at your motherboard. -@item Check the manufacturer's website or ask their support -@item Check the -@uref{http://www.lm-sensors.org/wiki/UsefulLinks, "links"} -page on @uref{http://www.lm-sensors.org, our website} some good cross-references. -@end enumerate - - -@anchor{Section 3.2.2} -@subsection Do you support motherboard XYZ? - -We don't support boards, we support chips. @xref{Section 3.2.1, What chips are on motherboard XYZ}. - - -@anchor{Section 3.2.3} -@subsection Do you support chip XYZ? - -This we have good answers for. -@itemize -@item Sorted by Manufacturer: @file{README} -@item Sorted by Manufacturer: @uref{http://www.lm-sensors.org/wiki/Devices} -@item Sorted by Sensor Driver: @file{doc/chips/SUMMARY} -@end itemize - - -@anchor{Section 3.2.4} -@subsection Anybody working on a driver for chip XYZ? - -Newest Driver Status: @uref{http://www.lm-sensors.org/wiki/Devices} - - -@node Section 3.3, Section 3.4, Section 3.2, Installation -@section Which modules should I insert? - -@command{sensors-detect} will tell you. Take the @command{modprobe} lines it -recommends and paste them into the appropriate @file{/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 @file{i2c-isa.o}. -for each type of chip you own. That's all. On my computer, I could use the -following lines: -@itemize -@item @command{modprobe i2c-isa} -@item @command{modprobe i2c-piix4} -@item @command{modprobe lm78} -@item @command{modprobe lm75} -@item @command{modprobe i2c-dev} -@item @command{sensors -s} -@end itemize - - -@node Section 3.4, Section 3.5, Section 3.3, Installation -@section Do I need the configuration file @file{/etc/sensors.conf}? - -Yes, for any applications that use @file{libsensors,} including the -@command{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 @file{/etc/sensors.conf}, but it will not -overwrite any existing file with that name. - - -@anchor{Section 3.4.1} -@subsection The labels for the voltage and temperature readings in @command{sensors} are incorrect! - -Every motherboard is different. You can customize the labels -in the file @file{/etc/sensors.conf}. That's why it exists! -The default labelling (in @file{lib/chips.c} and @file{/etc/sensors.conf}) is just -a template. - - -@anchor{Section 3.4.2} -@subsection The min and max for the readings in @command{sensors} are incorrect! - -You can customize them in the file @file{/etc/sensors.conf}. See above. - - -@anchor{Section 3.4.3} -@subsection The min and max settings in @file{/etc/sensors.conf} didn't take effect! - -You forgot to run @command{sensors -s}. See above. - - -@anchor{Section 3.4.4} -@subsection One sensor isn't hooked up on my board! - -Use an @command{ignore} line in @file{/etc/sensors.conf} so it isn't -displayed in @command{sensors}. - - -@anchor{Section 3.4.5} -@subsection I need help with @file{sensors.conf}! - -There is detailed help at the top of that file. - - -@anchor{Section 3.4.6} -@subsection Do you have a database of @file{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. - - -@node Section 3.5, Section 3.6, Section 3.4, Installation -@section What about the @samp{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 @command{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. - - -@node Section 3.6, Section 3.7, Section 3.5, Installation -@section 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 @file{/usr/local/include} or -@file{/usr/src/linux*/include}. Try to edit the @file{Makefile} for the other setting. - - -@anchor{Section 3.6.1} -@subsection @samp{No rule to make target xxxx needed by xxxx} - how to fix? - -@itemize -@item @xref{Section 3.6, I get all kinds of weird compilation errors}, also try @command{make clean} in @file{lm_sensors}. -@item If that doesn't work, try @command{make clean} in @file{i2c}. -@item If that doesn't work, try @command{make clean} in the kernel. -@item Also make sure @file{/usr/include/linux} points to @file{/usr/src/linux/include/linux}. -@end itemize - - -@node Section 3.7, Section 3.8, Section 3.6, Installation -@section 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! - - -@node Section 3.8, Section 3.9, Section 3.7, Installation -@section @command{make install} fails on Mandrake kernels - -Mandrake uses a non-standard @file{version.h} file which confuses our @file{Makefile}. -Edit our @file{Makefile} on the @code{MODDIR :=} line to hard-code the module directory. - - -@node Section 3.9, Section 3.10, Section 3.8, Installation -@section I get unresolved symbols when I @command{modprobe} modules (Red Hat especially) - -Example: -@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 -@end example - -You can also run @command{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 @command{make LINUX=/usr/src/linux-2.4.14}. - - -Try the following to be sure: - -@itemize -@item @command{nm --extern MODULE.o} -Filter out the kernel symbols, like @code{kmalloc}, @code{printk} etc. and note the -number code behind them, like @code{printk_R1b7d4074}. If there is no numeric -code after them, note this too. -@item @command{grep SYMBOL /proc/ksyms} -Substitute SYMBOL by the basename of the symbols above, like @code{kmalloc}, -@code{printk} etc. Note the number code behind them, or the lack thereof. -@item 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. -@end itemize - - -@node Section 3.10, , Section 3.9, Installation -@section 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: - -@enumerate -@item @command{rpm -qa | grep i2c} -@item Look for @file{kernel-i2c,} or a similar rpm in the output -@item -@command{rpm -ev kernel-i2c} (or the name of the similar package) -If this complains about dependencies, you can try adding -@command{--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. -@item Try (in the build directory of @file{lm_sensors)} -@example -@command{make clean} -@command{make} -@end example -@item @emph{If} you still have problems, you may have to replace the include -paths in the @file{.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. -@end enumerate - - -@node Problems, Help, Installation, Top -@chapter Problems - -@menu -* Section 4.1:: My fans report exactly half/double their values? -* Section 4.2:: Why do my two LM75's report "-48 degrees"? -* Section 4.3:: Why do I have two Vcore readings? -* Section 4.4:: How do those ALARMS work? -* Section 4.5:: My voltage readings seem to drift a bit. What's wrong? -* Section 4.6:: Some measurements are way out of range. What happened? -* Section 4.7:: What are VID lines? Why is the VID reading wrong? -* Section 4.8:: Sensor are only updated each second or so. Why? -* Section 4.9:: It takes a second before reading sensor results. Why? -* Section 4.10:: Can I be alerted when an ALARM occurs? -* Section 4.11:: SMBus transactions on my PIIX4 simply don't work. Why? -* Section 4.12:: My BIOS reports a higher CPU temperature than you! -* Section 4.13:: I read strange values from the raw @file{/proc} files! -* Section 4.14:: How do I set new limits? -* Section 4.15:: Some sensors are doubly detected? -* Section 4.16:: I ran sensors-detect, but now I get strange readings?! -* Section 4.17:: Bad readings from particular chips -* Section 4.18:: How do I configure two chips (LM87) differently? -* Section 4.19:: Dmesg says @samp{Upgrade BIOS}! I don't want to! -* Section 4.20:: Sensors says @samp{Can't access procfs/sysfs file} -* Section 4.21:: Sensors says @samp{No sensors found!} -* Section 4.22:: Sensors output is not correct! -* Section 4.23:: What is at I2C address XXX? -* Section 4.24:: Sensors-detect doesn't work at all -* Section 4.25:: Sensors says @samp{Error: Line xxx: zzzzzzz} -* Section 4.26:: Sensors only gives the name and adapter! -* Section 4.27:: Sensors says @samp{ERROR: Can't get xxxxx data!} -* Section 4.28:: Sensors doesn't find any sensors, just eeproms. -* Section 4.29:: Inserting modules hangs my board -* Section 4.30:: Inserting modules slows down my board -* Section 4.31:: Problems on particular motherboards -* Section 4.32:: Problems on 2.6 kernels -@end menu - - -@node Section 4.1, Section 4.2, , Problems -@section 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 @file{/etc/sensors.conf}: - -@example -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 -@end example - -See @file{doc/fan-divisors} in our package for further information. - - -@anchor{Fans sometimes/always read 0!} -@subsection 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 @file{doc/fan-divisors} -in our package for further information. - - -@anchor{I doubled the fan divisor and the fan still reads 7000} -@subsection 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 @file{/etc/sensors.conf}. -@xref{Section 4.1, My fans report exactly half/double their values compared to the BIOS}, -and see @file{doc/fan-divisors} in our package for further information. - - -@node Section 4.2, Section 4.3, Section 4.1, Problems -@section 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. - - -@node Section 4.3, Section 4.4, Section 4.2, Problems -@section 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 @command{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. - - -@node Section 4.4, Section 4.5, Section 4.3, Problems -@section How do those ALARMS work? The current value is within range but there is still an ALARM warning! - -The ALARM indications in @command{sensors} are those reported by the -sensor chip itself. They are NOT calculated by @command{sensors}. @command{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 @file{doc/chips} and the -chip datasheet for more information. - - -@node Section 4.5, Section 4.6, Section 4.4, Problems -@section 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. - - -@node Section 4.6, Section 4.7, Section 4.5, Problems -@section 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. - -@anchor{-5V and -12V readings are way out of range!} -@subsection -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 -@command{ignore inN} lines to @file{/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. - - -@node Section 4.7, Section 4.8, Section 4.6, Problems -@section 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 @command{ignore vid} to @file{/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. Since Linux 2.6.9, the right formula is -selected automatically. -See @file{doc/vid} for more information. - - -@node Section 4.8, Section 4.9, Section 4.7, Problems -@section 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). - - -@node Section 4.9, Section 4.10, Section 4.8, Problems -@section 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. - - -@node Section 4.10, Section 4.11, Section 4.9, Problems -@section 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 @uref{http://www.lm-sensors.org/wiki/UsefulLinks} for addresses. - - -@node Section 4.11, Section 4.12, Section 4.10, Problems -@section 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. - - -@node Section 4.12, Section 4.13, Section 4.11, Problems -@section 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: - -@example -chip lm75-*-49 # Or whatever chip this relates to -label temp "Processor" -compute temp @@*1.2+13,(@@-13)/1.2 # Or whatever formula -@end example - -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. - -@node Section 4.13, Section 4.14, Section 4.12, Problems -@section I try to read the raw @file{/proc} files, but the values are strange?!? - -Remember, these values do not take the configuration file -@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 @command{sensors} program) instead. - - -@node Section 4.14, Section 4.15, Section 4.13, Problems -@section How do I set new limits? - -Change the limit values in @file{/etc/sensors.conf} and then run -@command{sensors -s}. - - -@anchor{I set new limits and it didnt work} -@subsection I set new limits and it didn't work? - -You forgot to run @command{sensors -s}. Put it in a @file{/etc/rc.d/...} file -after the modprobe lines to run at startup. - - -@node Section 4.15, Section 4.16, Section 4.14, Problems -@section 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 @command{ignore=} modprobe parameters it suggests. - - -@node Section 4.16, Section 4.17, Section 4.15, Problems -@section 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 @kbd{s} when you are asked whether you want to -scan the PIIX4. - - -@node Section 4.17, Section 4.18, Section 4.16, Problems -@section Bad readings from particular chips - -See below for some particularly troublesome chips. -Also be sure and check @file{doc/chips/xxxxx} for the particular driver. - - -@anchor{Bad readings from the AS99127F} -@subsection 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 @file{/etc/sensors.conf.} Please don't ask us to -fix the driver. Ask Asus to release a datasheet. - - -@anchor{Bad readings from the VIA 686A} -@subsection 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 @file{/etc/sensors.conf.} Please don't ask us to -fix the driver. Ask Via to release a better datasheet. -Also, don't forget to @command{modprobe i2c-isa}. - - -@anchor{Bad readings from the MTP008} -@subsection 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 @file{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. - - -@anchor{Bad temperature readings from the SIS5595} -@subsection 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. - - -@anchor{Bad readings from a w8378[12]d} -@subsection 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 -@command{force_as99127f=BUS,0x2d} where @code{BUS} is your i2c bus number. -Cat /proc/bus/i2c to see a list of bus numbers. -Read the w83781d module documentation (@file{doc/chips/w83781d}) -for more details. - - -@anchor{Bus hangs on Ali 1543 on Asus P5A boards} -@subsection 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 @command{ignore=1,0x2d} or similar option -to the w83781d module to prevent i2c accesses. - - -@anchor{Bad readings from LM75} -@subsection Bad readings from LM75! - -The LM75 detection is poor and other hardware is often misdetected -as an LM75. Figure out what you really have @xref{Section 3.2.1, What chips are on motherboard XYZ}. - - -@anchor{Bad readings from LM78} -@subsection 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 @xref{Section 3.2.1, What chips are on motherboard XYZ}. - - -@anchor{Bad readings from LM80} -@subsection Bad readings from LM80! - -The LM80 detection is poor and other hardware is often misdetected -as an LM80. Figure out what you really have @xref{Section 3.2.1, What chips are on motherboard XYZ}. - - -@node Section 4.18, Section 4.19, Section 4.17, Problems -@section 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 @file{/etc/sensors.conf} as follows: -@example -chip "lm87-i2c-*-2c" - put configuration for the chip at 0x2c here -chip "lm87-i2c-*-2d" - put configuration for the chip at 0x2d here -@end example - -There is a commented example in @file{sensors.conf.eg} which should -be helpful. - - -@node Section 4.19, Section 4.20, Section 4.18, Problems -@section Dmesg says @samp{Upgrade BIOS}! I don't want to! - -If the problem is a PCI device is not present in @command{lspci}, the solution -is complex. For the ALI M7101 device, there is a solution which uses the -2.4 kernel's @command{hotplug} facility. See @file{prog/hotplug} in our package. -For other PCI devices, you can try to modify -the m7101 solution in @file{prog/hotplug}. - - -If dmesg says @samp{try force_addr}, see below. Other drivers generally do not -support the force_addr parameter. Sorry. Check the documentation -for your driver in @file{doc/[chips,busses]} and if we don't support it -you can send us your request. - - -@anchor{Dmesg says use force_addr=0xaddr! What address do I use} -@subsection Dmesg says @samp{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 -@command{modprobe via686a force_addr=0xADDRESS} where ADDRESS -is the I/O address. You must select an address that is not in use. -@command{cat @file{/proc/ioports}} to check (carefully) for conflicts. A high number like -0xf000 is generally safe. - - -@node Section 4.20, Section 4.21, Section 4.19, Problems -@section Sensors says @samp{Can't access procfs/sysfs file} - -@itemize -@item Linux 2.6 -@itemize -@item Did you @command{modprobe i2c_sensor}? Check @command{lsmod}. -@item Do you have sysfs support in your kernel and @file{/sys} mounted (is @file{/sys} there and populated)? -Create /sys with @command{mkdir /sys} if needed. Then add the following line to @file{/etc/fstab}: -@example -sys /sys sysfs default 0 0@end example -and @command{mount /sys}. -@end itemize -@item Linux 2.4 -@itemize -@item Did you @command{modprobe i2c-proc}? Check @command{lsmod}. -@item Do you have procfs support in your kernel and @file{/proc} mounted (is @file{/proc} there and populated)? -Create /proc with @command{mkdir /proc} if needed. Then add the following line to @file{/etc/fstab}: -@example -proc /proc proc defaults 0 0@end example -and @command{mount /proc}. -@end itemize -@item If you did @command{sensors -s}, did you run it as root? -@end itemize - - -@node Section 4.21, Section 4.22, Section 4.20, Problems -@section Sensors says @samp{No sensors found!} - -@itemize -@item Did @command{sensors-detect} find sensors? (If not @pxref{Sensors-detect doesnt find any sensors}) -@item Did you do what @command{sensors-detect} said? -@item Did you @command{modprobe} your sensor modules? -@item Did you @command{modprobe} your I2C adapter modules? -@item Did you @command{modprobe i2c-isa} if you have ISA sensor chips? -@item Check @command{lsmod}. -@end itemize - - -@node Section 4.22, Section 4.23, Section 4.21, Problems -@section Sensors output is not correct! - - What specifically is the trouble? -@itemize -@item Labels: @xref{Section 3.4.1, The labels for the voltage and temperature readings in sensors are incorrect}. -@item Min/max readings: @xref{Section 3.4.2, The min and max for the readings in sensors are incorrect}, and @xref{Section 3.4.3, The min and max settings didnt take effect}. -@item AS99127F: @xref{Section 4.16, I ran sensors-detect but now I get very strange readings?}. -@item Via 686A: @xref{Section 4.16, I ran sensors-detect but now I get very strange readings?}. -@item Other specific chips: @xref{Section 4.16, I ran sensors-detect but now I get very strange readings?}. -@item No output for a particular sensors chip: @xref{Section 5.3, What to do if it inserts but nothing happens}. -@item No output at all: @xref{Section 4.21, Sensors says No sensors found}, @xref{Section 5.3, What to do if it inserts but nothing happens}. -@item Completely bad output for a particular sensor chip: @xref{Section 5.4, What to do if I read only bogus information}. -@item One particular sensor readings: -@itemize -@item Maybe it isn't hooked up? - tell 'sensors' to ignore it. @xref{Section 3.4.4, One sensor isnt hooked up on my board}. -@item Maybe it is hooked up differently on your motherboard? - adjust @file{sensors.conf} calculation. -@end itemize -@end itemize - -@node Section 4.23, Section 4.24, Section 4.22, Problems -@section What is at I2C address XXX? - -In general, we don't know. Start by running @command{sensors-detect}. -If it doesn't recognize it, try running @command{i2cdump}. A partial list -of manufacturers' IDs are at the bottom of @file{doc/chips/SUMMARY}. - - -@anchor{What is at I2C address 0x69} -@subsection 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. - - -@anchor{What is at I2C addresses 0x50 - 0x57} -@subsection What is at I2C addresses 0x50 - 0x57? - -EEPROMs on your SDRAM DIMMs. Load the eeprom module and use the script -@command{decode-dimms.pl} (in the i2c-tools package) -to get more information than you ever wanted. - - -@anchor{What is at I2C addresses 0x30 - 0x37} -@subsection 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 @command{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. - - -@node Section 4.24, Section 4.25, Section 4.23, Problems -@section Sensors-detect doesn't work at all - -It could be many things. What was the problem? @xref{Section 4.31, Problems on particular motherboards}. - - -@anchor{Sensors-detect says "Couldnt open /proc/bus/i2c?!?"} -@subsection 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. - - -@anchor{Sensors-detect says "Cant open /dev/i2c[-/]0"} -@subsection Sensors-detect says "Can't open /dev/i2c[-/]0" - -Your @file{/dev/i2c-0,} @file{/dev/i2c0}, or @file{/dev/i2c/0} files do not exist -or you did not run @command{sensors-detect} as root. -Use @command{MAKEDEV} or @command{mknod} to create the @file{/dev/i2c-x} files. -Run @command{devfs} in the kernel to get the @file{/dev/i2c/x} files. - - -@anchor{Sensors-detect doesnt find any sensors} -@subsection Sensors-detect doesn't find any sensors! - -Either -@enumerate -@item The board doesn't have any sensors. -@item We don't support the sensors on the board. -@item The sensors it has are on an I2C bus connected to an I2C bus adapter that we don't support. -@item You don't have the latest version of lm_sensors. -@end enumerate - -But in any case you should figure out what is on the board: -@enumerate -@item Look at your motherboard. -@item Check the manufacturer's website. -@end enumerate - -When you know what chips you have, check the -@uref{http://www.lm-sensors.org/wiki/Devices, Driver Status} web page to -see if support has been added for your chip in a later release or in SVN. - - -@node Section 4.25, Section 4.26, Section 4.24, Problems -@section Sensors says @samp{Error: Line xxx: zzzzzzz} - -These are errors from the libsensors library in -reading the @file{/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. - - -@node Section 4.26, Section 4.27, Section 4.25, Problems -@section Sensors only gives the name and adapter for my chip - -If @command{sensors} only says this, for example, and doesn't -provide any actual data at all: - -@example -it87-isa-0290 -Adapter: ISA adapter -@end example - -Your chip is not currently supported by @command{sensors} and so all it -does is print out that information. Get the latest release -and be sure you are running the @command{sensors} program it installed -and not some older @command{sensors}. - - -@node Section 4.27, Section 4.28, Section 4.26, Problems -@section Sensors says @samp{ERROR: Can't get xxxxx data!} - -@itemize -@item (Linux 2.6) Make sure you are using one of the -@uref{http://www.lm-sensors.org/wiki/Kernel2.6, -recommended kernel/lm_sensors combination}. -@item You have a @file{libsensors}/@command{sensors} mismatch. -@command{sensors} is unable to -get a data entry from @file{libsensors}. You probably have an -old @file{libsensors} in your @file{/etc/ld.so.conf} path. -Make sure you did (as root) a @command{make install} (Linux 2.4) or -@command{make user_install} (Linux 2.6) followed by a @command{ldconfig}. -Then check the output of @command{ldconfig -v | grep libsensors} to -verify that there is only ONE @file{libsensors} entry and that it matches -the @file{libsensors} that was built in the @file{lib/} directory in @file{lm_sensors2}. -@end itemize - - -@node Section 4.28, Section 4.29, Section 4.27, Problems -@section Sensors doesn't find any sensors, just eeproms. - -@xref{Section 4.24, Sensors-detect doesnt work at all}, if @command{sensors-detect} failed to find any sensors. - -If @command{sensors-detect} did find sensors, did you insert your modules? For chips on the ISA -bus, did you insert i2c-isa? - -@xref{Section 5.2, What to do if a module wont insert}, if the modules didn't insert, -also @ref{Section 4.21, Sensors says No sensors found}. - - -@node Section 4.29, Section 4.30, Section 4.28, Problems -@section Inserting modules hangs my board - -There are several possible causes: -@enumerate -@item Bus driver problems. Insert the bus driver first, before you have inserted any chip drivers, to verify. -@item Wrong chip driver. Verify that you have a chip supported by the chip driver, see @ref{Section 3.2.1, What chips are on motherboard XYZ}. -@item The chip driver is reinitializing the chip, which undoes critical initialization done by the BIOS. Try the parameter @command{init=0} for the w83781d driver; this is the only driver supporting this parameter. -@item Some chips on the bus don't like to be probed at all. After inserting the bus driver (but not the chip drivers), run @command{i2cdetect} on the bus, then @command{i2cdump} on each address responding to @command{i2cdetect}. This may find the culprit. Do not @command{i2cdump address 0x69}, the clock chip. -@item 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 @command{modprobe ignore_range=0,0x00,0x28,0,0x2a,0x7f} to prevent access to other addresses. (@command{init=0} also req'd for the Tyan 2688). -@end enumerate - - -@node Section 4.30, Section 4.31, Section 4.29, Problems -@section 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 @file{/etc/sensors.conf} and run @command{sensors -s}. - - -@node Section 4.31, Section 4.32, Section 4.30, Problems -@section Problems on particular motherboards - -The following boards have unique problems and solutions. - - -@anchor{Asus P4B} -@subsection Asus P4B - -See @file{prog/hotplug/README.p4b} if your SMBus master is not found. - - -@anchor{Tyan 2460 2462} -@subsection Tyan 2460, 2462 - -See support tickets 805, 765, 781, 812, 813, and 867 for information. - - -@anchor{Tyan 2466} -@subsection Tyan 2466 - -See support tickets 941, 840, and 841 for information. - - -@anchor{Tyan 2688} -@subsection Tyan 2688 - -For board hangs, see support ticket 721 for information. -Also @ref{Section 4.29, Inserting modules hangs my board}. - - -@node Section 4.32, , Section 4.31, Problems -@section 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. - -@subsection 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. - -@subsection 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: -@itemize -@item libsensors will no more need to know about the underlying bus types -(I2C/SMBus, ISA or other); -@item libsensors will no more list non-hardware monitoring chips. -@end itemize -This explains why EEPROMs are no more displayed by @command{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 the i2c-tools package: @command{ddcmon}, -@command{decode-dimms.pl}, @command{decode-edid.pl} and -@command{decode-vaio.pl}. - - -@node Help, Contribute, Problems, Top -@chapter How to Ask for Help - -@menu -* Section 5.1:: What to send us when asking for help -* Section 5.2:: What to do if a module won't insert? -* Section 5.3:: What to do if it inserts, but nothing happens? -* Section 5.4:: What to do if I read only bogus information? -* Section 5.5:: What to do if you have other problems? -* Section 5.6:: What if it just works like a charm? -* Section 5.7:: How do I update a ticket? -* Section 5.8:: How do I follow up on a ticket? -* Section 5.9:: Why did you decide not to support undocumented chips? -@end menu - - -@node Section 5.1, Section 5.2, , Help -@section 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 @uref{http://lists.lm-sensors.org/mailman/listinfo/lm-sensors, 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 @uref{http://www.lm-sensors.org/wiki/FeedbackAndSupport}. 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: - -@itemize -@item The dmesg or syslog output if applicable -@item The output of (as root) @command{prog/detect/sensors-detect} -@item The output of @command{lsmod} -@item If a PCI chip problem: -@itemize -@item The output of @command{lspci -n} -@end itemize -@item If an I2C sensor chip problem: -@itemize -@item The output of (as root) @command{prog/detect/i2cdetect X} -where X = the bus number (run @command{i2cdetect} with no arguments to list the busses) -(please send this only if it's not all @samp{XX}) -@item The output of (as root) @command{prog/dump/i2cdump X 0xXX} -where XX = the address of each chip you see in the output of @command{i2cdetect}. (run once for each chip) -(please send this only if it's not all @samp{ff}) -@end itemize -@item If an ISA sensor chip problem: -@itemize -@item The output of (as root) @command{prog/dump/isadump 0x295 0x296} (only if it's not all @samp{XX}) -@end itemize -@item Part numbers of chips on your motherboard you think are the sensor chips (look at your motherboard) -@item Motherboard type -@item Sensors version -@item Kernel version -@end itemize - - -@node Section 5.2, Section 5.3, Section 5.1, Help -@section What to do if a module won't insert? - -Did you use @command{modprobe} instead of @command{insmod}??? Don't use insmod. - -Were there unresolved symbols? Did you run @command{depmod -a}? Run -@command{depmod -a -e} to see where the symbol problem is. - -ALWAYS inspect the output of @command{dmesg}. That's where the error -messages come out!!! Don't rely on the generic message from @command{modprobe}. -If you still can't figure it out, send us the information -listed above. - - -@node Section 5.3, Section 5.4, Section 5.2, Help -@section What to do if it inserts, but nothing happens? - -For an ISA sensor chip, did you also @command{modprobe i2c-isa}? It must be inserted. - -For an I2C sensor chip, did you also @command{modprobe i2c-xxx} where xxx is your -I2C bus adapter? It must be inserted. - -Always inspect the output of @command{dmesg}. That's where the error -messages come out. If you still can't figure it out, send us the information -listed above. - - -@node Section 5.4, Section 5.5, Section 5.3, Help -@section 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 (@pxref{Help}) - - -@node Section 5.5, Section 5.6, Section 5.4, Help -@section What to do if you have other problems? - -Again, send the output listed above. - - -@node Section 5.6, Section 5.7, Section 5.5, Help -@section 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! - - -@node Section 5.7, Section 5.8, Section 5.6, Help -@section How do I update a ticket? - -You can't. Only developers can. Follow up by emailing us -and reference your ticket number -in the subject. Please don't enter a new ticket with -follow-up information, email us instead. Thanks. - - -@node Section 5.8, Section 5.9, Section 5.7, Help -@section How do I follow up on a ticket? - -Follow up by emailing us -and reference your ticket number in the subject. - - -@node Section 5.9, , Section 5.8, Help -@section 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: - -@itemize -@item 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. -@item 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. -@item 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. -@item 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). -@end itemize - -There are also several reasons why we do not want to support such drivers, -even if they were written by other people: - -@itemize -@item 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. -@item 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. -@item 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. -@end itemize - -Lastly, there are other considerations, some of which are deliberately -political: - -@itemize -@item 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. -@item 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. -@end itemize - -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. - - -@node Contribute, Document Revisions, Help, Top -@chapter How to Contribute - -@menu -* Section 6.1:: How to write a driver -* Section 6.2:: How to get SVN access -* Section 6.3:: How to donate hardware to the project -* Section 6.4:: How to join the project mailing list -* Section 6.5:: How to access mailing list archives -* Section 6.6:: How to submit a patch -* Section 6.7:: How to REALLY help -* Section 6.8:: How to get release announcements -@end menu - - -@node Section 6.1, Section 6.2, , Contribute -@section How to write a driver - -See @file{doc/developers/new_drivers} in our package for instructions. - - -@node Section 6.2, Section 6.3, Section 6.1, Contribute -@section How to get SVN access - -For anonymous SVN read access, see the instructions on our -@uref{http://www.lm-sensors.org/wiki/Download, download page}. - -For write access, please contact us. - - -@node Section 6.3, Section 6.4, Section 6.2, Contribute -@section How to donate hardware to the project - -@uref{http://www.lm-sensors.org/wiki/FeedbackAndSupport, Contact us}. - - -@node Section 6.4, Section 6.5, Section 6.3, Contribute -@section How to join the project mailing lists - -There are two lists you can subscribe to: - -@itemize -@item A @uref{http://lists.lm-sensors.org/mailman/listinfo/lm-sensors, general discussion list}, -meant for both development and user support. You do not need to be subscribed to post. -@item A @uref{http://lists.lm-sensors.org/mailman/listinfo/lm-sensors-commit, CVS commits list}, -for watching the changes made to the CVS repositories. This list is read-only. -@end itemize - - -@node Section 6.5, Section 6.6, Section 6.4, Contribute -@section How to access mailing list archives - -The primary mailing list archive is at: -@uref{http://lists.lm-sensors.org/pipermail/lm-sensors/}. -It contains messages since October 28, 2001. - -There is another mailing list archive at: -@uref{http://news.gmane.org/gmane.linux.drivers.sensors}. -It contains messages since December 31, 2004. -This archive may also be accessed via a news reader: -@uref{nntp://news.gmane.org/gmane.linux.drivers.sensors} -and RSS: -@uref{http://rss.gmane.org/gmane.linux.drivers.sensors}. - -And last there is a legacy archive at: -@uref{http://archives.andrew.net.au/lm-sensors}. -It contains messages from October 28, 2001 through May 16, 2005. - - -@node Section 6.6, Section 6.7, Section 6.5, Contribute -@section How to submit a patch - -Check out the latest from CVS, then copy the directory to another -directory, and make your changes. Generate the diff with -@command{diff -u2 -r DIR1 DIR2}. Or you can generate the diff in CVS with -@command{cvs diff -u2}. Send us the patch in an email and tell us what it does. - -@node Section 6.7, Section 6.8, Section 6.6, Contribute -@section How to REALLY help - -Believe it or not, what we really need help with are: -@itemize -@item Answering email -@item Answering support tickets -@item Porting drivers to Linux 2.6 -@item Creating a sensors.conf database -@item Reviewing patches -@end itemize - -If you are willing to help, simply join our -@uref{http://lists.lm-sensors.org/mailman/listinfo/lm-sensors, discussion list}, -and we'll help you help us. - - -@node Section 6.8, , Section 6.7, Contribute -@section How to get release announcements - -We don't have a separate release announcement mailing list; -however, we put all our releases on freshmeat: @uref{http://freshmeat.net} -and you can register on our freshmeat project page @uref{http://freshmeat.net/projects/lm_sensors} -to 'subscribe to new releases' and then freshmeat -will email you announcement. - - -@node Document Revisions, , Contribute, Top -@appendix Revision History of This Document - -@itemize -@item Rev 2.19 (JD) Removed 4.32 (Thinkpad-specific issues), 2007-09-24 -@item Rev 2.18 (JD) Removed version 1 specifics part, 2005-12-17 -@item Rev 2.17 (JD) Added 5.9 (why we don't support undocumented chips), - removed 6.9 (doesn't apply to the new mailing list), 2005-10-05 -@item Rev 2.16 (JD) Added 4.33.2, 2005-09-06 -@item Rev 2.15 (JD) Updates, including mailing-list change, 2005-05-21 -@item Rev 2.14 (MDS) Updated 4.12, 2004-11-26 -@item Rev 2.13 (JD) Added 4.6.1, updated 4.7, 2004-06-23 -@item Rev 2.12 (JD) Updated 4.27, 2004-04-11 -@item Rev 2.11 (JD) Various updates, 2004-01-18 -@item Rev 2.10 (MDS) Various updates, 2004-01-03 -@item Rev 2.9 (CP) Converted to Gnu texinfo format, 2002-09-10 -@item Rev 2.8 (MDS) Minor updates 2002-07-10, released with lm_sensors 2.6.4 -@item Rev 2.7 (MDS) Minor updates 2002-04-25 -@item Rev 2.6 (MDS) Minor updates 2002-01-15, released with lm_sensors 2.6.3 -@item Rev 2.5 (MDS) Minor updates 2001-11-11, released with lm_sensors 2.6.2 -@item Rev 2.4 (MDS) Minor updates 2001-07-22 -@item Rev 2.3 (MDS) General update, 2001-02-24, released with lm_sensors 2.6.0. -@item Rev 2.2 (Frodo) Corrections for lm_sensors 2.4, 1999-09-20 -@item Rev 2.1 (Frodo) Corrections for lm_sensors 2.2, 1999-01-12 -@item Rev 2.0 (Frodo) Major revision for lm_sensors 2.1, 1998-12-29 -@item Rev 1.10 (Frodo) Modified 3.8, updated some other things, 1998-09-24 -@item Rev 1.9 (Frodo) Added 3.15, 1998-09-06 -@item Rev 1.8 (Frodo) Added 3.14, 1998-09-05 -@item Rev 1.7 (Phil) Added 3.13 and some other minor changes, 1998-09-01 -@item Rev 1.6 (Frodo) Added 4, 4.1, 4.2, 4.3, 4.4, 4.5, 1998-09-01 -@item Rev 1.5 (Frodo) Added 2.3, 2.4, 3.9, 3.10, 3.11, 1998-08-26 -@item Rev 1.4 (Frodo) Added some more Winbond information, and 3.5-3.8, 1998-08-17 -@item Rev 1.3 (Phil) Added info on the Winbond chip, 1998-08-16 -@item Rev 1.2 (Frodo) Adapation, 1998-08-10 -@item Rev 1.1 (Phil) Modifications, 1998-08-09 -@item Rev 1.0 (Phil) First version, 1998-08-03 -@end itemize - -@bye diff --git a/doc/version.texi b/doc/version.texi deleted file mode 100644 index 40ed7bee..00000000 --- a/doc/version.texi +++ /dev/null @@ -1,2 +0,0 @@ -@set UPDATED 24 September 2007 -@set VERSION 2.19 diff --git a/prog/detect/sensors-detect b/prog/detect/sensors-detect index 3c9fbbe2..7271e598 100755 --- a/prog/detect/sensors-detect +++ b/prog/detect/sensors-detect @@ -5863,9 +5863,8 @@ sub main if(! @chips_detected) { print "Sorry, no sensors were detected.\n", "Either your sensors are not supported, or they are connected to an\n", - "I2C or SMBus adapter that is not supported. See doc/FAQ,\n", - "doc/lm_sensors-FAQ.html or http://www.lm-sensors.org/wiki/FAQ\n", - "(FAQ #4.24.3) for further information.\n", + "I2C or SMBus adapter that is not supported. See\n", + "http://www.lm-sensors.org/wiki/FAQ/Chapter3 for further information.\n", "If you find out what chips are on your board, check\n", "http://www.lm-sensors.org/wiki/Devices for driver status.\n"; exit;