Bug 184583 - Kernel should export number and state of local APICs
Kernel should export number and state of local APICs
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Prarit Bhargava
Brian Brock
: 200746 (view as bug list)
Depends On:
Blocks: 171930 181411
  Show dependency treegraph
Reported: 2006-03-09 17:43 EST by Peter Jones
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHSA-2006-0575
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-10 18:35:03 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 Peter Jones 2006-03-09 17:43:24 EST
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 13:17:20 EDT
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 14:41:54 EDT
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 ...

Comment 22 Jason Baron 2006-05-08 11:34:19 EDT
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 13:39:09 EDT
I only see 35.2 there... what's the story?
Comment 24 Peter Jones 2006-05-08 13:39:51 EDT
Oh, nevermind, I see what you're saying.
Comment 26 Jason Baron 2006-05-23 17:32:00 EDT
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 10:33:46 EDT
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 10:40:42 EDT

I assume you loaded that on demand (ie, by using modprobe/lsmod)?

Comment 32 Red Hat Bugzilla 2006-08-10 18:35:03 EDT
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.

Comment 33 Prarit Bhargava 2006-09-18 13:23:19 EDT
*** Bug 200746 has been marked as a duplicate of this bug. ***

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