Bug 184583 - Kernel should export number and state of local APICs
Summary: Kernel should export number and state of local APICs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Prarit Bhargava
QA Contact: Brian Brock
URL:
Whiteboard:
: 200746 (view as bug list)
Depends On:
Blocks: 171930 181411
TreeView+ depends on / blocked
 
Reported: 2006-03-09 22:43 UTC by Peter Jones
Modified: 2007-11-30 22:07 UTC (History)
4 users (show)

Fixed In Version: RHSA-2006-0575
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-10 22:35:03 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2006:0575 0 normal SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 4 Update 4 2006-08-10 04:00:00 UTC

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


Comment 33 Prarit Bhargava 2006-09-18 17:23:19 UTC
*** 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.