Kernel driver `xeontemp.o' ========================= Status: Complete; tested for most devices except Xeon. Supported chips: * Intel Xeon and other processors Prefix: 'xeontemp' Addresses scanned: I2C 0x18, 0x1a, 0x29, 0x2b, 0x4c, 0x4e Datasheets: Publicly available at the Intel website See the adm1021 document for additional references Authors: Frodo Looijaard ,Philip Edelbrock , and Mark D. Studebaker (mdsxyz123@yahoo.com) License: GPL Module Parameters ----------------- * force: short array (min = 1, max = 48) List of adapter,address pairs to boldly assume to be present * force_xeontemp: short array (min = 1, max = 48) List of adapter,address pairs which are unquestionably assumed to contain a `xeontemp' chip * probe: short array (min = 1, max = 48) List of adapter,address pairs to scan additionally * probe_range: short array (min = 1, max = 48) List of adapter,start-addr,end-addr triples to scan additionally * ignore: short array (min = 1, max = 48) List of adapter,address pairs not to scan * ignore_range: short array (min = 1, max = 48) List of adapter,start-addr,end-addr triples not to scan * read_only: int Don't set any values, read only mode Description ----------- Many Xeons and other Intel processors have an embedded i2c temperature sensor that look very similar to an adm1021 or max1617. Some Xeons have honest to goodness, real live, actual MAX1617 chips on them. Others Xeons made around the same time have other ADM1021 compatible chips on them. They are mounted on the CPU substrate along with the processor information EEPROM that is part of that generation of Xeon CPU's. So it's basically impossible to tell a Xeon TEMP sensor from a MAX1617 since they are in fact the same chip. The Xeon Temperature sensors spec is just a stripped down register spec for the ADM1021 that says the "on-board" or "built-in" sensor registers are "reserved". That way Intel could substitute whatever ADM1021 compatible chip was cheapest at the time when they built the CPU's. One reason to use the xeontemp driver is if, when Intel built your particular Xeon's, they didn't use any of the ADM1021 compatible chips that the ADM1021 driver recognizes. In that case, using the xeontemp driver will get you the temperatures you want without potentially messing up something in the sensor. Another reason is to avoid having 'sensors' report the second temperature. Unfortunately, the 533MHz FSB Xeon's, dropped the on-board sensor chip. So these new Xeons require a sensor on the motherboard to be connected to the thermal diode to read the temperature. But these 533MHz capable motherboards can also accept 400MHz CPU's with the on-board sensor so it gets confusing in a hurry for motherboard vendors and users. If you have 400MHz FSB P4 Xeon CPU's, you should have an on-CPU ADM1021 compatible sensor at 0x18 or 0x19. In that case, use the ADM1021 driver if it detects a chip at that address. The CPU DIE temperature (Tj) will be the "REMOTE" temperature from this sensor. The "Board" or "built-in" temperature from the ADM1021 will be the temperature of the ADM1021 compatible itself which is one of the chips you see on the side of the CPU. If you have sensors at 0x18 and 0x19 that are not detected by the ADM1021, and you have 400MHz Xeons, then you may want to try the xeontemp driver. If you have 533MHZ FSB Xeons, then you do *not* have an on-board thermal sensor and you should look for CPU temperatures from the other sensors on your motherboard. (Winbond chip for example). If you have an Intel Xeon processor, and sensors-detect recommended the adm1021 driver, and the address is one of 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e, and when using the adm1021 driver, temp1 is invalid but temp2 looks correct, then it is likely you should use the xeontemp driver instead. If you have dual Xeons you may have appear to have two separate adm1021-compatible chips, or two single-temperature sensors, at distinct addresses. In summary, the xeontemp module supports one temperature and the adm1021 module supports two. Use the module that works best for you. See the adm1021 documentation for more information. Author/Maintainer ----------------- Mark D. Studebaker (mdsxyz123@yahoo.com). Derived from the adm1021 driver. Thanks to Philip Pokorny for help with this document.