Bug 79875
Summary: | 2.4.18-18.8.0 doesn't run smp code | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Joshua Weage <weage98> |
Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | fweimer |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | athlon | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-10-03 10:22:37 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Joshua Weage
2002-12-17 18:45:04 UTC
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. 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. 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 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). 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. |