Bug 4332 - System very slow with >=2.6.11-rc3-bk1
System very slow with >=2.6.11-rc3-bk1
Status: REJECTED DOCUMENTED
Product: Drivers
Classification: Unclassified
Component: Hardware Monitoring
i386 Linux
: P2 normal
Assigned To: Jean Delvare
:
: 5186 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-12 14:53 UTC by Jasmin Buchert
Modified: 2005-11-04 14:42 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.11-rc3-bk1
Tree: Mainline
Regression: ---


Attachments
kernel .config used with 2.6.11-mm3 (32.12 KB, text/plain)
2005-03-12 14:55 UTC, Jasmin Buchert
Details
lspci -vvv output (8.69 KB, text/plain)
2005-03-12 14:56 UTC, Jasmin Buchert
Details

Description Jasmin Buchert 2005-03-12 14:53:08 UTC
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.
Comment 1 Jasmin Buchert 2005-03-12 14:55:44 UTC
Created attachment 4711 [details]
kernel .config used with 2.6.11-mm3
Comment 2 Jasmin Buchert 2005-03-12 14:56:45 UTC
Created attachment 4712 [details]
lspci -vvv output
Comment 3 Andrew Morton 2005-03-13 12:42:07 UTC
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?
Comment 4 Jasmin Buchert 2005-03-13 15:11:16 UTC
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. 
 
Comment 5 Jean Delvare 2005-03-14 00:10:14 UTC
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.

Comment 6 Jasmin Buchert 2005-03-14 07:45:08 UTC
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. 
 
Comment 7 Jean Delvare 2005-03-15 11:43:39 UTC
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.
Comment 8 Jean Delvare 2005-11-04 14:42:42 UTC
*** Bug 5186 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.