root/lm-sensors/trunk/BUGS @ 1149

Revision 1149, 6.0 KB (checked in by mds, 14 years ago)

more on sis5595 and as99127f

  • Property svn:eol-style set to native
  • Property svn:keywords set to Author Date Id Revision
1Except for many unimplemented things (listed in the TODO file), there may be
2true bugs too. If you experience any problems not listed here,
3do not hesitate to mail
4But read this file and doc/FAQ first, please!
7These are current problems with specific programs and drivers.
8In general, please don't send us mail telling us you have the
9same problem!!  Do send us mail if you have a fix!!
13Asus boards - as99127f support (w83781d driver)
15Several problems. Asus will not release a datasheet.
16Support was developed - and tweaked - with experimentation and user feedback.
17These will not be fixed unless we get a datasheet.
18If you have problems, please lobby Asus to release a datasheet.
19Unfortunately, several others have done so, without success.
20Please do not send mail to us asking for better as99127f support.
21We have done the best we can without a datasheet.
22The changes we do make to please some people generally makes
23things worse for people with other types of motherboard.
24Please do not send mail to the author or the sensors group asking for
25a datasheet or ideas on how to convince Asus.
26See doc/chips/w83781d for more information.
28Also, many as99127f chips are misidentified as w83781d or w83782d chips.
29If so, you can fix this by forcing the driver:
30modprobe w83781d force_as99127f=BUS,0x2d where BUS is your bus number
31(cat /proc/bus/i2c to identify your bus number).
34i2c/smbus lockup (i2c-piix4 and i2c-ali15x3 drivers)
36Sometimes the i2c bus will get hung and the driver can't un-hang it.
37If this is caused by a hung sensor chip (mtp008 and w83781d chips may
38be culprits), only a reboot or even power cycle will clear it
39(if the SDRAM eeproms are on the hung i2c bus, the machine probably won't
40boot until the power is cycled).
41If there are bugs in the i2c bus drivers, or improvements we can make to
42error recovery, we don't know what they are.
46IBM Thinkpad laptops and sensors-detect
47See the file README.thinkpad
51mtp008 support
53This chip does not always respond, as evidenced by 'XX' fields
54in i2cdump. Results in non-detection by sensors-detect and/or
55the mtp008 driver, or periodic bad readings.
56Cause unknown - perhaps a bug in the chip, or the chip
57not meeting the i2c specifications.
61sis5595 (sis5595 and i2c-sis5595 drivers)
63These drivers latch on to many non-sis5595 chips which
64do not support sensors, i2c bus, or both.
65This is because SiS uses the same PCI ID for several different chips.
66This will have to be fixed by us to recognize these other chips.
68Right now, the driver tries
69writing the base addresses (using the force_addr=0x.... parameter to modprobe),
70it does not work for some machines (dmesg message is "force address failed").
71Either some chips do not support sensors, or there is some undocumented
72lock bit for the base address registers.
74Also, the temperature reading in sis5595 is usually wrong.
75Different formulas are required for different versions of
76the chip and different motherboards.
79bus drivers (all)
81Rmmod'ing a bus driver when the /proc directory for a chip
82driver on that bus is in use may cause a kernel oops, because
83the chip driver gets removed too. See ticket #331 for details.
84Not likely to happen. No obvious way to fix.
88Following are old problems with older kernels.
91Pre-2.1.58 /proc directory Oops
94There is a problem in pre 2.1.58 kernels that can make the kernel Oops. You
95can trigger this Oops if you have opened any file, or are in any directory,
96created by a module. If you remove the module at such a moment, successive
97access to those files or directories will make the kernel complain through
98an Oops. There is really no good way to solve this. Stock kernel modules
99exhibit the same problem, by the way. Kernels from 2.1.58 onwards have new
100fill_inode() semantics; using this function, we can increase the module use
101count while a module file or directory is accessed. This solves the problem,
102because it makes it impossible to remove the module.
103Alan Cox (, the maintainer of 2.0 kernels, has
104said he will consider patches that backport this 2.1 feature; perhaps it
105will be in 2.0.37. Until then, be careful when you unload modules.
1082.2.x cdrom.o Oops
111Module cdrom.o in all 2.2 kernels conflicts with our sensors.o module.
112You can get an Oops if cdrom.o is unloaded after sensors.o was loaded.
113Below is a small diff that you can apply to the kernel to correct this.
114Another solution is to make sure cdrom.o is never unloaded, or to make
115sure it is not a module but compiled into the kernel proper.
117The diff corrects a long-standing /proc bug. It will go into kernel 2.2.2
118or later in a somewhat modified form. It was written by Jens Axboe
121-----cut here-----
122--- virgin/kernel/sysctl.c      Sat Jan  9 07:54:16 1999
123+++ linux/kernel/sysctl.c       Mon Feb  1 23:44:58 1999
124@@ -559,12 +559,12 @@
125                        unregister_proc_table(table->child, de);
126                }
127                /* Don't unregister proc directories which still have
128-                  entries... */
129-               if (!((de->mode & S_IFDIR) && de->subdir)) {
130+                  entries or are still being used... */
131+               if (!((de->mode & S_IFDIR) && de->subdir) && !de->count)
133                        proc_unregister(root, de->low_ino);
134                        table->de = NULL;
135                        kfree(de);
136-               }
137+               }
138        }
139 }
140-----cut here-----
143Kernel i2c conflict
146An older version of the i2c modules is distributed in 2.2 and late 2.1
147kernels. If you try to use it at the same moment as our i2c modules, you
148may get into trouble. This should be fixed for lm_sensors-2.4.0 and newer.
Note: See TracBrowser for help on using the browser.