Bug 184583

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>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0	CC:	jbaron, jparadis, prarit, tao
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	RHSA-2006-0575	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-08-10 22:35:03 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:
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

Comment 33 Prarit Bhargava 2006-09-18 17:23:19 UTC

*** Bug 200746 has been marked as a duplicate of this bug. ***