Bug 7908 - Only one CPU detected on Tyan h1000E
Only one CPU detected on Tyan h1000E
Product: ACPI
Classification: Unclassified
Component: Config-Processors
i386 Linux
: P2 normal
Assigned To: Len Brown
Depends on:
  Show dependency treegraph
Reported: 2007-01-31 03:13 UTC by Jan "Yenya" Kasprzak
Modified: 2007-06-05 01:19 UTC (History)
2 users (show)

See Also:
Kernel Version:, 2.6.20-rc6
Tree: Mainline
Regression: ---

Dmesg of the 2.6.20-rc6 kernel (19.16 KB, text/plain)
2007-01-31 03:16 UTC, Jan "Yenya" Kasprzak
acpidump output (62.31 KB, text/plain)
2007-01-31 03:30 UTC, Jan "Yenya" Kasprzak
Kernel config (2.6.20-rc6) (34.42 KB, text/plain)
2007-03-09 03:44 UTC, Jan "Yenya" Kasprzak
dmidecode output (17.18 KB, text/plain)
2007-03-09 05:21 UTC, Jan "Yenya" Kasprzak

Description Jan "Yenya" Kasprzak 2007-01-31 03:13:26 UTC
Most recent kernel where this bug did *NOT* occur: N/A
Distribution: Fedora 6
Hardware Environment: Tyan h1000E, 3 GB RAM, 2x Opteron 2210 (4 cores total)
Software Environment: BIOS rev. 1.03
Problem Description:
The kernel cannot detect multiple processors and starts in UP mode.
I will attach dmesg and acpidump.

References: my original mail to lkml:
Comment 1 Jan "Yenya" Kasprzak 2007-01-31 03:16:32 UTC
Created attachment 10239 [details]
Dmesg of the 2.6.20-rc6 kernel
Comment 2 Jan "Yenya" Kasprzak 2007-01-31 03:30:52 UTC
Created attachment 10240 [details]
acpidump output

Note: I've got the following while running acpidump:

$ ./acpidump >/tmp/acpidump-h1000E.txt
Wrong checksum for generic table!
Comment 3 Len Brown 2007-03-09 01:15:55 UTC
ACPI: RSDP (v002 ACPIAM                                ) @ 0x00000000000f7700
ACPI: XSDT (v001 A M I  OEMXSDT  0x10000605 MSFT 0x00000097) @ 
ACPI: FADT (v003 A M I  OEMFACP  0x10000605 MSFT 0x00000097) @ 
ACPI: OEMB (v001 A M I  AMI_OEM  0x10000605 MSFT 0x00000097) @ 
ACPI: SRAT (v001 AMD    HAMMER   0x00000001 AMD  0x00000001) @ 
ACPI: SSDT (v001 A M I  POWERNOW 0x00000001 AMD  0x00000001) @ 
ACPI: DSDT (v001  0AAAA 0AAAA000 0x00000000 INTL 0x02002026) @ 

No APIC/MADT above, which is what Linux uses to enumerate processors...

    Scope (\_PR)
        Processor (P001, 0x01, 0x00000510, 0x06) {}
        Processor (P002, 0x02, 0x00000000, 0x00) {}
        Processor (P003, 0x03, 0x00000000, 0x00) {}
        Processor (P004, 0x04, 0x00000000, 0x00) {}
        Alias (P001, CPU1)
        Alias (P002, CPU2)
        Alias (P003, CPU3)
        Alias (P004, CPU4)

The AML seems to have a concept of 4 processors...

BIOS SETUP indicates that the BIOS sees 4 processors?

I'd say that this is an example of Linux needing to enumerate
processors via the ACPI name space rather than the MADT.
But it makes no sense that the MADT is not visible either --
because such a system should surely be running in IOAPIC mode...

It will be intersting to see if you can boot Windows and
if that shows all 4 processors (and IOAPIC use).

I assume that this has happened for every version of Linux tested,
including the distro install CD?

Please attach the .config

might be intersting to see also the output from dmidecode
Comment 4 Jan "Yenya" Kasprzak 2007-03-09 03:43:17 UTC
Yes, BIOS setup reports 4 cores.

I will have an identical server for testing soon, so I may do more tests then
(such as booting Windows).

The same problem had the distro CD (Fedora 6/x86_64) and the vanilla kernel
(2.6.19 and 2.6.20-rc6 at that time).

I will attach the .config and dmidecode.
Comment 5 Jan "Yenya" Kasprzak 2007-03-09 03:44:23 UTC
Created attachment 10665 [details]
Kernel config (2.6.20-rc6)
Comment 6 Jan "Yenya" Kasprzak 2007-03-09 05:21:58 UTC
Created attachment 10666 [details]
dmidecode output
Comment 7 Jan "Yenya" Kasprzak 2007-03-28 03:25:08 UTC
OK, another server with h1000E has arrived, so I've got a chance to tweak BIOS
settings. It turned out that after the following change in the BIOS settings
Linux can see all four cores:

Chipset -> HT1000 SouthBridge Configuration -> Hide XIOAPIC PCI Functions

I have set it to [Enabled], and all four cores are visible now (as well as
IO-APIC in /proc/interrupts). I have verified that setting it back to [Disabled]
 leads to the situation described in the original report (only one core, XT-PIC
in /proc/interrupts).

This is on a test server, I will try this option on the production server
probably during this weekend.

So, provided that XIOAPIC is something we don't want to support, I suggest to
close this bug as INVALID. Len, thanks for your input!
Comment 8 Alexey Starikovskiy 2007-06-05 01:19:35 UTC
Thanks for report!

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