Bug 79875 - 2.4.18-18.8.0 doesn't run smp code
2.4.18-18.8.0 doesn't run smp code
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
8.0
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-17 13:45 EST by Joshua Weage
Modified: 2007-04-18 12:49 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-03 06:22:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joshua Weage 2002-12-17 13:45:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

Description of problem:
I'm running LS-Dyna on dual CPU Athlon machines.  RedHat 7.3 runs the code fine
with both release kernels.  RedHat 8.0 with 2.4.18-18.8.0 runs the code, but
with only one cpu.


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


How reproducible:
Always

Steps to Reproduce:
1.  Run LS-Dyna with multi-cpu's.
2.
3.
    

Additional info:
Comment 1 Ben LaHaise 2002-12-17 15:39:38 EST
Check your /proc/cpuinfo.  If two CPUs are present, the kernel is working fine,
and the bug is in some other code, probably the application.
Comment 2 Joshua Weage 2002-12-17 18:21:59 EST
I am seeing 2 cpu's displayed while running top, so the kernel is detecting them
both.  I find it strange that the application runs fine with 7.3 2.4.18-3 and
2.4.18-18.7.x kernels, but not the 8.0 2.4.18-18.8.0 kernel -- on identical
hardware.

Considering all of the other bugs I've ran into with the 8.0 release, it may not
be kernel related.  Maybe it is something with the thread library?  I'm not at
work currently, so I can't check what libraries it is using.  Anyway, I wanted
to log this problem as I didn't see anything else like it logged already.
Comment 3 Arjan van de Ven 2002-12-17 18:24:19 EST
2.4.18-18.7.x and 2.4.18-18.8.0 are identical source code wise
which means it's not going to be a kernel bug....
reassigning to glibc since that's the next candidate
Comment 4 Ulrich Drepper 2003-04-22 03:50:31 EDT
Try this on RHL9.  I have no idea what should be the reason.  You should dig in
the code and determine where it is decided in the code that only one thread (or
process) is used.  If the program is using more than one thread/process
definitely all processors are used.  It either seems to be a problem in the
application code where it tries to find out how many processors are used, or a
hiccup in the runtime function which allows to determine this (there is only one
such function: sysconf).
Comment 5 Ulrich Drepper 2003-10-03 06:22:37 EDT
No response in almost 6 months.  Closing as NOTABUG since the runtime definitely
doesn't restrict an application to run on one processor.  If that kernel already
supported the affinity syscalls (I don't know whether it did) then it must be
the application which choses to use those.  The runtime _never_ uses them on its
own.

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