2.6.32.1 kernel unable to use more than 2 of 16 CPUs on Intel E5540 (i7)

2.6.32.1 kernel unable to use more than 2 of 16 CPUs on Intel E5540 (i7)

[Kurt Newman]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm posting here to get a bit of help to figure out this issue, or find
advice on a better mailing list or location to post this question.

The linux-smp and linux-config lists don't get many posts, while
linux-admin hasn't yielded much (perceived) help.

- ------------------------

My problem and question is:

I've tried 2.6.31.13 and 2.6.32.1, but none of these compilations find
all 16 CPUs on this E5540 (2 cpus, 4 cores each, 2 HT threads each).
However, using these same custom kernels on an Intel 5130, shows all 4
"cpus" (2 cpus, 2 cores each, no HT).  I've also tried older kernels
from common distros that find all 16 cpus just fine.  I'm guessing they
patched in support for additional hardware.

Q: What am I doing wrong, that prevents this kernel from seeing all
CPUs?  Or, could someone point me in the right direction?

- ------------------------

Relevant background information:

1) I am limited to a 32-bit OS and an older kernel because of some
software limitations.

2) While I've enabled CONFIG_HOTPLUG_CPU, I've confirmed that I'm not
passing any kernel args that would limit what is used (e.g. maxcpus=).

3) From the things I've looked at (e.g. /sys), the kernel seems to know
that there's 16 CPUs, but will only use 2.

4) I'm attaching my kernel config, dmesg output, /sys output, and
/proc/cpuinfo output to help.  NOTE: I've tried using CONFIG_MCORE2 and
CONFIG_M686, neither of these changes anything.

Thank you for your time,
Kurt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwj0eQACgkQ0rcig5YkL7E3vgCghDRO1VXMh9kap1yUhBoOSw7I
UV8An35Zqt7cf3v5vJqKrh43lbYXyqVv
=VLnf
-----END PGP SIGNATURE-----

[-- Attachment #2: config-2.6.32.1_GDG01.gz --]
[-- Type: application/x-gzip, Size: 15245 bytes --]

[-- Attachment #3: cpuinfo-2.6.32.1_GDG01.gz --]
[-- Type: application/x-gzip, Size: 597 bytes --]

[-- Attachment #4: dmesg-2.6.32.1_GDG01.gz --]
[-- Type: application/x-gzip, Size: 15086 bytes --]

[-- Attachment #5: sys-devices-2.6.32.1_GDG01.gz --]
[-- Type: application/x-gzip, Size: 191 bytes --]

Re: 2.6.32.1 kernel unable to use more than 2 of 16 CPUs on Intel E5540 (i7)

[Roland Dreier]

Your config seems to have CONFIG_PM and therefore CONFIG_ACPI disabled.
So the kernel is relying on mptable information.  Unsurprisingly on a
modern system, that info is probably broken -- since everything would
have been tested with ACPI.

Try turning on CONFIG_ACPI and see if that helps at all.
-- 
Roland Dreier <rolandd@cisco.com> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

Re: 2.6.32.1 kernel unable to use more than 2 of 16 CPUs on Intel E5540 (i7)

[Robert Hancock]

On 06/24/2010 04:05 PM, Roland Dreier wrote:
> Your config seems to have CONFIG_PM and therefore CONFIG_ACPI disabled.
> So the kernel is relying on mptable information.  Unsurprisingly on a
> modern system, that info is probably broken -- since everything would
> have been tested with ACPI.
>
> Try turning on CONFIG_ACPI and see if that helps at all.

Indeed, not having ACPI enabled will prevent any multi-core CPU 
detection. ACPI really has to be enabled for any modern x86 system to 
work properly.

I'd think that the CONFIG_ACPI really should be defaulted on more 
strongly - maybe force it on if CONFIG_EMBEDDED isn't set or something..

Re: 2.6.32.1 kernel unable to use more than 2 of 16 CPUs on Intel E5540 (i7)

[Kurt Newman]

Roland Dreier wrote:
> Your config seems to have CONFIG_PM and therefore CONFIG_ACPI disabled.
> So the kernel is relying on mptable information.  Unsurprisingly on a
> modern system, that info is probably broken -- since everything would
> have been tested with ACPI.
> 
> Try turning on CONFIG_ACPI and see if that helps at all.

Turning on ACPI solved the problem.  I don't understand why ACPI needs
to be turned on, but after reading the power management ldp it confirms
what you said.  I just didn't think that this would have mattered.

Thanks for the help,
Kurt



For anyone else with this problem, here's something to read:

Some SMP system manufacturers may have omitted the pre-ACPI tables used
for SMP configurations. In this case, ACPI is required.

If you have a newer system that supports Hyper-Threading, you will need
to enable ACPI (and, of course, SMP). Without it, your Linux system may
be unable to discover and initialize all of the virtual processors.

IA64 machines require ACPI as well. Additionally, NUMA servers are
starting to require it for proper initialization.

Source: http://tldp.org/HOWTO/Battery-Powered/powermgm.html#HYPERTHREAD