root/lm-sensors/tags/V2-8-4/BUGS

Except for many unimplemented things (listed in the TODO file), there may be
true bugs too. If you experience any problems not listed here,
do not hesitate to mail sensors@stimpy.netroedge.com.
But read this file and doc/FAQ first, please!

============================================================================
These are current problems with specific programs and drivers.
In general, please don't send us mail telling us you have the
same problem!!  Do send us mail if you have a fix!!


================================
Asus boards - as99127f support (w83781d driver)

Several problems. Asus will not release a datasheet.
Support was developed - and tweaked - with experimentation and user feedback.
These will not be fixed unless we get a datasheet.
If you have problems, please lobby Asus to release a datasheet.
Unfortunately, several others have done so, without success.
Please do not send mail to us asking for better as99127f support.
We have done the best we can without a datasheet.
The changes we do make to please some people generally makes
things worse for people with other types of motherboard.
Please do not send mail to the author or the sensors group asking for
a datasheet or ideas on how to convince Asus.
See doc/chips/w83781d for more information.

Also, many as99127f chips are misidentified as w83781d or w83782d chips.
If so, you can fix this by forcing the driver:
modprobe w83781d force_as99127f=BUS,0x2d where BUS is your bus number
(cat /proc/bus/i2c to identify your bus number).

================================
i2c/smbus lockup (i2c-piix4 and i2c-ali15x3 drivers)

Sometimes the i2c bus will get hung and the driver can't un-hang it.
If this is caused by a hung sensor chip (mtp008 and w83781d chips may
be culprits), only a reboot or even power cycle will clear it
(if the SDRAM eeproms are on the hung i2c bus, the machine probably won't
boot until the power is cycled).
If there are bugs in the i2c bus drivers, or improvements we can make to
error recovery, we don't know what they are.

On the ASUS P5A motherboard, there are several reports that
the SMBus will hang and this can only be resolved by
powering off the computer. It appears to be worse when the board
gets hot, for example under heavy CPU load, or in the summer.
There may be electrical problems on this board.
On the P5A, the W83781D sensor chip is on both the ISA and
SMBus. Therefore the SMBus hangs can generally be avoided
by accessing the W83781D on the ISA bus only.

================================
IBM Thinkpad laptops and sensors-detect
See the file README.thinkpad


================================
mtp008 support

This chip does not always respond, as evidenced by 'XX' fields
in i2cdump. Results in non-detection by sensors-detect and/or
the mtp008 driver, or periodic bad readings.
Cause unknown - perhaps a bug in the chip, or the chip
not meeting the i2c specifications.


================================
sis5595 (sis5595 and i2c-sis5595 drivers)

These drivers latch on to many non-sis5595 chips which
do not support sensors, i2c bus, or both.
This is because SiS uses the same PCI ID for several different chips.
This will have to be fixed by us to recognize these other chips.

Right now, the driver tries
writing the base addresses (using the force_addr=0x.... parameter to modprobe),
it does not work for some machines (dmesg message is "force address failed").
Either some chips do not support sensors, or there is some undocumented
lock bit for the base address registers.

Also, the temperature reading in sis5595 is usually wrong.
Different formulas are required for different versions of
the chip and different motherboards.

================================
bus drivers (all)

Rmmod'ing a bus driver when the /proc directory for a chip
driver on that bus is in use may cause a kernel oops, because
the chip driver gets removed too. See ticket #331 for details.
Not likely to happen. No obvious way to fix.


============================================================================
Following are old problems with older kernels.


Pre-2.1.58 /proc directory Oops
===============================

There is a problem in pre 2.1.58 kernels that can make the kernel Oops. You
can trigger this Oops if you have opened any file, or are in any directory,
created by a module. If you remove the module at such a moment, successive
access to those files or directories will make the kernel complain through
an Oops. There is really no good way to solve this. Stock kernel modules
exhibit the same problem, by the way. Kernels from 2.1.58 onwards have new
fill_inode() semantics; using this function, we can increase the module use
count while a module file or directory is accessed. This solves the problem,
because it makes it impossible to remove the module.
Alan Cox (alan@lxorguk.ukuu.org.uk), the maintainer of 2.0 kernels, has
said he will consider patches that backport this 2.1 feature; perhaps it
will be in 2.0.37. Until then, be careful when you unload modules.


2.2.x cdrom.o Oops
==================

Module cdrom.o in all 2.2 kernels conflicts with our sensors.o module.
You can get an Oops if cdrom.o is unloaded after sensors.o was loaded.
Below is a small diff that you can apply to the kernel to correct this.
Another solution is to make sure cdrom.o is never unloaded, or to make
sure it is not a module but compiled into the kernel proper.

The diff corrects a long-standing /proc bug. It will go into kernel 2.2.2
or later in a somewhat modified form. It was written by Jens Axboe 
<axboe@image.dk>.

-----cut here-----
--- virgin/kernel/sysctl.c      Sat Jan  9 07:54:16 1999
+++ linux/kernel/sysctl.c       Mon Feb  1 23:44:58 1999
@@ -559,12 +559,12 @@
                        unregister_proc_table(table->child, de);
                }
                /* Don't unregister proc directories which still have
-                  entries... */
-               if (!((de->mode & S_IFDIR) && de->subdir)) {
+                  entries or are still being used... */
+               if (!((de->mode & S_IFDIR) && de->subdir) && !de->count)
{
                        proc_unregister(root, de->low_ino);
                        table->de = NULL;
                        kfree(de);
-               } 
+               }
        }
 }
-----cut here-----


Kernel i2c conflict
===================

An older version of the i2c modules is distributed in 2.2 and late 2.1
kernels. If you try to use it at the same moment as our i2c modules, you
may get into trouble. This should be fixed for lm_sensors-2.4.0 and newer.