Bug 66387 - SMP kernel for dual Xeon "see" four processors
SMP kernel for dual Xeon "see" four processors
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-06-09 12:57 EDT by Benoit
Modified: 2007-04-18 12:43 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-07 15:11:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Benoit 2002-06-09 12:57:08 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Description of problem:
I have installed RH 7.3 on Tyan i860 dual Xeon motherboard without any 
I can run to instances of the same program at the same time (very long batch 
program for neural network computation):
1) they both run at the same speed as they individually run one a single 
processor motherboard
2) xosview shows the two processors working at 100%
3) lm_sensors show one processor at 42 degrees Celsius and the other at 49 
degrees (box is 37 degrees inside)
Up to that point everything is ok.
Then I have updated the kernel from from 2.4.18-3 to 2.4.18-4 with red hat 
network because of the bug fix "kernel panic on smp system".

Boot with new 2.4.18-4smp kernel:
1) xosview doesn't work anymore, even when reinstalled. 
2) running to instances of the same program mentioned above at the same time 
provide a loss of performance of 50% in both programs sugesting that one 
processeur is not working
3) lm_sensors indicate that one processor is 37 degree (the other still 49) 
suggesting too that one processor is not working.

Reboot with 2.4.18-3smp old kernel:
1) xosview is working, but indicates that there is FOUR processors !
2) programs perfomances still bad
3) lm_sensors still show one processor at 37 degree

xosview indicates that processors 2 and 3 are working 100% (processors 0 and 1 
from 0 to 3%), but from time to time (not very ofen),without any action of my 
own, xosview indicates that processor 0 and 3 are working ` 100%; and at that 
point performances of the programmes turn back good, lm_sensors indicates that 
both processors are hot (42 and 49 degrees), and then things went back bad as 
before without any notice or action.

More funny, I can run third instance of my program and xosview said there is 
three processors working at 100%...

Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Steps to Reproduce:
1. I don't want reinstall RH7.3 and upgrade again the kernel.

Additional info:
Comment 1 Arjan van de Ven 2002-06-10 05:03:28 EDT
Something went wrong in -4 that broke xosview. The actual work should be fine
though, it's just the measurement program that gives the wrong data; top should
also still provide the right info.
Comment 2 Benoit 2002-06-10 14:14:25 EDT
no, top doesn't still produce the right info.
Comment 3 Benoit 2002-06-11 13:14:50 EDT
I have found where the problem come from : the bios has Hyper-Thread enable !
I have just disbled it and everything ok.
There is still one question now, why and how when there is already a process 
running on a physical processor the kernel choose to run a second process to 
the second logical processor attache to same physical processor the first 
process is already running on ?
Is it a option or a command to force a task to run on a specific physical 
processor ?
P.S. I found the answer of my problem in the support database of suse linux.
Comment 4 paulm 2002-10-04 15:33:56 EDT
I am seeing double processors on xeon servers also. My kernel is 2.4.18-10
Does redhat consider this a bug? 
Comment 5 Arjan van de Ven 2002-10-04 15:35:55 EDT
you see 4 virtual processors...
you paid money to intel for the hyperthreading feature... use it! :)

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