Bug 123340 - ia32el cannot work with kernels built for more than 64 CPUs
Summary: ia32el cannot work with kernels built for more than 64 CPUs
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ia32el (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-05-17 11:43 UTC by Yoav Zach
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-18 09:46:56 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
use cpu_set_t for cpu mask instead of unsigned long (23.37 KB, patch)
2004-05-17 11:44 UTC, Yoav Zach
no flags Details | Diff
fixes a problem with prev patch (508 bytes, patch)
2004-06-22 11:10 UTC, Yoav Zach
no flags Details | Diff

Description Yoav Zach 2004-05-17 11:43:12 UTC
Description of problem:
when running with a kernel that was built for more than 64 CPUs, the 
affinity mask is larger than the size of 'unsigned long' which 
libia32x.so is using for set/get affinity. therefore, calls to this 
syscall ( which are made directly, not via glibc ) fail and cause 
ia32el to crash )

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

How reproducible:
run a 32 bit application, which uses shared memory, in a system that 
was built for more than 64 CPUs

Steps to Reproduce:
1.
2.
3.
  
Actual results:
the application crashes

Expected results:
application should run correctly

Additional info:

Comment 1 Yoav Zach 2004-05-17 11:44:12 UTC
Created attachment 100267 [details]
use cpu_set_t for cpu mask instead of unsigned long

Comment 2 Yoav Zach 2004-06-22 11:10:26 UTC
Created attachment 101327 [details]
fixes a problem with prev patch

should go on top of prev patch

Comment 3 Yoav Zach 2004-11-16 08:01:53 UTC
this is fixed in v5. i believe it should be closed.


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