Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 455200 - kernel-2.6.26-0.131.rc9.git9.fc10.x86_64 doesn't boot on MacBook Pro
Summary: kernel-2.6.26-0.131.rc9.git9.fc10.x86_64 doesn't boot on MacBook Pro
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-13 23:26 UTC by Need Real Name
Modified: 2008-10-28 19:52 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-28 19:52:02 UTC


Attachments (Terms of Use)

Description Need Real Name 2008-07-13 23:26:23 UTC
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.

Comment 1 Dave Jones 2008-07-13 23:38:46 UTC
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.

Comment 2 Need Real Name 2008-07-14 13:39:11 UTC
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.

Comment 3 Need Real Name 2008-07-14 13:44:21 UTC
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. 

Comment 4 Need Real Name 2008-07-14 13:52:37 UTC
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?

Comment 5 Need Real Name 2008-07-14 21:21:01 UTC
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.

Comment 6 Need Real Name 2008-07-14 23:36:24 UTC
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?

Comment 7 Need Real Name 2008-07-15 02:04:25 UTC
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?

Comment 8 Need Real Name 2008-07-15 02:27:07 UTC
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.

Comment 9 Need Real Name 2008-07-15 02:42:28 UTC
Filed linux kernel bugzilla report on this issue...

http://bugzilla.kernel.org/show_bug.cgi?id=11087

Comment 10 Need Real Name 2008-07-15 23:04:43 UTC
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.

Comment 11 Need Real Name 2008-07-18 03:24:58 UTC
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.

Comment 12 Need Real Name 2008-07-19 22:20:28 UTC
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.

Comment 13 Need Real Name 2008-07-27 19:13:11 UTC
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.

Comment 14 Jeff Cook 2008-09-22 16:15:37 UTC
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.

Comment 15 Christopher D. Stover 2008-10-25 17:40:13 UTC
Is this bug fixed in new kernels or does this need to remain open -> assigned?

Comment 16 Christopher D. Stover 2008-10-28 19:52:02 UTC
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.


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