Distribution: Gentoo Linux Hardware Environment: Pentium 4 1.8, Asus P4T-E, 512MB RDRAM Software Environment: gcc-3.4.3, glibc-2.3.4.20050125 Problem Description: Under newer kernels (e.g. 2.6.11, 2.6.11-mm3) my system is very slow. The latest normally working kernel is 2.6.11-rc2-bk4. The problem seems to exist since 2.6.11-rc3. I tried different kernels with and without ACPI. I get no errors in dmesg. I have no idea what changes in the kernel are causing this.
Created attachment 4711 [details] kernel .config used with 2.6.11-mm3
Created attachment 4712 [details] lspci -vvv output
That seems to be a 73,000 line diff. Can you please narrow the problem down to a particular 2.6.11-rc2-bkX snapshot?
I narrowed the problem down now: 2.6.11-rc3 works 2.6.11-rc3-bk1 does not and it's only there if I load the modules i2c-i801 + w83781d. I also noticed that if I load the modules, the CPU temperature is totally wrong. After the modules are loaded, unloading them does not help.
Your Asus motherboard uses an AS99127F chip for hardware monitoring. Temperature channels 2 and 3 of this chip were not properly handled up to and including 2.6.11-rc3, in that the value exposed to user-space by the driver was half the real values. To compensate for this, the default sensors.conf file would multiply the values by 2. In 2.6.11-rc3-bk1, the w83781d driver was fixed to expose the correct values for AS99127F chips. This means that the compensation in sensors.conf needs to be removed. Edit /etc/sensors/conf, search for the as99127f-* section, then scroll down to the "compute temp2" and "compute temp3" lines, and discard the now incorrect multiplication. Alternatively you can just fetch the new default configuration file from lm_sensors CVS and start from that. I think the slowdown can be explained by a CPU-throttling mechanism. If the throttling mechanism thought the temperature was way too high, it must have throttled as much as possible, waiting for the temperature to lower, but this never happened, because the temperature wasn't high, just improperly reported. Once the configuration file is fixed and correct temperatures are reported, I'd expect the system to be back to full speed.
Ok, I now upgraded to the latest lm_sensors CVS and loaded the 2 modules afterwards. I seems to work now :) Could it be that sensors -s did set something in the kernel that telled the hardware something wrong? Because I don't believe the kernel modules look into /etc/sensors.conf.
You're right, "sensors -s" was most likely reprogramming the temperature limits incorrectly due to the wrong compute lines, causing alarms to trigger when they shouldn't have.
*** Bug 5186 has been marked as a duplicate of this bug. ***