Latest working kernel version: 2.6.25.10 Earliest failing kernel version: 2.6.26 Distribution: Fedora (also with stock kernel build) Hardware Environment: MacBook Pro (second generation) with 3GB RAM Software Environment: Fedora 9 x86_64 Problem Description: The new MMCONFIG detection code is not working on a second generation MacBook Pro under 2.6.26. The boot process hangs with... ACPI: bus type pci registered PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 255 PCI: Not using MMCONFIG PCI: Using configuration type 1 for base access ACPI: EC: EC description table is found, configuring boot EC ACPI: EC: non-query interrupt received switching to interrupt mode ACPI: BIOS_OSI (Linux) query ignored via DMI ACPI: Interpreter enabled ACPI: (supports S0 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 255 PCI: BIOS Bug: MCFG area at f0000000 is not reserved in ACPI motherboard resources PCI: Not using MMCONFIG ACPI: EC:GPE=0x17, I/O: command/status=0x66, data=0x62 ACPI: EC: driver started in interrupt mode ACPI: PCI Root Bridge [PCI0] (0000:00) pci 0000:00:1f.0: quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO pci 0000:00:1f.0: quirk: region 0500-053f claimed by ICH6 GPIO This compares with the results reported on the linux-kernel mailing list for a Mac-Mini... ACPI: bus type pci registered PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255 PCI: MCFG area at e0000000 reserved in E820 PCI: Using MMCONFIG at e0000000 - efffffff PCI: Using configuration type 1 for base access ACPI: EC: EC description table is found, configuring boot EC ACPI: BIOS _OSI(Linux) query ignored via DMI ACPI: Interpreter enabled ACPI: (supports S0 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62 ACPI: EC: driver started in poll mode ACPI: PCI Root Bridge [PCI0] (0000:00) pci 0000:00:1f.0: quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO pci 0000:00:1f.0: quirk: region 0500-053f claimed by ICH6 GPIO PCI: Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [...] The critical difference is that on a 2nd generation MacBook Pro, we see... PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 255 PCI: Not using MMCONFIG instead of... PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255 PCI: MCFG area at e0000000 reserved in E820 PCI: Using MMCONFIG at e0000000 - efffffff seen on a Mac-Mini. Could the failure be related to higher base address on the MacBook Pro (which has 3GB)? Any suggestions on how to debug this further would be most welcome. Steps to reproduce: Installed Fedora 9 x86_64 Built and installed stock unpatched 2.6.26 kernel. Same bug is seen in Fedora's 2.6.26-131 kernel srpm built under Fedora 9.
Marking as a regression.
> Latest working kernel version: 2.6.25.10 Can you please provide the boot log for this kernel on the MacBook Pro (second generation). The Mac-Mini one is not really helpful. > PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 255 > PCI: BIOS Bug: MCFG area at f0000000 is not reserved in ACPI motherboard > resources This looks like the real problem.
How can I generate a boot log when the boot process hangs? The first log section in the description of the bug is all of the boot information that I see. FYI, the use of pci=noacpi has no effect on the boot hang. I haven't had any luck finding a vga=XXX setting that would decrease the font size and let me see more of the boot messages. However I think I am seeing the critical ones starting with ACPI: bus type pci registered
Is this possibly due to the fact that I have 3 GB of ram installed? Is there any kernel options that would fake out the kernel to believe the machine has less than 3 GB (to avoid having to physically remove the ram)?
> Is this possibly due to the fact that I have 3 GB of ram installed? Is there > any kernel options that would fake out the kernel to believe the machine has > less than 3 GB (to avoid having to physically remove the ram)? mem=2G should do the trick
In an attempt to figure out why MMCONFIG is not in use on a MacBook Pro v2 under 2.6.26-git2, I applied the following patch... --- arch/x86/kernel/e820.c.org 2008-07-16 00:00:18.000000000 -0400 +++ arch/x86/kernel/e820.c 2008-07-16 01:00:57.000000000 -0400 @@ -87,10 +87,22 @@ struct e820entry *ei = &e820.map[i]; if (type && ei->type != type) + { + printk(KERN_ERR "%d conflict for type %u vs %u in map\n", i, type, e820.map[i].type); continue; + } /* is the region (part) in overlap with the current region ?*/ if (ei->addr >= end || ei->addr + ei->size <= start) + { + printk(KERN_ERR "%d addr %016Lx addr+size %016Lx start %016Lx end %016Lx \n", i, + (unsigned long long) e820.map[i].addr, + (unsigned long long) + (e820.map[i].addr + e820.map[i].size), + (unsigned long long) start, + (unsigned long long) end); + continue; + } /* if the region is at the beginning of <start,end> we move * start to the end of the region since it's ok until there This produced the following output when booting the 2.6.26-git2 kernel... PCI: BIOS Bug: MCFG area at f00000000 is not reserved in ACPI motherboard resources. 0 conflict for type 2 vs 1 in map 1 addr 000000000009fc00 addr+size 00000000000a0000 start 00000000f0000000 end 00000000ffffffff 2 addr 00000000000e0000 addr+size 0000000000100000 start 00000000f0000000 end 00000000ffffffff 3 conflict for type 2 vs 1 in map 4 conflict for type 2 vs 4 in map 5 conflict for type 2 vs 3 in map 6 conflict for type 2 vs 4 in map 7 conflict for type 2 vs 3 in map 8 addr 00000000bff00000 addr+size 00000000c0000000 start 00000000f0000000 end 00000000ffffffff At this point the call to e820_all_mapped() must be returning 0 because start wasn't greater than end. Let me know if I can add any other printk's to help debug this problem of MMCONFIG not starting up.
Created attachment 16831 [details] dmesg file from successful linux 2.6.25.10 boot I am attaching the dmesg file from a booting linux 2.6.25.10 on the same MacBook Pro v2 which fails to boot 2.6.26.
Created attachment 16851 [details] dmesg file for linux 2.6.25.10 boot with apic=verbose
Created attachment 16853 [details] lspci -vvxxx output from under 2.6.25.10 on MacBook Pro v2
Using the debug patches and your mmconfig patch as well as the kernel options 'debug initcall_debug apic=verbose pci=routeirq", I see the following messages that don't scroll off screen... PCI: 0000:00:1f.1 reg 10 io port: [ 40d8, 40df] PCI: 0000:00:1f.1 reg 14 io port: [ 40ec, 40ef] PCI: 0000:00:1f.1 reg 18 io port: [ 40d0, 40d7] PCI: 0000:00:1f.1 reg 1c io port: [ 40e8, 40eb] PCI: 0000:00:1f.1 reg 20 io port: [ 40b0, 40bf] pci 0000:00.1f.1: calling pci_fixup_transparent_bridge+0x0/0x2a PCI: Found 0000:00:1f.2 [8086/27c4] 000101 00 PCI: 0000:00:1f.2 reg 10 io port: [ 40c8, 40cf] PCI: 0000:00:1f.2 reg 14 io port: [ 40e4, 40e7] PCI: 0000:00:1f.2 reg 18 io port: [ 40c0, 40c7] PCI: 0000:00:1f.2 reg 1c io port: [ 40e0, 40e3] PCI: 0000:00:1f.2 reg 20 io port: [ 40a0, 40af] PCI: 0000:00:1f.2 reg 24 32bit mmio: [d8405000, d84053ff] pci: 0000:00:1f.2 calling pci_fixup_transparent_bridge+0x0/0x2a PCI: Found 0000:00:1f.3 [8086/27da] 000c05 00 PCI: 0000:00:1f.3 reg 20 io port: [ efa0, efbf] PCI: 0000:00:1f.3: calling pci_fixup_transparent_bridge+0x0/0x2a PCI: Fixups for bus 0000:00 PCI: Scanning behind PCI bridge 0000:00:01.0, config 010100, pass 0 PCI: Scanning bus 0000:01 PCI: Found 0000:01:00.0 [1002/71c5] 000300 00 PCI: 0000:00:01:00.0 reg 10 32bit mmio: [c0000000, cfffffff] PCI: 0000:00:01:00.0 reg 14 io port: [ 3000, 30ff] PCI: 0000:00:01:00.0 reg 18 32bit mmio: [d8300000, d830ffff] ...at which point the boot freezes.
Created attachment 16864 [details] .config used for linux 2.6.26 kernel builds on MacBookPro This config file was generated from the .config file created by the Fedora development kernel-2.6.26-136 srpm and used with 'make oldconfig'.
please check if the problem still happen with current mainline or tip/master.
Closing stale bug