Bug 7908 - Only one CPU detected on Tyan h1000E
Only one CPU detected on Tyan h1000E
Status: REJECTED INVALID
Product: ACPI
Classification: Unclassified
Component: Config-Processors
i386 Linux
: P2 normal
Assigned To: Len Brown
:
Depends on:
Blocks:
  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.19.2, 2.6.20-rc6
Tree: Mainline
Regression: ---


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

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:
http://lkml.org/lkml/2007/1/30/397
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
dmesg:
ACPI: RSDP (v002 ACPIAM                                ) @ 0x00000000000f7700
ACPI: XSDT (v001 A M I  OEMXSDT  0x10000605 MSFT 0x00000097) @ 
0x00000000bfff0100
ACPI: FADT (v003 A M I  OEMFACP  0x10000605 MSFT 0x00000097) @ 
0x00000000bfff0290
ACPI: OEMB (v001 A M I  AMI_OEM  0x10000605 MSFT 0x00000097) @ 
0x00000000bfffe040
ACPI: SRAT (v001 AMD    HAMMER   0x00000001 AMD  0x00000001) @ 
0x00000000bfff3420
ACPI: SSDT (v001 A M I  POWERNOW 0x00000001 AMD  0x00000001) @ 
0x00000000bfff34e0
ACPI: DSDT (v001  0AAAA 0AAAA000 0x00000000 INTL 0x02002026) @ 
0x0000000000000000

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

DSDT:
    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.