Bug 11087
| Summary: | MMCONFIG isn't used under 2.6.26 on second generation MacBook Pro | ||
|---|---|---|---|
| Product: | Platform Specific/Hardware | Reporter: | Jack Howarth (howarth) |
| Component: | x86-64 | Assignee: | platform_x86_64 (platform_x86_64) |
| Status: | CLOSED INSUFFICIENT_DATA | ||
| Severity: | high | CC: | alan, mingo, yhlu.kernel |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.26 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
dmesg file from successful linux 2.6.25.10 boot
dmesg file for linux 2.6.25.10 boot with apic=verbose lspci -vvxxx output from under 2.6.25.10 on MacBook Pro v2 .config used for linux 2.6.26 kernel builds on MacBookPro |
||
|
Description
Jack Howarth
2008-07-14 19:40:42 UTC
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 |