2003-08-23 17:29:58 +00:00
< html lang = "en" > < head >
2003-07-03 06:50:08 +00:00
< title > Sensors FAQ for lm_sensors version 2.9< / title >
2002-09-15 02:16:22 +00:00
< meta http-equiv = "Content-Type" content = "text/html" >
2003-08-23 17:29:58 +00:00
< meta name = description content = "Sensors FAQ for lm_sensors version 2.9" >
< meta name = generator content = "makeinfo 4.0" >
< link href = "http://texinfo.org/" rel = generator-home >
< / head > < body >
< p > C< p > opyright (c) 1998 - 2002< br >
2002-09-15 02:16:22 +00:00
< a href = "mailto:frodol@dds.nl" > Frodo Looijaard< / a > ,< br >
< a href = "mailto:phil@netroedge.com" > Philip Edelbrock< / a > ,< br >
and< br >
< a href = "mailto:mdsxyz123@yahoo.com" > Mark Studebaker< / a > < br >
2003-08-23 17:29:58 +00:00
< h1 > Table of Contents< / h1 >
2002-09-15 02:16:22 +00:00
< ul >
2003-08-23 17:29:58 +00:00
< li > < a href = "#Top" > lm_sensors< / a >
< li > < a href = "#Overview" > 1 PC and Sensor Overview< / a >
2002-09-15 02:16:22 +00:00
< ul >
< li > < a href = "#Section%201.1" > 1.1 What sensors are available on my PC?< / a >
< li > < a href = "#Section%201.2" > 1.2 What can a sensor chip like the "LM78" do?< / a >
< li > < a href = "#Section%201.3" > 1.3 Where do I find out more about any of these chips?< / a >
2003-08-23 17:29:58 +00:00
< / ul >
< li > < a href = "#Basics" > 2 Sensor and Bus Basics< / a >
2002-09-15 02:16:22 +00:00
< ul >
< li > < a href = "#Section%202.1" > 2.1 How are these sensors read?< / a >
< li > < a href = "#Section%202.2" > 2.2 What is the SMBus? And the I2C bus?< / a >
< li > < a href = "#Section%202.3" > 2.3 I don't have an ISA bus!< / a >
< li > < a href = "#Section%202.4" > 2.4 What sensors do processors have?< / a >
< li > < a href = "#Section%202.5" > 2.5 How often are the sensor values updated?< / a >
< li > < a href = "#Section%202.6" > 2.6 How are alarms triggered?< / a >
2003-08-23 17:29:58 +00:00
< / ul >
< li > < a href = "#Installation" > 3 Installation and Management< / a >
2002-09-15 02:16:22 +00:00
< ul >
< li > < a href = "#Section%203.1" > 3.1 Why so many modules, and how do I cope with them?< / a >
< li > < a href = "#Section%203.2" > 3.2 How do I know which chips I own?< / a >
< ul >
< li > < a href = "#Section%203.2" > 3.2.1 What chips are on motherboard XYZ?< / a >
< li > < a href = "#Section%203.2" > 3.2.2 Do you support motherboard XYZ?< / a >
< li > < a href = "#Section%203.2" > 3.2.3 Do you support chip XYZ?< / a >
< li > < a href = "#Section%203.2" > 3.2.4 Anybody working on a driver for chip XYZ?< / a >
2003-08-23 17:29:58 +00:00
< / ul >
2002-09-15 02:16:22 +00:00
< li > < a href = "#Section%203.3" > 3.3 Which modules should I insert?< / a >
< li > < a href = "#Section%203.4" > 3.4 Do I need the configuration file < code > /etc/sensors.conf< / code > ?< / a >
< ul >
< li > < a href = "#Section%203.4" > 3.4.1 The labels for the voltage and temperature readings in < code > sensors< / code > are incorrect!< / a >
< li > < a href = "#Section%203.4" > 3.4.2 The min and max for the readings in < code > sensors< / code > are incorrect!< / a >
< li > < a href = "#Section%203.4" > 3.4.3 The min and max settings in < code > /etc/sensors.conf< / code > didn't take effect!< / a >
< li > < a href = "#Section%203.4" > 3.4.4 One sensor isn't hooked up on my board!< / a >
< li > < a href = "#Section%203.4" > 3.4.5 I need help with < code > sensors.conf< / code > !< / a >
< li > < a href = "#Section%203.4" > 3.4.6 Do you have a database of < code > sensors.conf< / code > entries for specific boards?< / a >
2003-08-23 17:29:58 +00:00
< / ul >
2002-09-15 02:16:22 +00:00
< li > < a href = "#Section%203.5" > 3.5 What about the < code > No such file or directory< / code > warnings when I compile?< / a >
< li > < a href = "#Section%203.6" > 3.6 I get all kinds of weird compilation errors?< / a >
< ul >
< li > < a href = "#Section%203.6" > 3.6.1 < code > No rule to make target xxxx needed by xxxx< / code > - how to fix?< / a >
2003-08-23 17:29:58 +00:00
< / ul >
2002-09-15 02:16:22 +00:00
< li > < a href = "#Section%203.7" > 3.7 It still does not compile or patch!< / a >
< li > < a href = "#Section%203.8" > 3.8 < code > make install< / code > fails on Mandrake kernels< / a >
< li > < a href = "#Section%203.9" > 3.9 I get unresolved symbols when I < code > modprobe< / code > modules (Red Hat especially)< / a >
< li > < a href = "#Section%203.10" > 3.10 I2C_DRIVERID_ADM1024 undefined (Red Hat especially)< / a >
2003-08-23 17:29:58 +00:00
< / ul >
< li > < a href = "#Problems" > 4 Problems< / a >
2002-09-15 02:16:22 +00:00
< ul >
< li > < a href = "#Section%204.1" > 4.1 My fans report exactly half/double their values compared to the BIOS?< / a >
< ul >
< li > < a href = "#Section%204.1" > 4.1.1 Fans sometimes/always read 0!!< / a >
< li > < a href = "#Section%204.1" > 4.1.2 I doubled the fan divisor and the fan still reads 7000!< / a >
2003-08-23 17:29:58 +00:00
< / ul >
2002-09-15 02:16:22 +00:00
< li > < a href = "#Section%204.2" > 4.2 Why do my two LM75's report "-48 degrees"?< / a >
< li > < a href = "#Section%204.3" > 4.3 Why do I have two Vcore readings, I have only one processor!< / a >
< li > < a href = "#Section%204.4" > 4.4 How do those ALARMS work? The current value is within range but there is still an ALARM warning!< / a >
< li > < a href = "#Section%204.5" > 4.5 My voltage readings seem to drift a bit. Is something wrong?< / a >
< li > < a href = "#Section%204.6" > 4.6 Some measurements are way out of range. What happened?< / a >
< li > < a href = "#Section%204.7" > 4.7 What are VID lines? Why is the VID reading wrong?< / a >
< li > < a href = "#Section%204.8" > 4.8 I read sensor values several times a second, but they are only updated only each second or so. Why?< / a >
< li > < a href = "#Section%204.9" > 4.9 It sometimes seems to take almost a second before I see the sensor reading results. Why?< / a >
< li > < a href = "#Section%204.10" > 4.10 Can I be alerted when an ALARM occurs?< / a >
< li > < a href = "#Section%204.11" > 4.11 SMBus transactions on my PIIX4 simply don't work (timeouts happen). Why?< / a >
< li > < a href = "#Section%204.12" > 4.12 My BIOS reports a much higher CPU temperature than your modules!< / a >
< li > < a href = "#Section%204.13" > 4.13 I try to read the raw < code > /proc< / code > files, but the values are strange?!?< / a >
< li > < a href = "#Section%204.14" > 4.14 How do I set new limits?< / a >
< ul >
< li > < a href = "#Section%204.14" > 4.14.1 I set new limits and it didn't work?< / a >
2003-08-23 17:29:58 +00:00
< / ul >
2002-09-15 02:16:22 +00:00
< li > < a href = "#Section%204.15" > 4.15 Some sensors are doubly detected?< / a >
< li > < a href = "#Section%204.16" > 4.16 I ran sensors-detect, but now I get very strange readings?!?< / a >
< li > < a href = "#Section%204.17" > 4.17 Bad readings from particular chips< / a >
< ul >
< li > < a href = "#Section%204.17" > 4.17.1 Bad readings from the AS99127F!< / a >
< li > < a href = "#Section%204.17" > 4.17.2 Bad readings from the VIA 686A!< / a >
< li > < a href = "#Section%204.17" > 4.17.3 Bad readings from the MTP008!< / a >
< li > < a href = "#Section%204.17" > 4.17.4 Bad temperature readings from the SIS5595!< / a >
< li > < a href = "#Section%204.17" > 4.17.5 Bad readings from a w8378[12]d!< / a >
< li > < a href = "#Section%204.17" > 4.17.6 Bus hangs on Ali 1543 on Asus P5A boards!< / a >
< li > < a href = "#Section%204.17" > 4.17.7 Bad readings from LM75!< / a >
< li > < a href = "#Section%204.17" > 4.17.8 Bad readings from LM78!< / a >
< li > < a href = "#Section%204.17" > 4.17.9 Bad readings from LM80!< / a >
< li > < a href = "#Section%204.17" > 4.17.10 Bad readings from it87!< / a >
2003-08-23 17:29:58 +00:00
< / ul >
2002-09-15 02:16:22 +00:00
< li > < a href = "#Section%204.18" > 4.18 How do I configure two chips (LM87) differently?< / a >
< li > < a href = "#Section%204.19" > 4.19 Dmesg says < code > Upgrade BIOS< / code > ! I don't want to!< / a >
< ul >
< li > < a href = "#Section%204.19" > 4.19.1 Dmesg says < code > use force_addr=0xaddr< / code > ! What address do I use?< / a >
2003-08-23 17:29:58 +00:00
< / ul >
< li > < a href = "#Section%204.20" > 4.20 Sensors says < code > Can't access < code > /proc< / code > file< / code > < / a >
2002-09-15 02:16:22 +00:00
< li > < a href = "#Section%204.21" > 4.21 Sensors says < code > No sensors found!< / code > < / a >
< li > < a href = "#Section%204.22" > 4.22 Sensors output is not correct!< / a >
< li > < a href = "#Section%204.23" > 4.23 What is at I2C address XXX?< / a >
< ul >
< li > < a href = "#Section%204.23" > 4.23.1 What is at I2C address 0x69?< / a >
< li > < a href = "#Section%204.23" > 4.23.2 What is at I2C addresses 0x50 - 0x57?< / a >
< li > < a href = "#Section%204.23" > 4.23.3 What is at I2C addresses 0x30 - 0x37?< / a >
2003-08-23 17:29:58 +00:00
< / ul >
2002-09-15 02:16:22 +00:00
< li > < a href = "#Section%204.24" > 4.24 Sensors-detect doesn't work at all< / a >
< ul >
< li > < a href = "#Section%204.24" > 4.24.1 Sensors-detect says "Couldn't open /proc/bus/i2c?!?"< / a >
< li > < a href = "#Section%204.24" > 4.24.2 Sensors-detect says "Can't open /dev/i2c[-/]0"< / a >
< li > < a href = "#Section%204.24" > 4.24.3 Sensors-detect doesn't find any sensors!< / a >
2003-08-23 17:29:58 +00:00
< / ul >
2002-09-15 02:16:22 +00:00
< li > < a href = "#Section%204.25" > 4.25 Sensors says < code > Error: Line xxx: zzzzzzz< / code > < / a >
< li > < a href = "#Section%204.26" > 4.26 Sensors only gives the name, adapter, and algorithm for my chip< / a >
< li > < a href = "#Section%204.27" > 4.27 Sensors says < code > ERROR: Can't get xxxxx data!< / code > < / a >
< li > < a href = "#Section%204.28" > 4.28 Sensors doesn't find any sensors, just eeproms.< / a >
< li > < a href = "#Section%204.29" > 4.29 Inserting modules hangs my board< / a >
< li > < a href = "#Section%204.30" > 4.30 Inserting modules slows down my board< / a >
< li > < a href = "#Section%204.31" > 4.31 Problems on particular motherboards< / a >
< ul >
< li > < a href = "#Section%204.31" > 4.31.1 Asus P4B< / a >
< li > < a href = "#Section%204.31" > 4.31.2 Tyan 2460, 2462< / a >
< li > < a href = "#Section%204.31" > 4.31.3 Tyan 2466< / a >
< li > < a href = "#Section%204.31" > 4.31.4 Tyan 2688< / a >
2003-08-23 17:29:58 +00:00
< / ul >
2003-04-15 14:47:32 +00:00
< li > < a href = "#Section%204.32" > 4.32 Problems on particular systems< / a >
2003-08-23 17:29:58 +00:00
< / ul >
< li > < a href = "#Help" > 5 How to Ask for Help< / a >
2002-09-15 02:16:22 +00:00
< ul >
< li > < a href = "#Section%205.1" > 5.1 What to send us when asking for help< / a >
< li > < a href = "#Section%205.2" > 5.2 What to do if a module won't insert?< / a >
< li > < a href = "#Section%205.3" > 5.3 What to do if it inserts, but nothing happens?< / a >
< li > < a href = "#Section%205.4" > 5.4 What to do if I read only bogus information?< / a >
< li > < a href = "#Section%205.5" > 5.5 What to do if you have other problems?< / a >
< li > < a href = "#Section%205.6" > 5.6 What if it just works like a charm?< / a >
< li > < a href = "#Section%205.7" > 5.7 How do I update a ticket?< / a >
< li > < a href = "#Section%205.8" > 5.8 How do I follow up on a ticket?< / a >
2003-08-23 17:29:58 +00:00
< / ul >
< li > < a href = "#Contribute" > 6 How to Contribute< / a >
2002-09-15 02:16:22 +00:00
< ul >
< li > < a href = "#Section%206.1" > 6.1 How to write a driver< / a >
< li > < a href = "#Section%206.2" > 6.2 How to get CVS access< / a >
< li > < a href = "#Section%206.3" > 6.3 How to donate hardware to the project< / a >
< li > < a href = "#Section%206.4" > 6.4 How to join the project mailing list< / a >
< li > < a href = "#Section%206.5" > 6.5 How to access mailing list archives< / a >
< li > < a href = "#Section%206.6" > 6.6 How to submit a patch< / a >
< li > < a href = "#Section%206.7" > 6.7 How to REALLY help< / a >
2003-02-17 01:58:10 +00:00
< li > < a href = "#Section%206.8" > 6.8 How to block spam on the project mailing list< / a >
2003-08-23 17:29:58 +00:00
< / ul >
< li > < a href = "#Version%201%20Specifics" > 7 Version 1 Specific Questions< / a >
2002-09-15 02:16:22 +00:00
< ul >
< li > < a href = "#Section%207.1" > 7.1 My manufacturer swears that my mainboard has an SMBus, but your code reports that it can't find it. What's wrong?< / a >
< li > < a href = "#Section%207.2" > 7.2 The modules won't load, saying 'SMBus not detected'.< / a >
< li > < a href = "#Section%207.3" > 7.3 I try to read < code > /proc/sensors< / code > , and I get a "No sensor data yet (try again in a few moments)" message. Why?< / a >
< li > < a href = "#Section%207.4" > 7.4 On my Dell, a LM80 is detected, but all readings are 0!< / a >
2003-08-23 17:29:58 +00:00
< / ul >
< li > < a href = "#Document%20Revisions" > Appendix A Revision History of This Document< / a >
< / ul >
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Top" > Top< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Overview" > Overview< / a > ,
Up:< a rel = up href = "#(dir)" > (dir)< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h1 > lm_sensors< / h1 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The lm_sensors package includes a collection of modules for general SMBus
2002-09-15 02:16:22 +00:00
access and hardware monitoring. NOTE: this requires special support which
is not in standard 2.2-vintage kernels.
2003-08-23 17:29:58 +00:00
< ul >
< li > < a href = "#Overview" > Overview< / a > : PC and Sensor Overview
< li > < a href = "#Basics" > Basics< / a > : Sensor and Bus Basics
< li > < a href = "#Installation" > Installation< / a > : Installation and Management
< li > < a href = "#Problems" > Problems< / a > : Problems
< li > < a href = "#Help" > Help< / a > : How to Ask for Help
< li > < a href = "#Contribute" > Contribute< / a > : How to Contribute
< li > < a href = "#Version%201%20Specifics" > Version 1 Specifics< / a > : Version 1 Specific Questions
< li > < a href = "#Document%20Revisions" > Document Revisions< / a > : Revision History of This Document
2002-09-15 02:16:22 +00:00
< / ul >
< p > < hr >
Node:< a name = "Overview" > Overview< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Basics" > Basics< / a > ,
Previous:< a rel = previous href = "#Top" > Top< / a > ,
Up:< a rel = up href = "#Top" > Top< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h1 > 1 PC and Sensor Overview< / h1 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< ul >
< li > < a href = "#Section%201.1" > Section 1.1< / a > : What sensors are available on my PC?
< li > < a href = "#Section%201.2" > Section 1.2< / a > : What can a sensor chip like the "LM78" do?
< li > < a href = "#Section%201.3" > Section 1.3< / a > : Where do I find out more about any of these chips?
2002-09-15 02:16:22 +00:00
< / ul >
< p > < hr >
Node:< a name = "Section%201.1" > Section 1.1< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%201.2" > Section 1.2< / a > ,
Up:< a rel = up href = "#Overview" > Overview< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 1.1 What sensors are available on my PC?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Most PC's built since late 1997 now come with a
2002-09-15 02:16:22 +00:00
hardware health monitoring chip. This chip may be accessed via the
ISA bus or the SMBus, depending on the motherboard.
2003-08-23 17:29:58 +00:00
< p > Some motherboard chipsets, notably the Via 686 and the SiS 5595,
2002-09-15 02:16:22 +00:00
contain hardware monitor functions.
2003-08-23 17:29:58 +00:00
< p > This FAQ frequently refers to the "LM78". This chip has been
2002-09-15 02:16:22 +00:00
obsoleted by National Semiconductor. Most motherboards today contain
a chip with similar functions.
< p > < hr >
Node:< a name = "Section%201.2" > Section 1.2< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%201.3" > Section 1.3< / a > ,
Previous:< a rel = previous href = "#Section%201.1" > Section 1.1< / a > ,
Up:< a rel = up href = "#Overview" > Overview< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 1.2 What can a sensor chip like the "LM78" do?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The LM78 is a chip made by National Semiconductor which can monitor 7
2002-09-15 02:16:22 +00:00
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.
2003-08-23 17:29:58 +00:00
< p > The LM78 also has 3 fan speed monitoring inputs, an internal
2002-09-15 02:16:22 +00:00
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.
2003-08-23 17:29:58 +00:00
< p > The LM78 can be interfaced to a system via the ISA bus and/or the
2002-09-15 02:16:22 +00:00
SMBus.
2003-08-23 17:29:58 +00:00
< p > Most other sensor chips have comparable functionality. Each supported
2002-09-15 02:16:22 +00:00
chip is documented in the < code > doc/chips< / code > directory.
< p > < hr >
Node:< a name = "Section%201.3" > Section 1.3< / a > ,
2003-08-23 17:29:58 +00:00
Previous:< a rel = previous href = "#Section%201.2" > Section 1.2< / a > ,
Up:< a rel = up href = "#Overview" > Overview< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 1.3 Where do I find out more about any of these chips?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Most semiconductor companies have comprehensive documentation,
2002-09-15 02:16:22 +00:00
including complete datasheets, on their websites. Analog Devices,
Dallas Semiconductor, Maxim, and National Semiconductor have the widest selection
of sensor chips. Their websites are:
2003-08-23 17:29:58 +00:00
< ul >
2002-09-15 02:16:22 +00:00
< li > < a href = "http://www.analog.com" > http://www.analog.com< / a >
< li > < a href = "http://www.dalsemi.com" > http://www.dalsemi.com< / a >
< li > < a href = "http://www.maxim-ic.com" > http://www.maxim-ic.com< / a >
< li > < a href = "http://www.national.com" > http://www.national.com< / a >
< / ul >
2003-08-23 17:29:58 +00:00
< p > Please see the file < a href = "http://www2.lm-sensors.nu/~lm78/useful_addresses.html" > http://www2.lm-sensors.nu/~lm78/useful_addresses.html< / a >
2002-09-15 02:16:22 +00:00
for links to other companies' websites.
< p > < hr >
Node:< a name = "Basics" > Basics< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Installation" > Installation< / a > ,
Previous:< a rel = previous href = "#Overview" > Overview< / a > ,
Up:< a rel = up href = "#Top" > Top< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h1 > 2 Sensor and Bus Basics< / h1 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< ul >
< li > < a href = "#Section%202.1" > Section 2.1< / a > : What sensors are available on my PC?
< li > < a href = "#Section%202.2" > Section 2.2< / a > : What can a sensor chip like the "LM78" do?
< li > < a href = "#Section%202.3" > Section 2.3< / a > : Where do I find out more about any of these chips?
< li > < a href = "#Section%202.4" > Section 2.4< / a > : What sensors are available on my PC?
< li > < a href = "#Section%202.5" > Section 2.5< / a > : What can a sensor chip like the "LM78" do?
< li > < a href = "#Section%202.6" > Section 2.6< / a > : Where do I find out more about any of these chips?
2002-09-15 02:16:22 +00:00
< / ul >
< p > < hr >
Node:< a name = "Section%202.1" > Section 2.1< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%202.2" > Section 2.2< / a > ,
Up:< a rel = up href = "#Basics" > Basics< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 2.1 How are these sensors read?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Sensor chips reside on either the ISA bus, the SMBus, or both.
2002-09-15 02:16:22 +00:00
See the file < code > doc/chips/SUMMARY< / code > in our package for a list.
2003-08-23 17:29:58 +00:00
< p > To communicate with chips on the ISA bus, the software uses
2002-09-15 02:16:22 +00:00
simple I/O reads and writes.
2003-08-23 17:29:58 +00:00
< p > To communicate with chips on the SMBus, the software must
2002-09-15 02:16:22 +00:00
use an SMBus interface device, explained below.
< p > < hr >
Node:< a name = "Section%202.2" > Section 2.2< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%202.3" > Section 2.3< / a > ,
Previous:< a rel = previous href = "#Section%202.1" > Section 2.1< / a > ,
Up:< a rel = up href = "#Basics" > Basics< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 2.2 What is the SMBus? And the I2C bus?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The SMBus is the "System Management Bus". More specifically, it is a
2002-09-15 02:16:22 +00:00
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.
2003-08-23 17:29:58 +00:00
< p > The SMBus (or I2C bus) starts at the host controller, used for
2002-09-15 02:16:22 +00:00
starting transactions on the SMBus. From the host interface, the
devices communicated with are the < dfn > slave< / dfn > devices. Each slave device has a
unique 7-bit address which the host uses to refer to that device.
2003-08-23 17:29:58 +00:00
< p > For each supported SMBus host, there is a separate kernel module
2002-09-15 02:16:22 +00:00
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.
< p > < hr >
Node:< a name = "Section%202.3" > Section 2.3< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%202.4" > Section 2.4< / a > ,
Previous:< a rel = previous href = "#Section%202.2" > Section 2.2< / a > ,
Up:< a rel = up href = "#Basics" > Basics< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 2.3 I don't have an ISA bus!< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > We promise, you do, even if you don't have any old ISA slots.
2002-09-15 02:16:22 +00:00
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 < code > /proc/ioports< / code > 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".
< p > < hr >
Node:< a name = "Section%202.4" > Section 2.4< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%202.5" > Section 2.5< / a > ,
Previous:< a rel = previous href = "#Section%202.3" > Section 2.3< / a > ,
Up:< a rel = up href = "#Basics" > Basics< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 2.4 What sensors do processors have?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Most new processors contain a thermal diode on the die itself.
2002-09-15 02:16:22 +00:00
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 < code > doc/chips/SUMMARY< / code > in our package which
has support for more than one temperature supports external temperature sensing.
2003-08-23 17:29:58 +00:00
< p > Older motherboards and processors without this feature generally use
2002-09-15 02:16:22 +00:00
an LM75 placed close to the processor. This is much less accurate.
2003-08-23 17:29:58 +00:00
< p > The Pentium 2 'boxed' processor usually has an LM75 very close to the
2002-09-15 02:16:22 +00:00
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.
2003-08-23 17:29:58 +00:00
< p > The P6 (Pentium-Pro) may have an LM75 in or just under the socket.
2002-09-15 02:16:22 +00:00
P6's also have VID lines.
2003-08-23 17:29:58 +00:00
< p > Pentiums and Pentium w/ MMX do not have VID lines, and sometimes have
2002-09-15 02:16:22 +00:00
LM75's under the sockets (depends on the mainboard, and how 'modern' the
mainboard is).
2003-08-23 17:29:58 +00:00
< p > The P2 Xeon was the first Intel processor to include the SMBus
2002-09-15 02:16:22 +00:00
interface on the P2 Xeon SEC.
< p > < hr >
Node:< a name = "Section%202.5" > Section 2.5< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%202.6" > Section 2.6< / a > ,
Previous:< a rel = previous href = "#Section%202.4" > Section 2.4< / a > ,
Up:< a rel = up href = "#Basics" > Basics< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 2.5 How often are the sensor values updated?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The LM78, and most other sensor chips like it, reads its sensors one
2002-09-15 02:16:22 +00:00
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.
< p > < hr >
Node:< a name = "Section%202.6" > Section 2.6< / a > ,
2003-08-23 17:29:58 +00:00
Previous:< a rel = previous href = "#Section%202.5" > Section 2.5< / a > ,
Up:< a rel = up href = "#Basics" > Basics< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 2.6 How are alarms triggered?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > It is possible to monitor each sensor and have an alarm go off if
2002-09-15 02:16:22 +00:00
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 < code > /proc/interrupts< / code > .
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.
2003-08-23 17:29:58 +00:00
< p > Even if no interrupt is generated, some bits in a status register
2002-09-15 02:16:22 +00:00
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.
2003-08-23 17:29:58 +00:00
< p > Most drivers in our package do not support interrupts at this time.
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Installation" > Installation< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Problems" > Problems< / a > ,
Previous:< a rel = previous href = "#Basics" > Basics< / a > ,
Up:< a rel = up href = "#Top" > Top< / a >
< br >
< h1 > 3 Installation and Management< / h1 >
< ul >
< li > < a href = "#Section%203.1" > Section 3.1< / a > : Why so many modules, and how do I cope with them?
< li > < a href = "#Section%203.2" > Section 3.2< / a > : How do I know which chips I own?
< li > < a href = "#Section%203.3" > Section 3.3< / a > : Which modules should I insert?
< li > < a href = "#Section%203.4" > Section 3.4< / a > : Do I need the configuration file < code > /etc/sensors.conf< / code > ?
< li > < a href = "#Section%203.5" > Section 3.5< / a > : What about the < code > No such file or directory< / code > warnings
< li > < a href = "#Section%203.6" > Section 3.6< / a > : I get all kinds of weird compilation errors?
< li > < a href = "#Section%203.7" > Section 3.7< / a > : It still does not compile or patch!
< li > < a href = "#Section%203.8" > Section 3.8< / a > : < code > make install< / code > fails on Mandrake kernels
< li > < a href = "#Section%203.9" > Section 3.9< / a > : I get unresolved symbols when I < code > modprobe< / code > modules
2002-09-15 02:16:22 +00:00
< li > < a href = "#Section%203.10" > Section 3.10< / a > : I2C_DRIVERID_ADM1024 undefined (Red Hat especially)
< / ul >
< p > < hr >
Node:< a name = "Section%203.1" > Section 3.1< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%203.2" > Section 3.2< / a > ,
Up:< a rel = up href = "#Installation" > Installation< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 3.1 Why so many modules, and how do I cope with them?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > We tried to make this package as modular as possible. This makes it
2002-09-15 02:16:22 +00:00
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.
2003-08-23 17:29:58 +00:00
< p > Here are two simple guidelines:
< ul >
2002-09-15 02:16:22 +00:00
< li > Run < code > sensors-detect< / code > and do what it tells you.
< li > Always use < code > modprobe< / code > , not < code > insmod< / code > .
< / ul >
2003-08-23 17:29:58 +00:00
< p > Further information is in < code > doc/modules< / code > .
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < a name = "How%20do%20I%20know%20which%20chips%20I%20own" > < / a >
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Section%203.2" > Section 3.2< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%203.3" > Section 3.3< / a > ,
Previous:< a rel = previous href = "#Section%203.1" > Section 3.1< / a > ,
Up:< a rel = up href = "#Installation" > Installation< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 3.2 How do I know which chips I own?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > We have an excellent program that scans all your hardware.
2002-09-15 02:16:22 +00:00
It is called < code > sensors-detect< / code > and is installed in < code > /usr/local/sbin< / code >
by < code > make install< / code > . Just execute this script, and it will tell you.
2003-08-23 17:29:58 +00:00
< p > Chip detection in the drivers is fairly good. That means that it is
2002-09-15 02:16:22 +00:00
usually harmless to insert more chip drivers than you need. However, this
can still lead to problems, so we do not recommend it.
2003-08-23 17:29:58 +00:00
< p > If sensors-detect didn't find any sensors, either you don't have
2002-09-15 02:16:22 +00:00
any, or the ones you have, we don't support. (Look at your motherboard
for candidates, then see < a href = "#Help" > Help< / a > )
2003-08-23 17:29:58 +00:00
< p > < a name = "Section%203.2.1" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 3.2.1 What chips are on motherboard XYZ?< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < strong > !!!!!!!!! YES THIS IS THE MOST FREQUENT QUESTION WE GET !!!!!!!!!< / strong >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > We have no idea. Here is what you should do:
< ol type = 1 start = 1 >
< / p > < li > Run sensors-detect.
< / ol >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > If that doesn't work:
< ol type = 1 start = 2 >
< / p > < li > Look at your motherboard.
2002-09-15 02:16:22 +00:00
< li > Check the manufacturer's website or ask their support
< li > Check the < a href = "http://mbm.livewiredev.com/" > Motherboard Monitor< / a > website and the
< a href = "http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/useful_addresses.html" > "links"< / a >
page on < a href = "http://www2.lm-sensors.nu/~lm78/" > our website< / a > some good cross-references.
2003-08-23 17:29:58 +00:00
< / ol >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < a name = "Section%203.2.2" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 3.2.2 Do you support motherboard XYZ?< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > We don't support boards, we support chips. See < a href = "#Section%203.2.1" > What chips are on motherboard XYZ< / a > .
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < a name = "Section%203.2.3" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 3.2.3 Do you support chip XYZ?< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > This we have good answers for.
< ul >
2002-09-15 02:16:22 +00:00
< li > Sorted by Manufacturer: < code > README< / code >
< li > Sorted by Manufacturer: < a href = "http://www2.lm-sensors.nu/~lm78/supported.html" > http://www2.lm-sensors.nu/~lm78/supported.html< / a >
< li > Sorted by Sensor Driver: < code > doc/chips/SUMMARY< / code >
< li > Newest Driver Status: < a href = "http://www2.lm-sensors.nu/~lm78/newdrivers.html" > http://www2.lm-sensors.nu/~lm78/newdrivers.html< / a >
< / ul >
2003-08-23 17:29:58 +00:00
< p > < a name = "Section%203.2.4" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 3.2.4 Anybody working on a driver for chip XYZ?< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Newest Driver Status: < a href = "http://www2.lm-sensors.nu/~lm78/newdrivers.html" > http://www2.lm-sensors.nu/~lm78/newdrivers.html< / a >
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Section%203.3" > Section 3.3< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%203.4" > Section 3.4< / a > ,
Previous:< a rel = previous href = "#Section%203.2" > Section 3.2< / a > ,
Up:< a rel = up href = "#Installation" > Installation< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 3.3 Which modules should I insert?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < code > sensors-detect< / code > will tell you. Take the < code > modprobe< / code > lines it
2002-09-15 02:16:22 +00:00
recommends and paste them into the appropriate < code > /etc/rc.d/xxxx< / code > file
to be executed at startup.
2003-08-23 17:29:58 +00:00
< p > You need one module for each sensor chip and bus adapter you own;
2002-09-15 02:16:22 +00:00
if there are sensor chips on the ISA bus, you also need < code > i2c-isa.o< / code > .
for each type of chip you own. That's all. On my computer, I could use the
following lines:
2003-08-23 17:29:58 +00:00
< ul >
2002-09-15 02:16:22 +00:00
< li > < code > modprobe i2c-isa< / code >
< li > < code > modprobe i2c-piix4< / code >
< li > < code > modprobe lm78< / code >
< li > < code > modprobe lm75< / code >
< li > < code > modprobe i2c-dev< / code >
< li > < code > sensors -s< / code >
< / ul >
< p > < hr >
Node:< a name = "Section%203.4" > Section 3.4< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%203.5" > Section 3.5< / a > ,
Previous:< a rel = previous href = "#Section%203.3" > Section 3.3< / a > ,
Up:< a rel = up href = "#Installation" > Installation< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 3.4 Do I need the configuration file < code > /etc/sensors.conf< / code > ?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Yes, for any applications that use < code > libsensors,< / code > including the
2002-09-15 02:16:22 +00:00
< code > sensors< / code > 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 < code > /etc/sensors.conf< / code > , but it will not
overwrite any existing file with that name.
2003-08-23 17:29:58 +00:00
< p > < a name = "Section%203.4.1" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 3.4.1 The labels for the voltage and temperature readings in < code > sensors< / code > are incorrect!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Every motherboard is different. You can customize the labels
2002-09-15 02:16:22 +00:00
in the file < code > /etc/sensors.conf< / code > . That's why it exists!
The default labelling (in < code > lib/chips.c< / code > and < code > /etc/sensors.conf< / code > ) is just
a template.
2003-08-23 17:29:58 +00:00
< p > < a name = "Section%203.4.2" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 3.4.2 The min and max for the readings in < code > sensors< / code > are incorrect!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > You can customize them in the file < code > /etc/sensors.conf< / code > . See above.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < a name = "Section%203.4.3" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 3.4.3 The min and max settings in < code > /etc/sensors.conf< / code > didn't take effect!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > You forgot to run < code > sensors -s< / code > . See above.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < a name = "Section%203.4.4" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 3.4.4 One sensor isn't hooked up on my board!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Use an < code > ignore< / code > line in < code > /etc/sensors.conf< / code > so it isn't
2002-09-15 02:16:22 +00:00
displayed in < code > sensors< / code > .
2003-08-23 17:29:58 +00:00
< p > < a name = "Section%203.4.5" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 3.4.5 I need help with < code > sensors.conf< / code > !< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > There is detailed help at the top of that file.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < a name = "Section%203.4.6" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 3.4.6 Do you have a database of < code > sensors.conf< / code > entries for specific boards?< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > No. Good idea though. If you would like to set one up on your website
2002-09-15 02:16:22 +00:00
send us mail and we will set up a link to it.
< p > < hr >
Node:< a name = "Section%203.5" > Section 3.5< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%203.6" > Section 3.6< / a > ,
Previous:< a rel = previous href = "#Section%203.4" > Section 3.4< / a > ,
Up:< a rel = up href = "#Installation" > Installation< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 3.5 What about the < code > No such file or directory< / code > warnings when I compile?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Don't worry about them. The dependency files (which tell which
2002-09-15 02:16:22 +00:00
files should be recompiled when certain files change) are created
dynamically. They are not distributed with the package. The < code > make< / code > program
notices they are not there, and warns about that - and the first thing
it will do is generate them. So all is well.
< p > < hr >
Node:< a name = "Section%203.6" > Section 3.6< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%203.7" > Section 3.7< / a > ,
Previous:< a rel = previous href = "#Section%203.5" > Section 3.5< / a > ,
Up:< a rel = up href = "#Installation" > Installation< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 3.6 I get all kinds of weird compilation errors?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Check that the correct i2c header files are used. Depending on
2002-09-15 02:16:22 +00:00
how you installed, they should be under either < code > /usr/local/include< / code > or
< code > /usr/src/linux*/include< / code > . Try to edit the < code > Makefile< / code > for the other setting.
2003-08-23 17:29:58 +00:00
< p > < a name = "Section%203.6.1" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 3.6.1 < code > No rule to make target xxxx needed by xxxx< / code > - how to fix?< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< ul >
2002-09-15 02:16:22 +00:00
< li > See < a href = "#Section%203.6" > I get all kinds of weird compilation errors< / a > , also try < code > make clean< / code > in < code > lm_sensors< / code > .
< li > If that doesn't work, try < code > make clean< / code > in < code > i2c< / code > .
< li > If that doesn't work, try < code > make clean< / code > in the kernel.
< li > Also make sure < code > /usr/include/linux< / code > points to < code > /usr/src/linux/include/linux< / code > .
< / ul >
< p > < hr >
Node:< a name = "Section%203.7" > Section 3.7< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%203.8" > Section 3.8< / a > ,
Previous:< a rel = previous href = "#Section%203.6" > Section 3.6< / a > ,
Up:< a rel = up href = "#Installation" > Installation< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 3.7 It still does not compile or patch!< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Have you installed the matching version of the i2c package? Remember,
2002-09-15 02:16:22 +00:00
compilation is not enough, you also need to install it for the header
files to be found!
2003-08-23 17:29:58 +00:00
< p > If you want to patch the kernel, you will have to apply the i2c
2002-09-15 02:16:22 +00:00
patches first!
< p > < hr >
Node:< a name = "Section%203.8" > Section 3.8< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%203.9" > Section 3.9< / a > ,
Previous:< a rel = previous href = "#Section%203.7" > Section 3.7< / a > ,
Up:< a rel = up href = "#Installation" > Installation< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 3.8 < code > make install< / code > fails on Mandrake kernels< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Mandrake uses a non-standard < code > version.h< / code > file which confuses our < code > Makefile< / code > .
2002-09-15 02:16:22 +00:00
Edit our < code > Makefile< / code > on the < code > MODDIR :=< / code > line to hard-code the module directory.
< p > < hr >
Node:< a name = "Section%203.9" > Section 3.9< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%203.10" > Section 3.10< / a > ,
Previous:< a rel = previous href = "#Section%203.8" > Section 3.8< / a > ,
Up:< a rel = up href = "#Installation" > Installation< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 3.9 I get unresolved symbols when I < code > modprobe< / code > modules (Red Hat especially)< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Example:
< pre > *** Unresolved symbols in /lib/modules/2.4.5/kernel/drivers/i2c/i2c-i810.o
i2c_bit_add_bus_R8c3bc60e
i2c_bit_del_bus_R92b18f49
< / pre >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > You can also run < code > depmod -a -e< / code > to see all unresolved symbols.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > These are module versioning problems. Generally you did not compile
2002-09-15 02:16:22 +00:00
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 < code > make LINUX=/usr/src/linux-2.4.14< / code > .
2003-08-23 17:29:58 +00:00
< p > Try the following to be sure:
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< ul >
2002-09-15 02:16:22 +00:00
< li > < code > nm --extern MODULE.o< / code >
Filter out the kernel symbols, like < code > kmalloc< / code > , < code > printk< / code > etc. and note the
number code behind them, like < code > printk_R1b7d4074< / code > . If there is no numeric
code after them, note this too.
< li > < code > grep SYMBOL /proc/ksyms< / code >
Substitute SYMBOL by the basename of the symbols above, like < code > kmalloc< / code > ,
< code > printk< / code > etc. Note the number code behind them, or the lack thereof.
< li > 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.
< / ul >
< p > < hr >
Node:< a name = "Section%203.10" > Section 3.10< / a > ,
2003-08-23 17:29:58 +00:00
Previous:< a rel = previous href = "#Section%203.9" > Section 3.9< / a > ,
Up:< a rel = up href = "#Installation" > Installation< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 3.10 I2C_DRIVERID_ADM1024 undefined (Red Hat especially)< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > In some versions of Redhat, an RPM is included to provide i2c support.
2002-09-15 02:16:22 +00:00
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:
2003-08-23 17:29:58 +00:00
< ol type = 1 start = 1 >
< / p > < li > < code > rpm -qa | grep i2c< / code >
2002-09-15 02:16:22 +00:00
< li > Look for < code > kernel-i2c,< / code > or a similar rpm in the output
< li > < as root>
< code > rpm -ev kernel-i2c< / code > (or the name of the similar package)
If this complains about dependencies, you can try adding
< code > --nodeps< / code > , 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.
< li > Try (in the build directory of < code > lm_sensors)< / code >
2003-08-23 17:29:58 +00:00
< pre > < code > make clean< / code >
< code > make< / code >
< / pre >
< li > < em > If< / em > you still have problems, you may have to replace the include
2002-09-15 02:16:22 +00:00
paths in the < code > .c/.h< / code > 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.
2003-08-23 17:29:58 +00:00
< / ol >
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Problems" > Problems< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Help" > Help< / a > ,
Previous:< a rel = previous href = "#Installation" > Installation< / a > ,
Up:< a rel = up href = "#Top" > Top< / a >
< br >
< h1 > 4 Problems< / h1 >
< ul >
< li > < a href = "#Section%204.1" > Section 4.1< / a > : My fans report exactly half/double their values?
< li > < a href = "#Section%204.2" > Section 4.2< / a > : Why do my two LM75's report "-48 degrees"?
< li > < a href = "#Section%204.3" > Section 4.3< / a > : Why do I have two Vcore readings?
< li > < a href = "#Section%204.4" > Section 4.4< / a > : How do those ALARMS work?
< li > < a href = "#Section%204.5" > Section 4.5< / a > : My voltage readings seem to drift a bit. What's wrong?
< li > < a href = "#Section%204.6" > Section 4.6< / a > : Some measurements are way out of range. What happened?
< li > < a href = "#Section%204.7" > Section 4.7< / a > : What are VID lines? Why is the VID reading wrong?
< li > < a href = "#Section%204.8" > Section 4.8< / a > : Sensor are only updated each second or so. Why?
< li > < a href = "#Section%204.9" > Section 4.9< / a > : It takes a second before reading sensor results. Why?
2002-09-15 02:16:22 +00:00
< li > < a href = "#Section%204.10" > Section 4.10< / a > : Can I be alerted when an ALARM occurs?
< li > < a href = "#Section%204.11" > Section 4.11< / a > : SMBus transactions on my PIIX4 simply don't work. Why?
< li > < a href = "#Section%204.12" > Section 4.12< / a > : My BIOS reports a higher CPU temperature than you!
< li > < a href = "#Section%204.13" > Section 4.13< / a > : I read strange values from the raw < code > /proc< / code > files!
< li > < a href = "#Section%204.14" > Section 4.14< / a > : How do I set new limits?
< li > < a href = "#Section%204.15" > Section 4.15< / a > : Some sensors are doubly detected?
< li > < a href = "#Section%204.16" > Section 4.16< / a > : I ran sensors-detect, but now I get strange readings?!
< li > < a href = "#Section%204.17" > Section 4.17< / a > : Bad readings from particular chips
< li > < a href = "#Section%204.18" > Section 4.18< / a > : How do I configure two chips (LM87) differently?
< li > < a href = "#Section%204.19" > Section 4.19< / a > : Dmesg says < code > Upgrade BIOS< / code > ! I don't want to!
2003-08-23 17:29:58 +00:00
< li > < a href = "#Section%204.20" > Section 4.20< / a > : Sensors says < code > Can't access < code > /proc< / code > file< / code >
2002-09-15 02:16:22 +00:00
< li > < a href = "#Section%204.21" > Section 4.21< / a > : Sensors says < code > No sensors found!< / code >
< li > < a href = "#Section%204.22" > Section 4.22< / a > : Sensors output is not correct!
< li > < a href = "#Section%204.23" > Section 4.23< / a > : What is at I2C address XXX?
< li > < a href = "#Section%204.24" > Section 4.24< / a > : Sensors-detect doesn't work at all
< li > < a href = "#Section%204.25" > Section 4.25< / a > : Sensors says < code > Error: Line xxx: zzzzzzz< / code >
< li > < a href = "#Section%204.26" > Section 4.26< / a > : Sensors only gives the name, adapter, and algorithm!
< li > < a href = "#Section%204.27" > Section 4.27< / a > : Sensors says < code > ERROR: Can't get xxxxx data!< / code >
< li > < a href = "#Section%204.28" > Section 4.28< / a > : Sensors doesn't find any sensors, just eeproms.
< li > < a href = "#Section%204.29" > Section 4.29< / a > : Inserting modules hangs my board
< li > < a href = "#Section%204.30" > Section 4.30< / a > : Inserting modules slows down my board
< li > < a href = "#Section%204.31" > Section 4.31< / a > : Problems on particular motherboards
2003-04-15 14:47:32 +00:00
< li > < a href = "#Section%204.32" > Section 4.32< / a > : Problems on particular systems
2002-09-15 02:16:22 +00:00
< / ul >
< p > < hr >
Node:< a name = "Section%204.1" > Section 4.1< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.2" > Section 4.2< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.1 My fans report exactly half/double their values compared to the BIOS?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The problem with much of the sensor data is that it is impossible to
2002-09-15 02:16:22 +00:00
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 < code > /etc/sensors.conf< / code > :
2003-08-23 17:29:58 +00:00
< pre > 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
< / pre >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > See < code > doc/fan-divisors< / code > in our package for further information.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < a name = "Fans%20sometimes%2falways%20read%200!" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.1.1 Fans sometimes/always read 0!!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > You may not have a three-wire fan, which is required.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > You may need to increase the 'fan divisor'. See < code > doc/fan-divisors< / code >
2002-09-15 02:16:22 +00:00
in our package for further information.
2003-08-23 17:29:58 +00:00
< p > < a name = "I%20doubled%20the%20fan%20divisor%20and%20the%20fan%20still%20reads%207000" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.1.2 I doubled the fan divisor and the fan still reads 7000!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Believe it or not, doubling the 'fan divisor' will not halve
2002-09-15 02:16:22 +00:00
the fan reading. You have to add a compute line in < code > /etc/sensors.conf< / code > .
See < a href = "#Section%204.1" > My fans report exactly half/double their values compared to the BIOS< / a > ,
and see < code > doc/fan-divisors< / code > in our package for further information.
< p > < hr >
Node:< a name = "Section%204.2" > Section 4.2< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.3" > Section 4.3< / a > ,
Previous:< a rel = previous href = "#Section%204.1" > Section 4.1< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.2 Why do my two LM75's report "-48 degrees"?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > For starters, those aren't LM75's. Your mainboard actually has the
2002-09-15 02:16:22 +00:00
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.
2003-08-23 17:29:58 +00:00
< p > If you have an Asus P2B and want more information on adding thermal sensing capability, check out:
2002-09-15 02:16:22 +00:00
< a href = "http://ultimatepc.fsn.net/techinfo/p2bthermistor/p2bthermistor.htm" > http://ultimatepc.fsn.net/techinfo/p2bthermistor/p2bthermistor.htm< / a >
2003-08-23 17:29:58 +00:00
< p > In upcoming versions, you will be able to disable non-interesting
2002-09-15 02:16:22 +00:00
readings.
< p > < hr >
Node:< a name = "Section%204.3" > Section 4.3< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.4" > Section 4.4< / a > ,
Previous:< a rel = previous href = "#Section%204.2" > Section 4.2< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.3 Why do I have two Vcore readings, I have only one processor!< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The LM78 has seven voltage sensors. The default way of
2002-09-15 02:16:22 +00:00
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 < code > ignore< / code > line.
2003-08-23 17:29:58 +00:00
< p > Note that Vcore2 is often the same as Vcore on motherboards which
2002-09-15 02:16:22 +00:00
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.
< p > < hr >
Node:< a name = "Section%204.4" > Section 4.4< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.5" > Section 4.5< / a > ,
Previous:< a rel = previous href = "#Section%204.3" > Section 4.3< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.4 How do those ALARMS work? The current value is within range but there is still an ALARM warning!< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The ALARM indications in < code > sensors< / code > are those reported by the
2002-09-15 02:16:22 +00:00
sensor chip itself. They are NOT calculated by < code > sensors< / code > . < code > sensors< / code >
simply reads the ALARM bits and reports them.
2003-08-23 17:29:58 +00:00
< p > An ALARM will go off when a minimum or maximum limit is crossed.
2002-09-15 02:16:22 +00:00
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.
2003-08-23 17:29:58 +00:00
< p > Reading the registers clears the ALARMS, unless the current
2002-09-15 02:16:22 +00:00
value is still out of range.
2003-08-23 17:29:58 +00:00
< p > The purpose of this scheme is to tell you if there has been
2002-09-15 02:16:22 +00:00
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 < code > doc/chips< / code > and the
chip datasheet for more information.
< p > < hr >
Node:< a name = "Section%204.5" > Section 4.5< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.6" > Section 4.6< / a > ,
Previous:< a rel = previous href = "#Section%204.4" > Section 4.4< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.5 My voltage readings seem to drift a bit. Is something wrong?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > No, probably not. If your motherboard heats up a bit, the sensed
2002-09-15 02:16:22 +00:00
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.
< p > < hr >
Node:< a name = "Section%204.6" > Section 4.6< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.7" > Section 4.7< / a > ,
Previous:< a rel = previous href = "#Section%204.5" > Section 4.5< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.6 Some measurements are way out of range. What happened?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Each module tries to set limits to sensible values on initialization,
2002-09-15 02:16:22 +00:00
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.
2003-08-23 17:29:58 +00:00
< p > Readings can also be strange; there are several reasons for this.
2002-09-15 02:16:22 +00:00
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.
< p > < hr >
Node:< a name = "Section%204.7" > Section 4.7< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.8" > Section 4.8< / a > ,
Previous:< a rel = previous href = "#Section%204.6" > Section 4.6< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.7 What are VID lines? Why is the VID reading wrong?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > These describe the core voltage for your processor. They are
2002-09-15 02:16:22 +00:00
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 < code > ignore vid< / code > to < code > /etc/sensors.conf< / code > ,
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.
< p > < hr >
Node:< a name = "Section%204.8" > Section 4.8< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.9" > Section 4.9< / a > ,
Previous:< a rel = previous href = "#Section%204.7" > Section 4.7< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.8 I read sensor values several times a second, but they are only updated only each second or so. Why?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > If we would read the registers more often, it would not find the
2002-09-15 02:16:22 +00:00
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).
< p > < hr >
Node:< a name = "Section%204.9" > Section 4.9< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.10" > Section 4.10< / a > ,
Previous:< a rel = previous href = "#Section%204.8" > Section 4.8< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.9 It sometimes seems to take almost a second before I see the sensor reading results. Why?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > ISA bus access is fast, but SMBus access is really slow. If you have
2002-09-15 02:16:22 +00:00
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.
< p > < hr >
Node:< a name = "Section%204.10" > Section 4.10< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.11" > Section 4.11< / a > ,
Previous:< a rel = previous href = "#Section%204.9" > Section 4.9< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.10 Can I be alerted when an ALARM occurs?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > No, you can't; and it may well be never supported.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Almost no mainboard we have encountered have actually connected the
2002-09-15 02:16:22 +00:00
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.
2003-08-23 17:29:58 +00:00
< p > The SMI interrupt is only available on a few types of chips. It is
2002-09-15 02:16:22 +00:00
really a very obscure way to handle interrupts, and supporting it under Linux
might be quite hard to do.
2003-08-23 17:29:58 +00:00
< p > Your best bet would be to poll the alarm file with a user-land daemon
2002-09-15 02:16:22 +00:00
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 < a href = "http://www2.lm-sensors.nu/~lm78/useful_addresses.html" > http://www2.lm-sensors.nu/~lm78/useful_addresses.html< / a > for addresses.
< p > < hr >
Node:< a name = "Section%204.11" > Section 4.11< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.12" > Section 4.12< / a > ,
Previous:< a rel = previous href = "#Section%204.10" > Section 4.10< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.11 SMBus transactions on my PIIX4 simply don't work (timeouts happen). Why?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Some chips which mainboard makers connect to the SMBus are not SMBus
2002-09-15 02:16:22 +00:00
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.
2003-08-23 17:29:58 +00:00
< p > Why did they connect these devices to the SMBus if they aren't
2002-09-15 02:16:22 +00:00
compatible? Good question! :') Actually, these devices may support being
written to, but lock things up when they are read.
< p > < hr >
Node:< a name = "Section%204.12" > Section 4.12< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.13" > Section 4.13< / a > ,
Previous:< a rel = previous href = "#Section%204.11" > Section 4.11< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.12 My BIOS reports a much higher CPU temperature than your modules!< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > We display the actual temperature of the sensor. This may not be the
2002-09-15 02:16:22 +00:00
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 is just somewhere near it. 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:
2003-08-23 17:29:58 +00:00
< pre > chip lm75-*-49 # Or whatever chip this relates to
label temp "Processor"
compute temp @*1.2+13,(@-13)/1.2 # Or whatever formula
< / pre >
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Section%204.13" > Section 4.13< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.14" > Section 4.14< / a > ,
Previous:< a rel = previous href = "#Section%204.12" > Section 4.12< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.13 I try to read the raw < code > /proc< / code > files, but the values are strange?!?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Remember, these values do not take the configuration file
2002-09-15 02:16:22 +00:00
< code > compute< / code > lines in account. This is especially obvious for voltage readings
(usually called in? or vin?). Use a program linked to libsensors (like
the provided < code > sensors< / code > program) instead.
< p > < hr >
Node:< a name = "Section%204.14" > Section 4.14< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.15" > Section 4.15< / a > ,
Previous:< a rel = previous href = "#Section%204.13" > Section 4.13< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.14 How do I set new limits?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Change the limit values in < code > /etc/sensors.conf< / code > and then run
2002-09-15 02:16:22 +00:00
< code > sensors -s< / code > .
2003-08-23 17:29:58 +00:00
< p > < a name = "I%20set%20new%20limits%20and%20it%20didnt%20work" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.14.1 I set new limits and it didn't work?< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > You forgot to run < code > sensors -s< / code > . Put it in a < code > /etc/rc.d/...< / code > file
2002-09-15 02:16:22 +00:00
after the modprobe lines to run at startup.
< p > < hr >
Node:< a name = "Section%204.15" > Section 4.15< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.16" > Section 4.16< / a > ,
Previous:< a rel = previous href = "#Section%204.14" > Section 4.14< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.15 Some sensors are doubly detected?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Yes, this is still a problem. It is partially solved by alias detection
2002-09-15 02:16:22 +00:00
and confidence values in sensors-detect, but it is really tough.
2003-08-23 17:29:58 +00:00
< p > Double detections can be caused by two things:
2002-09-15 02:16:22 +00:00
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 < code > ignore=< / code > modprobe parameters it suggests.
< p > < hr >
Node:< a name = "Section%204.16" > Section 4.16< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.17" > Section 4.17< / a > ,
Previous:< a rel = previous href = "#Section%204.15" > Section 4.15< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.16 I ran sensors-detect, but now I get very strange readings?!?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Your SMBus (PIIX4?) is probably crashed or hung. There are some mainboards
2002-09-15 02:16:22 +00:00
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< / kbd > when you are asked whether you want to
scan the PIIX4.
< p > < hr >
Node:< a name = "Section%204.17" > Section 4.17< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.18" > Section 4.18< / a > ,
Previous:< a rel = previous href = "#Section%204.16" > Section 4.16< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.17 Bad readings from particular chips< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > See below for some particularly troublesome chips.
2002-09-15 02:16:22 +00:00
Also be sure and check < code > doc/chips/xxxxx< / code > for the particular driver.
2003-08-23 17:29:58 +00:00
< p > < a name = "Bad%20readings%20from%20the%20AS99127F" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.17.1 Bad readings from the AS99127F!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The Asus AS99127F is a modified version of the Winbond W83781D.
2002-09-15 02:16:22 +00:00
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 < code > /etc/sensors.conf.< / code > Please don't ask us to
fix the driver. Ask Asus to release a datasheet.
2003-08-23 17:29:58 +00:00
< p > < a name = "Bad%20readings%20from%20the%20VIA%20686A" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.17.2 Bad readings from the VIA 686A!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The Via 686A datasheet is incomplete.
2002-09-15 02:16:22 +00:00
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 < code > /etc/sensors.conf.< / code > Please don't ask us to
fix the driver. Ask Via to release a better datasheet.
Also, don't forget to < code > modprobe i2c-isa< / code > .
2003-08-23 17:29:58 +00:00
< p > < a name = "Bad%20readings%20from%20the%20MTP008" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.17.3 Bad readings from the MTP008!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The MTP008 has programmable temperature sensor types.
2002-09-15 02:16:22 +00:00
If your sensor type does not match the default, you will have to change it.
See < code > doc/chips/mtp008< / code > for details.
Also, MTP008 chips seem to randomly refuse to respond, for
unknown reasons. You can see this as 'XX' entries in i2cdump.
2003-08-23 17:29:58 +00:00
< p > < a name = "Bad%20temperature%20readings%20from%20the%20SIS5595" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.17.4 Bad temperature readings from the SIS5595!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > This chip can use multiple thermistor types and there are also
2002-09-15 02:16:22 +00:00
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.
2003-08-23 17:29:58 +00:00
< p > < a name = "Bad%20readings%20from%20a%20w8378%5b12%5dd" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.17.5 Bad readings from a w8378[12]d!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Do you own an ASUS motherboard? Perhaps your chip is being
2002-09-15 02:16:22 +00:00
misidentified. Look on the motherboard (or at
< a href = "http://mbm.livewiredev.com" > http://mbm.livewiredev.com< / a > ) 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
< code > force_as99127f=BUS,0x2d< / code > where < code > BUS< / code > is your i2c bus number.
Cat /proc/bus/i2c to see a list of bus numbers.
Read the w83781d module documentation (< code > doc/chips/w83781d< / code > )
for more details.
2003-08-23 17:29:58 +00:00
< p > < a name = "Bus%20hangs%20on%20Ali%201543%20on%20Asus%20P5A%20boards" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.17.6 Bus hangs on Ali 1543 on Asus P5A boards!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The SMBus tends to hang on this board and it seems to get worse
2002-09-15 02:16:22 +00:00
at higher temperatures. Use ISA accesses to reliably use the w83781d
monitor chip on this board and use the < code > ignore=1,0x2d< / code > or similar option
to the w83781d module to prevent i2c accesses.
2003-08-23 17:29:58 +00:00
< p > < a name = "Bad%20readings%20from%20LM75" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.17.7 Bad readings from LM75!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The LM75 detection is poor and other hardware is often misdetected
2002-09-15 02:16:22 +00:00
as an LM75. Figure out what you really have See < a href = "#Section%203.2.1" > What chips are on motherboard XYZ< / a > .
2003-08-23 17:29:58 +00:00
< p > < a name = "Bad%20readings%20from%20LM78" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.17.8 Bad readings from LM78!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The LM78 is no longer manufactured by National Semiconductor.
2002-09-15 02:16:22 +00:00
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 < a href = "#Section%203.2.1" > What chips are on motherboard XYZ< / a > .
2003-08-23 17:29:58 +00:00
< p > < a name = "Bad%20readings%20from%20LM80" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.17.9 Bad readings from LM80!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The LM80 detection is poor and other hardware is often misdetected
2002-09-15 02:16:22 +00:00
as an LM80. Figure out what you really have See < a href = "#Section%203.2.1" > What chips are on motherboard XYZ< / a > .
2003-08-23 17:29:58 +00:00
< p > < a name = "Bad%20readings%20from%20it87" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.17.10 Bad readings from it87!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The it87 temperature sesnsors are configured, unfortunately,
2002-09-15 02:16:22 +00:00
in a way different from w83781d. They cannot be configured from
< code > /etc/sensors.conf< / code > ; they must be set at modprobe insertion with
< code > modprobe it87 temp_type=0xXX< / code > . See < code > doc/chips/it87< / code > for details.
< p > < hr >
Node:< a name = "Section%204.18" > Section 4.18< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.19" > Section 4.19< / a > ,
Previous:< a rel = previous href = "#Section%204.17" > Section 4.17< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.18 How do I configure two chips (LM87) differently?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > There is a SuperMicro board with two LM87's on it that are
2002-09-15 02:16:22 +00:00
not hooked up in the same way, so they need different defaults.
For example, both CPU temperatures go to one LM87.
2003-08-23 17:29:58 +00:00
< p > Make two different sections in < code > /etc/sensors.conf< / code > as follows:
< pre > chip "lm87-i2c-*-2c"
put configuration for the chip at 0x2c here
chip "lm87-i2c-*-2d"
put configuration for the chip at 0x2d here
< / pre >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > There is a commented example in < code > sensors.conf.eg< / code > which should
2002-09-15 02:16:22 +00:00
be helpful.
< p > < hr >
Node:< a name = "Section%204.19" > Section 4.19< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.20" > Section 4.20< / a > ,
Previous:< a rel = previous href = "#Section%204.18" > Section 4.18< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.19 Dmesg says < code > Upgrade BIOS< / code > ! I don't want to!< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > If the problem is a PCI device is not present in < code > lspci< / code > , the solution
2002-09-15 02:16:22 +00:00
is complex. For the ALI M7101 device, there is a solution which uses the
2.4 kernel's < code > hotplug< / code > facility. See < code > prog/hotplug< / code > in our package.
For other PCI devices, you can try to modify
the m7101 solution in < code > prog/hotplug< / code > .
2003-08-23 17:29:58 +00:00
< p > If dmesg says < code > try force_addr< / code > , see below. Other drivers generally do not
2002-09-15 02:16:22 +00:00
support the force_addr parameter. Sorry. Check the documentation
for your driver in < code > doc/[chips,busses]< / code > and if we don't support it
you can send us your request.
2003-08-23 17:29:58 +00:00
< p > < a name = "Dmesg%20says%20use%20force_addr%3d0xaddr!%20What%20address%20do%20I%20use" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.19.1 Dmesg says < code > use force_addr=0xaddr< / code > ! What address do I use?< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > If the problem is a PCI device whose base address is not set,
2002-09-15 02:16:22 +00:00
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
< code > modprobe via686a force_addr=0xADDRESS< / code > where ADDRESS
is the I/O address. You must select an address that is not in use.
2003-08-23 17:29:58 +00:00
< code > cat < code > /proc/ioports< / code > < / code > to check (carefully) for conflicts. A high number like
2002-09-15 02:16:22 +00:00
0xf000 is generally safe.
< p > < hr >
Node:< a name = "Section%204.20" > Section 4.20< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.21" > Section 4.21< / a > ,
Previous:< a rel = previous href = "#Section%204.19" > Section 4.19< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.20 Sensors says < code > Can't access < code > /proc< / code > file< / code > < / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< ul >
2002-09-15 02:16:22 +00:00
< li > (release 2.6.0 and later) Did you < code > modprobe i2c-proc< / code > ? Check < code > lsmod< / code > .
< li > (release 2.5.5 and earlier) Did you 'modprobe sensors'? Check 'lsmod'.
< li > If you did < code > sensors -s< / code > , did you run it as root?
< li > Do you have < code > /proc< / code > support in your kernel (is < code > /proc< / code > there?)
< / ul >
< p > < hr >
Node:< a name = "Section%204.21" > Section 4.21< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.22" > Section 4.22< / a > ,
Previous:< a rel = previous href = "#Section%204.20" > Section 4.20< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.21 Sensors says < code > No sensors found!< / code > < / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< ul >
2002-09-15 02:16:22 +00:00
< li > Did < code > sensors-detect< / code > find sensors? (If not see < a href = "#Sensors-detect%20doesnt%20find%20any%20sensors" > Sensors-detect doesnt find any sensors< / a > )
< li > Did you do what < code > sensors-detect< / code > said?
< li > Did you < code > modprobe< / code > your sensor modules?
< li > Did you < code > modprobe< / code > your I2C adapter modules?
< li > Did you < code > modprobe i2c-isa< / code > if you have ISA sensor chips?
< li > Check < code > lsmod< / code > .
< / ul >
< p > < hr >
Node:< a name = "Section%204.22" > Section 4.22< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.23" > Section 4.23< / a > ,
Previous:< a rel = previous href = "#Section%204.21" > Section 4.21< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.22 Sensors output is not correct!< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > What specifically is the trouble?
< ul >
2002-09-15 02:16:22 +00:00
< li > Labels: See < a href = "#Section%203.4.1" > The labels for the voltage and temperature readings in sensors are incorrect< / a > .
< li > Min/max readings: See < a href = "#Section%203.4.2" > The min and max for the readings in sensors are incorrect< / a > , and See < a href = "#Section%203.4.3" > The min and max settings didnt take effect< / a > .
< li > AS99127F: See < a href = "#Section%204.16" > I ran sensors-detect but now I get very strange readings?< / a > .
< li > Via 686A: See < a href = "#Section%204.16" > I ran sensors-detect but now I get very strange readings?< / a > .
< li > Other specific chips: See < a href = "#Section%204.16" > I ran sensors-detect but now I get very strange readings?< / a > .
< li > No output for a particular sensors chip: See < a href = "#Section%205.3" > What to do if it inserts but nothing happens< / a > .
< li > No output at all: See < a href = "#Section%204.21" > Sensors says No sensors found< / a > , See < a href = "#Section%205.3" > What to do if it inserts but nothing happens< / a > .
< li > Completely bad output for a particular sensor chip: See < a href = "#Section%205.4" > What to do if I read only bogus information< / a > .
< li > One particular sensor readings:
2003-08-23 17:29:58 +00:00
< ul >
2002-09-15 02:16:22 +00:00
< li > Maybe it isn't hooked up? - tell 'sensors' to ignore it. See < a href = "#Section%203.4.4" > One sensor isnt hooked up on my board< / a > .
< li > Maybe it is hooked up differently on your motherboard? - adjust < code > sensors.conf< / code > calculation.
< / ul >
2003-08-23 17:29:58 +00:00
< / ul >
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Section%204.23" > Section 4.23< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.24" > Section 4.24< / a > ,
Previous:< a rel = previous href = "#Section%204.22" > Section 4.22< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.23 What is at I2C address XXX?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > In general, we don't know. Start by running < code > sensors-detect< / code > .
2002-09-15 02:16:22 +00:00
If it doesn't recognize it, try running < code > i2cdump< / code > . A partial list
of manufacturers' IDs are at the bottom of < code > doc/chips/SUMMARY< / code > .
2003-08-23 17:29:58 +00:00
< p > < a name = "What%20is%20at%20I2C%20address%200x69" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.23.1 What is at I2C address 0x69?< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > A clock chip. Often, accessing these clock chips in the wrong
2002-09-15 02:16:22 +00:00
way will instantly crash your computer. Sensors-detect carefully
avoids these chips. If you really really want to play with your clock
chip you can look at < code > kernel/chips/icspll.c< / code > in our package. But we
do not recommend it. You have been warned.
2003-08-23 17:29:58 +00:00
< p > < a name = "What%20is%20at%20I2C%20addresses%200x50%20-%200x57" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.23.2 What is at I2C addresses 0x50 - 0x57?< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > EEPROMs on your SDRAM DIMMs. Load the eeprom module to
2002-09-15 02:16:22 +00:00
look at some basic data in < code > sensors< / code > or use the program
< code > prog/eeprom/decode-dimms.pl< / code > to get more information than you ever wanted.
2003-08-23 17:29:58 +00:00
< p > < a name = "What%20is%20at%20I2C%20addresses%200x30%20-%200x37" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.23.3 What is at I2C addresses 0x30 - 0x37?< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > These are often 'shadows' of your EEPROMs on your SDRAM DIMMs
2002-09-15 02:16:22 +00:00
at addresses 0x50 - 0x57. They aren't really there. If you try and
do a < code > i2cdump< / code > on them you won't get anything. This is probably
caused by some timing problem on your motherboard or on the DIMMs.
We don't know the exact cause.
< p > < hr >
Node:< a name = "Section%204.24" > Section 4.24< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.25" > Section 4.25< / a > ,
Previous:< a rel = previous href = "#Section%204.23" > Section 4.23< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.24 Sensors-detect doesn't work at all< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > It could be many things. What was the problem? See < a href = "#Section%204.31" > Problems on particular motherboards< / a > .
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < a name = "Sensors-detect%20says%20%22Couldnt%20open%20%2fproc%2fbus%2fi2c%3f!%3f%22" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.24.1 Sensors-detect says "Couldn't open /proc/bus/i2c?!?"< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > You don't have i2c support in your kernel, or the i2c-core module
2002-09-15 02:16:22 +00:00
was not loaded and you did not run sensors-detect as root.
2003-08-23 17:29:58 +00:00
< p > < a name = "Sensors-detect%20says%20%22Cant%20open%20%2fdev%2fi2c%5b-%2f%5d0%22" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.24.2 Sensors-detect says "Can't open /dev/i2c[-/]0"< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Your < code > /dev/i2c-0,< / code > < code > /dev/i2c0< / code > , or < code > /dev/i2c/0< / code > files do not exist
2002-09-15 02:16:22 +00:00
or you did not run < code > sensors-detect< / code > as root.
Run the script < code > prog/mkdev/mkdev.sh< / code > to create the < code > /dev/i2c-x< / code > files.
Run < code > devfs< / code > in the kernel to get the < code > /dev/i2c/x< / code > files.
2003-08-23 17:29:58 +00:00
< p > < a name = "Sensors-detect%20doesnt%20find%20any%20sensors" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.24.3 Sensors-detect doesn't find any sensors!< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Either
< ol type = 1 start = 1 >
< / p > < li > The board doesn't have any sensors.
2002-09-15 02:16:22 +00:00
< li > We don't support the sensors on the board.
< li > The sensors it has are on an I2C bus connected to an I2C bus adapter that we don't support.
< li > You don't have the latest version of lm_sensors.
2003-08-23 17:29:58 +00:00
< / ol >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > But in any case you should figure out what is on the board:
< ol type = 1 start = 1 >
< / p > < li > Look at your motherboard.
2002-09-15 02:16:22 +00:00
< li > Check the manufacturer's website.
< li > Check the < a href = "http://mbm.livewiredev.com/" > Motherboard Monitor< / a > website.
2003-08-23 17:29:58 +00:00
< / ol >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > When you know what chips you have, check the
2002-09-15 02:16:22 +00:00
< a href = "http://www2.lm-sensors.nu/~lm78/newdrivers.html" > Newest Driver Status< / a > web page to
see if support has been added for your chip in a later release or in CVS.
< p > < hr >
Node:< a name = "Section%204.25" > Section 4.25< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.26" > Section 4.26< / a > ,
Previous:< a rel = previous href = "#Section%204.24" > Section 4.24< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.25 Sensors says < code > Error: Line xxx: zzzzzzz< / code > < / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > These are errors from the libsensors library in
2002-09-15 02:16:22 +00:00
reading the < code > /etc/sensors.conf< / code > 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.
< p > < hr >
Node:< a name = "Section%204.26" > Section 4.26< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.27" > Section 4.27< / a > ,
Previous:< a rel = previous href = "#Section%204.25" > Section 4.25< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.26 Sensors only gives the name, adapter, and algorithm for my chip< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > If < code > sensors< / code > only says this, for example, and doesn't
2002-09-15 02:16:22 +00:00
provide any actual data at all:
2003-08-23 17:29:58 +00:00
< pre > it87-isa-0290
Adapter: ISA adapter
Algorithm: ISA algorithm
< / pre >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Your chip is not currently supported by < code > sensors< / code > and so all it
2002-09-15 02:16:22 +00:00
does is print out that information. Get the latest release
and be sure you are running the < code > sensors< / code > program it installed
and not some older < code > sensors< / code > .
< p > < hr >
Node:< a name = "Section%204.27" > Section 4.27< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.28" > Section 4.28< / a > ,
Previous:< a rel = previous href = "#Section%204.26" > Section 4.26< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.27 Sensors says < code > ERROR: Can't get xxxxx data!< / code > < / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > You have a < code > libsensors/sensors< / code > mismatch. < code > sensors< / code > is unable to
2002-09-15 02:16:22 +00:00
get a data entry from < code > libsensors< / code > . You probably have an
old < code > libsensors< / code > in your < code > /etc/ld.so.conf< / code > path.
Make sure you did (as root) a < code > make install< / code > followed by a < code > ldconfig< / code > .
Then check the output of < code > ldconfig -v | grep libsensors< / code > to
verify that there is only ONE < code > libsensors< / code > entry and that it matches
the < code > libsensors< / code > that was built in the < code > lib/< / code > directory in < code > lm_sensors2< / code > .
< p > < hr >
Node:< a name = "Section%204.28" > Section 4.28< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.29" > Section 4.29< / a > ,
Previous:< a rel = previous href = "#Section%204.27" > Section 4.27< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.28 Sensors doesn't find any sensors, just eeproms.< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > See < a href = "#Section%204.24" > Sensors-detect doesnt work at all< / a > , if < code > sensors-detect< / code > failed to find any sensors.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > If < code > sensors-detect< / code > did find sensors, did you insert your modules? For chips on the ISA
2002-09-15 02:16:22 +00:00
bus, did you insert i2c-isa?
2003-08-23 17:29:58 +00:00
< p > See < a href = "#Section%205.2" > What to do if a module wont insert< / a > , if the modules didn't insert,
2002-09-15 02:16:22 +00:00
also < a href = "#Section%204.21" > Sensors says No sensors found< / a > .
< p > < hr >
Node:< a name = "Section%204.29" > Section 4.29< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.30" > Section 4.30< / a > ,
Previous:< a rel = previous href = "#Section%204.28" > Section 4.28< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.29 Inserting modules hangs my board< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > There are several possible causes:
< ol type = 1 start = 1 >
< / p > < li > Bus driver problems. Insert the bus driver first, before you have inserted any chip drivers, to verify.
2002-09-15 02:16:22 +00:00
< li > Wrong chip driver. Verify that you have a chip supported by the chip driver, see < a href = "#Section%203.2.1" > What chips are on motherboard XYZ< / a > .
< li > The chip driver is reinitializing the chip, which undoes critical initialization done by the BIOS. Try the parameter < code > init=0< / code > for the w83781d driver; this is the only driver supporting this parameter.
< li > Some chips on the bus don't like to be probed at all. After inserting the bus driver (but not the chip drivers), run < code > i2cdetect< / code > on the bus, then < code > i2cdump< / code > on each address responding to < code > i2cdetect< / code > . This may find the culprit. Do not < code > i2cdump address 0x69< / code > , the clock chip.
< li > 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 < code > modprobe ignore_range=0,0x00,0x28,0,0x2a,0x7f< / code > to prevent access to other addresses. (< code > init=0< / code > also req'd for the Tyan 2688).
2003-08-23 17:29:58 +00:00
< / ol >
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Section%204.30" > Section 4.30< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.31" > Section 4.31< / a > ,
Previous:< a rel = previous href = "#Section%204.29" > Section 4.29< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.30 Inserting modules slows down my board< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Generally this is caused by an overtemperature alarm output from
2002-09-15 02:16:22 +00:00
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 < code > /etc/sensors.conf< / code > and run < code > sensors -s< / code > .
< p > < hr >
Node:< a name = "Section%204.31" > Section 4.31< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%204.32" > Section 4.32< / a > ,
Previous:< a rel = previous href = "#Section%204.30" > Section 4.30< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.31 Problems on particular motherboards< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The following boards have unique problems and solutions.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < a name = "Asus%20P4B" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.31.1 Asus P4B< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > See < code > prog/hotplug/README.p4b< / code > if your SMBus master is not found.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < a name = "Tyan%202460%202462" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.31.2 Tyan 2460, 2462< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > See support tickets 805, 765, 781, 812, 813, and 867 for information.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < a name = "Tyan%202466" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.31.3 Tyan 2466< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > See support tickets 941, 840, and 841 for information.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > < a name = "Tyan%202688" > < / a >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< h3 > 4.31.4 Tyan 2688< / h3 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > For board hangs, see support ticket 721 for information.
2002-09-15 02:16:22 +00:00
Also < a href = "#Section%204.29" > Inserting modules hangs my board< / a > .
2003-04-15 14:47:32 +00:00
< p > < hr >
Node:< a name = "Section%204.32" > Section 4.32< / a > ,
2003-08-23 17:29:58 +00:00
Previous:< a rel = previous href = "#Section%204.31" > Section 4.31< / a > ,
Up:< a rel = up href = "#Problems" > Problems< / a >
2003-04-15 14:47:32 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 4.32 Problems on particular systems< / h2 >
2003-04-15 14:47:32 +00:00
2003-08-23 17:29:58 +00:00
< p > For IBM systems, see < code > README.thinkpad< / code > .
2003-04-15 14:47:32 +00:00
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Help" > Help< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Contribute" > Contribute< / a > ,
Previous:< a rel = previous href = "#Problems" > Problems< / a > ,
Up:< a rel = up href = "#Top" > Top< / a >
< br >
< h1 > 5 How to Ask for Help< / h1 >
< ul >
< li > < a href = "#Section%205.1" > Section 5.1< / a > : What to send us when asking for help
< li > < a href = "#Section%205.2" > Section 5.2< / a > : What to do if a module won't insert?
< li > < a href = "#Section%205.3" > Section 5.3< / a > : What to do if it inserts, but nothing happens?
< li > < a href = "#Section%205.4" > Section 5.4< / a > : What to do if I read only bogus information?
< li > < a href = "#Section%205.5" > Section 5.5< / a > : What to do if you have other problems?
< li > < a href = "#Section%205.6" > Section 5.6< / a > : What if it just works like a charm?
< li > < a href = "#Section%205.7" > Section 5.7< / a > : How do I update a ticket?
< li > < a href = "#Section%205.8" > Section 5.8< / a > : How do I follow up on a ticket?
2002-09-15 02:16:22 +00:00
< / ul >
< p > < hr >
Node:< a name = "Section%205.1" > Section 5.1< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%205.2" > Section 5.2< / a > ,
Up:< a rel = up href = "#Help" > Help< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 5.1 What to send us when asking for help< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > We are always willing to answer questions if things don't work out.
2002-09-15 02:16:22 +00:00
Please email < a href = "mailto:sensors@stimpy.netroedge.com" > sensors@stimpy.netroedge.com< / a > , and not the individual authors,
unless you have something private to say.
2003-08-23 17:29:58 +00:00
< p > Instead of using email, you can also use the web-based support
2002-09-15 02:16:22 +00:00
area, at < a href = "http://secure.netroedge.com/~lm78/support.html" > http://secure.netroedge.com/~lm78/support.html< / a > . 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.
2003-08-23 17:29:58 +00:00
< p > Here's what you should send us:
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< ul >
2002-09-15 02:16:22 +00:00
< li > The dmesg or syslog output if applicable
< li > The output of (as root) < code > prog/detect/sensors-detect< / code >
< li > The output of < code > lsmod< / code >
< li > If a PCI chip problem:
2003-08-23 17:29:58 +00:00
< ul >
2002-09-15 02:16:22 +00:00
< li > The output of < code > lspci -n< / code >
< / ul >
2003-08-23 17:29:58 +00:00
< li > If an I2C sensor chip problem:
< ul >
2002-09-15 02:16:22 +00:00
< li > The output of (as root) < code > prog/detect/i2cdetect X< / code >
where X = the bus number (run < code > i2cdetect< / code > with no arguments to list the busses)
(please send this only if it's not all < code > XX< / code > )
< li > The output of (as root) < code > prog/dump/i2cdump X 0xXX< / code >
where XX = the address of each chip you see in the output of < code > i2cdetect< / code > . (run once for each chip)
(please send this only if it's not all < code > ff< / code > )
< / ul >
2003-08-23 17:29:58 +00:00
< li > If an ISA sensor chip problem:
< ul >
2002-09-15 02:16:22 +00:00
< li > The output of (as root) < code > prog/dump/isadump 0x295 0x296< / code > (only if it's not all < code > XX< / code > )
< / ul >
2003-08-23 17:29:58 +00:00
< li > Part numbers of chips on your motherboard you think are the sensor chips (look at your motherboard)
2002-09-15 02:16:22 +00:00
< li > Motherboard type
< li > Sensors version
< li > Kernel version
< / ul >
< p > < hr >
Node:< a name = "Section%205.2" > Section 5.2< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%205.3" > Section 5.3< / a > ,
Previous:< a rel = previous href = "#Section%205.1" > Section 5.1< / a > ,
Up:< a rel = up href = "#Help" > Help< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 5.2 What to do if a module won't insert?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Did you use < code > modprobe< / code > instead of < code > insmod< / code > ??? Don't use insmod.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Were there unresolved symbols? Did you run < code > depmod -a< / code > ? Run
2002-09-15 02:16:22 +00:00
< code > depmod -a -e< / code > to see where the symbol problem is.
2003-08-23 17:29:58 +00:00
< p > ALWAYS inspect the output of < code > dmesg< / code > . That's where the error
2002-09-15 02:16:22 +00:00
messages come out!!! Don't rely on the generic message from < code > modprobe< / code > .
If you still can't figure it out, send us the information
listed above.
< p > < hr >
Node:< a name = "Section%205.3" > Section 5.3< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%205.4" > Section 5.4< / a > ,
Previous:< a rel = previous href = "#Section%205.2" > Section 5.2< / a > ,
Up:< a rel = up href = "#Help" > Help< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 5.3 What to do if it inserts, but nothing happens?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > For an ISA sensor chip, did you also < code > modprobe i2c-isa< / code > ? It must be inserted.
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > For an I2C sensor chip, did you also < code > modprobe i2c-xxx< / code > where xxx is your
2002-09-15 02:16:22 +00:00
I2C bus adapter? It must be inserted.
2003-08-23 17:29:58 +00:00
< p > Always inspect the output of < code > dmesg< / code > . That's where the error
2002-09-15 02:16:22 +00:00
messages come out. If you still can't figure it out, send us the information
listed above.
< p > < hr >
Node:< a name = "Section%205.4" > Section 5.4< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%205.5" > Section 5.5< / a > ,
Previous:< a rel = previous href = "#Section%205.3" > Section 5.3< / a > ,
Up:< a rel = up href = "#Help" > Help< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 5.4 What to do if I read only bogus information?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > It may be that this was a mis-detection: the chip may not be
2002-09-15 02:16:22 +00:00
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 < a href = "#Help" > Help< / a > )
< p > < hr >
Node:< a name = "Section%205.5" > Section 5.5< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%205.6" > Section 5.6< / a > ,
Previous:< a rel = previous href = "#Section%205.4" > Section 5.4< / a > ,
Up:< a rel = up href = "#Help" > Help< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 5.5 What to do if you have other problems?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Again, send the output listed above.
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Section%205.6" > Section 5.6< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%205.7" > Section 5.7< / a > ,
Previous:< a rel = previous href = "#Section%205.5" > Section 5.5< / a > ,
Up:< a rel = up href = "#Help" > Help< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 5.6 What if it just works like a charm?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Drop us a mail if you feel like it, mentioning the mainboard and
2002-09-15 02:16:22 +00:00
detected chip type. That way, we have some positive feedback, too!
< p > < hr >
Node:< a name = "Section%205.7" > Section 5.7< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%205.8" > Section 5.8< / a > ,
Previous:< a rel = previous href = "#Section%205.6" > Section 5.6< / a > ,
Up:< a rel = up href = "#Help" > Help< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 5.7 How do I update a ticket?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > You can't. Only developers can. Follow up by emailing us
2002-09-15 02:16:22 +00:00
at < a href = "mailto:sensors@stimpy.netroedge.com" > sensors@stimpy.netroedge.com< / a > and reference your ticket number
in the subject. Please don't enter a new ticket with
follow-up information, email us instead. Thanks.
< p > < hr >
Node:< a name = "Section%205.8" > Section 5.8< / a > ,
2003-08-23 17:29:58 +00:00
Previous:< a rel = previous href = "#Section%205.7" > Section 5.7< / a > ,
Up:< a rel = up href = "#Help" > Help< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 5.8 How do I follow up on a ticket?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Follow up by emailing us at < a href = "mailto:sensors@stimpy.netroedge.com" > sensors@stimpy.netroedge.com< / a >
2002-09-15 02:16:22 +00:00
and reference your ticket number in the subject.
< p > < hr >
Node:< a name = "Contribute" > Contribute< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Version%201%20Specifics" > Version 1 Specifics< / a > ,
Previous:< a rel = previous href = "#Help" > Help< / a > ,
Up:< a rel = up href = "#Top" > Top< / a >
< br >
< h1 > 6 How to Contribute< / h1 >
< ul >
< li > < a href = "#Section%206.1" > Section 6.1< / a > : How to write a driver
< li > < a href = "#Section%206.2" > Section 6.2< / a > : How to get CVS access
< li > < a href = "#Section%206.3" > Section 6.3< / a > : How to donate hardware to the project
< li > < a href = "#Section%206.4" > Section 6.4< / a > : How to join the project mailing list
< li > < a href = "#Section%206.5" > Section 6.5< / a > : How to access mailing list archives
< li > < a href = "#Section%206.6" > Section 6.6< / a > : How to submit a patch
< li > < a href = "#Section%206.7" > Section 6.7< / a > : How to REALLY help
< li > < a href = "#Section%206.8" > Section 6.8< / a > : How to block spam on the project mailing list
2002-09-15 02:16:22 +00:00
< / ul >
< p > < hr >
Node:< a name = "Section%206.1" > Section 6.1< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%206.2" > Section 6.2< / a > ,
Up:< a rel = up href = "#Contribute" > Contribute< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 6.1 How to write a driver< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > See < code > doc/developers/new_drivers< / code > in our package for instructions.
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Section%206.2" > Section 6.2< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%206.3" > Section 6.3< / a > ,
Previous:< a rel = previous href = "#Section%206.1" > Section 6.1< / a > ,
Up:< a rel = up href = "#Contribute" > Contribute< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 6.2 How to get CVS access< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > For anonymous CVS read access, see the instructions on our download page.
2002-09-15 02:16:22 +00:00
Sorry, we don't have automatically generated CVS tarballs.
2003-08-23 17:29:58 +00:00
< p > For write access, run the script < code > doc/developers/genpasswd.pl< / code > in
2002-09-15 02:16:22 +00:00
our package and follow the instructions. Let us know what part
of the package you would like to work on.
< p > < hr >
Node:< a name = "Section%206.3" > Section 6.3< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%206.4" > Section 6.4< / a > ,
Previous:< a rel = previous href = "#Section%206.2" > Section 6.2< / a > ,
Up:< a rel = up href = "#Contribute" > Contribute< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 6.3 How to donate hardware to the project< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Send us email < a href = "mailto:sensors@stimpy.netroedge.com" > sensors@stimpy.netroedge.com< / a > .
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Section%206.4" > Section 6.4< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%206.5" > Section 6.5< / a > ,
Previous:< a rel = previous href = "#Section%206.3" > Section 6.3< / a > ,
Up:< a rel = up href = "#Contribute" > Contribute< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 6.4 How to join the project mailing list< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Send us email < a href = "mailto:sensors@stimpy.netroedge.com" > sensors@stimpy.netroedge.com< / a > . Sorry,
there is no automated subscribe/unsubscribe service yet
(but we're seriously thinking of switching to majordomo).
Please note that you do NOT need to be subscribed to the list
in order to post. If you simply need help as a user, post your
detailed problem and questions directly. Don't worry, you'll be
CC'd on all replies.
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Section%206.5" > Section 6.5< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%206.6" > Section 6.6< / a > ,
Previous:< a rel = previous href = "#Section%206.4" > Section 6.4< / a > ,
Up:< a rel = up href = "#Contribute" > Contribute< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 6.5 How to access mailing list archives< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > The mailing list archive is at: < a href = "http://archives.andrew.net.au/lm-sensors" > http://archives.andrew.net.au/lm-sensors< / a >
2002-09-15 02:16:22 +00:00
Sorry, it only contains messages since October 28, 2001.
< p > < hr >
Node:< a name = "Section%206.6" > Section 6.6< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%206.7" > Section 6.7< / a > ,
Previous:< a rel = previous href = "#Section%206.5" > Section 6.5< / a > ,
Up:< a rel = up href = "#Contribute" > Contribute< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 6.6 How to submit a patch< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Check out the latest from CVS, then copy the directory to another
2002-09-15 02:16:22 +00:00
directory, and make your changes. Generate the diff with
< code > diff -u2 -r DIR1 DIR2< / code > . Or you can generate the diff in CVS with
< code > cvs diff -u2< / code > . Send us the patch in an email and tell us what it does.
< p > < hr >
Node:< a name = "Section%206.7" > Section 6.7< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%206.8" > Section 6.8< / a > ,
Previous:< a rel = previous href = "#Section%206.6" > Section 6.6< / a > ,
Up:< a rel = up href = "#Contribute" > Contribute< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 6.7 How to REALLY help< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Believe it or not, what we really need help with are:
< ul >
2002-09-15 02:16:22 +00:00
< li > Answering email
< li > Answering support tickets
< li > Submitting patches to Linus, etc.
< li > Creating a sensors.conf database
< li > Creating RPM's
< / ul >
2003-08-23 17:29:58 +00:00
< p > Send us email < a href = "mailto:sensors@stimpy.netroedge.com" > sensors@stimpy.netroedge.com< / a > if you can help.
2002-09-15 02:16:22 +00:00
No experience necessary :)
2003-02-17 01:58:10 +00:00
< p > < hr >
Node:< a name = "Section%206.8" > Section 6.8< / a > ,
2003-08-23 17:29:58 +00:00
Previous:< a rel = previous href = "#Section%206.7" > Section 6.7< / a > ,
Up:< a rel = up href = "#Contribute" > Contribute< / a >
2003-02-17 01:58:10 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 6.8 How to block spam on the project mailing list< / h2 >
2003-02-17 01:58:10 +00:00
2003-08-23 17:29:58 +00:00
< p > Sorry, we know the spam is a hassle. It would be nice to have a
2003-02-17 01:58:10 +00:00
moderator who can screen everything, but that takes too much time and
delays emails. Right now there is a procmail script which tags likely
spam and puts in a X-SBClass: header. If it is followed by 'Spam', then
it is almost certainly spam, if it is followed by 'Blocked', then it
scores high as being potential spam. You should be able to set some
rules in your mail client to throw those emails into a seperate folder.
It's not bullet proof (some legit mails get tagged wrong, and vice
versa), but it seems to be about 95% accurate in our experience.
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Version%201%20Specifics" > Version 1 Specifics< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Document%20Revisions" > Document Revisions< / a > ,
Previous:< a rel = previous href = "#Contribute" > Contribute< / a > ,
Up:< a rel = up href = "#Top" > Top< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h1 > 7 Version 1 Specific Questions< / h1 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< ul >
< li > < a href = "#Section%207.1" > Section 7.1< / a > : My mainboard has an SMBus, your code can't find it. Why?
< li > < a href = "#Section%207.2" > Section 7.2< / a > : The modules won't load, saying 'SMBus not detected'.
< li > < a href = "#Section%207.3" > Section 7.3< / a > : I get a "No sensor data yet (try again in a few moments)" msg.
< li > < a href = "#Section%207.4" > Section 7.4< / a > : On my Dell, a LM80 is detected, but all readings are 0!
2002-09-15 02:16:22 +00:00
< / ul >
2003-08-23 17:29:58 +00:00
< p > Note: Version 1 is very very old and is not recommended.
2002-09-15 02:16:22 +00:00
< p > < hr >
Node:< a name = "Section%207.1" > Section 7.1< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%207.2" > Section 7.2< / a > ,
Up:< a rel = up href = "#Version%201%20Specifics" > Version 1 Specifics< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 7.1 My manufacturer swears that my mainboard has an SMBus, but your code reports that it can't find it. What's wrong?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Currently, our code only assumes that an SMBus exists if it originates
2002-09-15 02:16:22 +00:00
from the Intel PIIX4 (82371AB). If your computer doesn't have one, or if your
SMBus originates from a different SMBus 'host', then you are out of luck. :'(
Our experience is, though, that most machines have a PIIX4, and that it is
where the SMBus is hosted.
2003-08-23 17:29:58 +00:00
< p > Regarding the VIA chip set(s):
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > Right now, the SMBus code depends on the Intel PIIX4 chip to handle
2002-09-15 02:16:22 +00:00
SMBus transactions. The VIA chip set is NOT supported at this time because
it forces much of the SMBus protocol to be implemented by software.
2003-08-23 17:29:58 +00:00
< p > To implement the SMBus correctly with the VIA chip, it needs to be
2002-09-15 02:16:22 +00:00
written at a low level to be quick. A more attractive alternative is to
use the Bios SMBus interface (not always available nor standard).
2003-08-23 17:29:58 +00:00
< p > Version 2 supports the VIA chipset, and will support other chipsets.
2002-09-15 02:16:22 +00:00
Version 1 never will.
< p > < hr >
Node:< a name = "Section%207.2" > Section 7.2< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%207.3" > Section 7.3< / a > ,
Previous:< a rel = previous href = "#Section%207.1" > Section 7.1< / a > ,
Up:< a rel = up href = "#Version%201%20Specifics" > Version 1 Specifics< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 7.2 The modules won't load, saying 'SMBus not detected'.< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > This should no longer be an issue in 1.4.10 and later; it will
2002-09-15 02:16:22 +00:00
continue loading, but it won't support SMBus-connected devices, of course.
< p > < hr >
Node:< a name = "Section%207.3" > Section 7.3< / a > ,
2003-08-23 17:29:58 +00:00
Next:< a rel = next href = "#Section%207.4" > Section 7.4< / a > ,
Previous:< a rel = previous href = "#Section%207.2" > Section 7.2< / a > ,
Up:< a rel = up href = "#Version%201%20Specifics" > Version 1 Specifics< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 7.3 I try to read < code > /proc/sensors< / code > , and I get a "No sensor data yet (try again in a few moments)" message. Why?< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > It takes about 1.5 seconds for the LM78 to update all its sensor
2002-09-15 02:16:22 +00:00
values. If we would try to read it before it finished that, you would get
old garbage instead. So you have to wait 1.5 seconds after the module is
inserted before you can access < code > /proc/sensors< / code > .
2003-08-23 17:29:58 +00:00
< p > Module versions 1.3.7 and later let the process sleep if it tries
2002-09-15 02:16:22 +00:00
to access sensor data right after insertion time, and do not display this
message anymore.
< p > < hr >
Node:< a name = "Section%207.4" > Section 7.4< / a > ,
2003-08-23 17:29:58 +00:00
Previous:< a rel = previous href = "#Section%207.3" > Section 7.3< / a > ,
Up:< a rel = up href = "#Version%201%20Specifics" > Version 1 Specifics< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h2 > 7.4 On my Dell, a LM80 is detected, but all readings are 0!< / h2 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< p > This is a bug we have only observed on Dell computers. There is
2002-09-15 02:16:22 +00:00
probably a problem with the way the SMBus is accessed; but it is not yet
clear whether the problem is in our code or with the Dells.
2003-08-23 17:29:58 +00:00
< p > There are very probably no sensor chips at all on your computer;
2002-09-15 02:16:22 +00:00
but until somebody contacts Dell about this and tells us the results, we
can not be sure.
< p > < hr >
Node:< a name = "Document%20Revisions" > Document Revisions< / a > ,
2003-08-23 17:29:58 +00:00
Previous:< a rel = previous href = "#Version%201%20Specifics" > Version 1 Specifics< / a > ,
Up:< a rel = up href = "#Top" > Top< / a >
2002-09-15 02:16:22 +00:00
< br >
2003-08-23 17:29:58 +00:00
< h1 > Appendix A Revision History of This Document< / h1 >
2002-09-15 02:16:22 +00:00
2003-08-23 17:29:58 +00:00
< ul >
2003-07-03 06:50:08 +00:00
< li > Rev 2.9 (CP) Converted to Gnu texinfo format, 20020910
2002-09-15 02:16:22 +00:00
< li > Rev 2.8 (MDS) Minor updates 20020710, released with lm_sensors 2.6.4
< li > Rev 2.7 (MDS) Minor updates 20020425
< li > Rev 2.6 (MDS) Minor updates 20020115, released with lm_sensors 2.6.3
< li > Rev 2.5 (MDS) Minor updates 20011111, released with lm_sensors 2.6.2
< li > Rev 2.4 (MDS) Minor updates 20010722
< li > Rev 2.3 (MDS) General update, 20010224, released with lm_sensors 2.6.0.
< li > Rev 2.2 (Frodo) Corrections for lm_sensors 2.4, 19990920
< li > Rev 2.1 (Frodo) Corrections for lm_sensors 2.2, 19990112
< li > Rev 2.0 (Frodo) Major revision for lm_sensors 2.1, 19981229
< li > Rev 1.10 (Frodo) Modified 3.8, updated some other things, 19980924
< li > Rev 1.9 (Frodo) Added 3.15, 19980906
< li > Rev 1.8 (Frodo) Added 3.14, 19980905
< li > Rev 1.7 (Phil) Added 3.13 and some other minor changes, 19980901
< li > Rev 1.6 (Frodo) Added 4, 4.1, 4.2, 4.3, 4.4, 4.5, 19980901
< li > Rev 1.5 (Frodo) Added 2.3, 2.4, 3.9, 3.10, 3.11, 19980826
< li > Rev 1.4 (Frodo) Added some more Winbond information, and 3.5-3.8, 19980817
< li > Rev 1.3 Added info on the Winbond chip, 19980816
< li > Rev 1.2 Adapation by Frodo Looijaard, 19980810
< li > Rev 1.1 Modifications by Philip Edelbrock, 19980809
< li > Rev 1.0 Written by Philip Edelbrock, 19980803
< / ul >
2003-08-23 17:29:58 +00:00
< / body > < / html >
