|Summary:||Kernel should export number and state of local APICs|
|Product:||Red Hat Enterprise Linux 4||Reporter:||Peter Jones <pjones>|
|Component:||kernel||Assignee:||Prarit Bhargava <prarit>|
|Status:||CLOSED ERRATA||QA Contact:||Brian Brock <bbrock>|
|Version:||4.0||CC:||jbaron, jparadis, prarit, tao|
|Fixed In Version:||RHSA-2006-0575||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-08-10 22:35:03 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||171930, 181411|
Description Peter Jones 2006-03-09 22:43:24 UTC
Description of problem: Userland (anaconda) needs to know how many CPUs are in a system, without concern for the current CONFIG_NCPUS or "maxcpus=" setting. Apparently scanning this from userland causes serious instability on some systems. The kernel scans ACPI for this info during boot, but doesn't directly expose the data to userland. So if the kernel could report how many local APICs there are as well as which are enabled and disabled, regardless of the current "maxcpus" setting, then we wouldn't need to do this dangerous scanning. Preferably a file in /proc or /sys, though even an ioctl() would do.
Comment 3 Bob Johnson 2006-04-11 17:17:20 UTC
This issue is on Red Hat Engineering's list of planned work items for the upcoming Red Hat Enterprise Linux 4.4 release. Engineering resources have been assigned and barring unforeseen circumstances, Red Hat intends to include this item in the 4.4 release.
Comment 11 Prarit Bhargava 2006-05-02 18:41:54 UTC
Yep -- got all that. The issue is that x86_apicid is not defined for i386 :( I'll have to do some more thinkin' about the 32 bit side of things ... P.
Comment 22 Jason Baron 2006-05-08 15:34:19 UTC
committed in stream U4 build 35.3. A test kernel with this patch is available from http://people.redhat.com/~jbaron/rhel4/
Comment 23 Peter Jones 2006-05-08 17:39:09 UTC
I only see 35.2 there... what's the story?
Comment 24 Peter Jones 2006-05-08 17:39:51 UTC
Oh, nevermind, I see what you're saying.
Comment 26 Jason Baron 2006-05-23 21:32:00 UTC
seems like the first attempt to debug this would just to try loading the module on say a U2 install, it'll be easiest to debug there if there's a problem with the module.
Comment 29 Mike Gahagan 2006-06-16 14:33:46 UTC
Looks good as far as the kernel module itself is concerned. This is from an Intel single dual-core CPU box. [root@dhcp59-204 ~]# modprobe lapic_status [root@dhcp59-204 ~]# cat /proc/lapics 0 0 1 1 -1 1 [root@dhcp59-204 ~]# uname -a Linux dhcp59-204.rdu.redhat.com 2.6.9-39.EL #1 Thu Jun 1 17:47:54 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
Comment 30 Prarit Bhargava 2006-06-16 14:40:42 UTC
Mike, I assume you loaded that on demand (ie, by using modprobe/lsmod)? P.
Comment 32 Red Hat Bugzilla 2006-08-10 22:35:03 UTC
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2006-0575.html