Description of problem: The current kernel-2.6.26-0.131.rc9.git9.fc10.x86_64 in the development branch is unable to boot a MacBook Pro. The kernel fails with an "PCI: Not Using MMCONFIG" error even though the .config for the kernel package indicates that it was built with mmconfig="y". Version-Release number of selected component (if applicable): kernel-2.6.26-0.131.rc9.git9.fc10.x86_64 How reproducible: Always. Steps to Reproduce: 1. Install FC9 and upgrade to the development repository. 2. Reboot under kernel-2.6.26-0.131.rc9.git9.fc10.x86_64 Actual results: The kernel fails to boot with the errors... PCI: Not Using MMCONFIG PCI: Bios Bug: MCFG area at f000000 is not reserved in ACPI motherboard resources. PCI: Not using MMCONFIG Expected results: I expected MMCONFIG to be used (since it is required by the MacBook Pro). Additional info: I can also reproduce this problem under Fedora 9 by building the srpm for kernel-2.6.26-0.131.rc9.git9.fc10 with the most current patch-2.6.26-rc9-git12.bz2. The same problem occurs when attempting to boot the resulting kernel under F9.
it shouldn't be required. booting with pci=mmconf will enable it, though I find it incredibly unlikely to be the reason you are unable to boot.
There is no pci=mmconf or pci=mmconfig AFAIK... only a pc=nommconfig to disable the feature. In any case, with quiet, this is what I see with a kernel-2.6.26-0.131.rc9.git12.fc10.x86_64 kernel (which is the same errors as with the current git9 in rawhide... 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 at which point the boot process hangs. I do recall reading somewhere that the EFI on Macintel required the use of MMCONFIG to boot so we shouldn't be surprised by the boot failure but rather focus on why MMCONFIG isn't being used.
For comparision, the same section in dmesg from a boot of kernel-2.6.25.10-86.fc9.x86_64 shows... ACPI: bus type pci registered PCI: Using MMCONFIG at f0000000 - ffffffff PCI: Using configuration type 1 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 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] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEGP._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP02._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP03._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 12 14 15) *11 ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 12 14 15) *11 ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 *11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 7 10 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 1 3 4 5 6 7 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 1 3 4 5 6 7 *10 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: bus type pnp registered ACPI: EC: non-query interrupt received, switching to interrupt mode pnp: PnP ACPI: found 9 devices ACPI: ACPI bus type pnp unregistered usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report NetLabel: Initializing ...etc.
I notice that 2.6.26 appears to be released now. Is there a particular directory on people.redhat.com where I might obtain test versions of the kernel 2.6.26 srpms?
I have confirmation that a stock 2.6.26 boots on a Mac-mini. I'll try the latest rawhide srpm for the kernel tonight. If that doesn't work, we may have to consider if any of the patches added to the stock kernel is breaking mmconfig.
I am seeing the same problem with the latest kernel-2.6.26-136 srpm built under Fedora 9. Can someone else try testing the 2.6.26 kernel rpm on a second generation MacBook Pro?
I am also seeing the problem with a build of the unpatched stock linux 2.6.26 sources built using the .config from the fedora rpm build and 'make oldconfig'. The boot always fails with... 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 Could one of the fedora developers try booting the 2.6.26 kernel on a second generation MacBook Pro?
For reference, a boot of 2.6.26 on a Mac-mini is reported as... 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] [...] ...so the problem appears to be that the new MMCONFIG code doesn't allow it to start up on certain Macintel hardware.
Filed linux kernel bugzilla report on this issue... http://bugzilla.kernel.org/show_bug.cgi?id=11087
I also find that if I download the current rawhide i386 boot.iso based on the 2.6.26 kernel, burn a cd and boot directly with the 'c' key to it, the same hang occurs when using the "linux rescue" mode of the boot image. Thus the problem effects both the i386 and x86_64 architectures.
This problem is triggered by the new PCIEASPM code in 2.6.26. Building the curent development srpm for 2.6.27-0.156.rc0.git4 with CONFIG_PCIEASPM unset in the config-generic file eliminates the freezes on booting a MacBook Pro v2.
The 2.6.26 kernels built with CONFIG_PCIEASPM can be booted on machines that are incompatible with the current aspm code by using the pcie_noaspm kernel option. Confirmed this works on a MacBook Pro v2.
This problem is due to the new ASPM support attempting to use pre-1.1 PCIe devices. Patches to prevent this from happening are available at... http://article.gmane.org/gmane.linux.kernel.pci/348 http://article.gmane.org/gmane.linux.kernel.pci/350 http://article.gmane.org/gmane.linux.kernel.pci/349 These patches follow the Microsoft Vista approach of disallowing ASPM on pre1.1 PCIe devices as well as adding an aspm=force option to override this.
Seeing this problem on my MacBook Pro v2 with the new kernel in Fedora 9, 2.6.26-29.fc9 which I just obtained with a yum update. Using all stable sources. Boot no longer complains about MMCONFIG, but offers PCI: BIOS Bug: MCFG area at f0000000 is not reserved in ACPI motherboard resources and hangs after informing that nash was starting. Using rEFIt 0.11.
Is this bug fixed in new kernels or does this need to remain open -> assigned?
Closing this as I have not seen comments from other users of MacBooks reporting this issue in newer bugs. Please reopen and assign if necessary.