On 04/07/2010 02:06 PM, Bjorn Helgaas wrote: > > Currently, we only reserve the legacy VGA area [mem 0xa0000-0xbffff] on > x86_32. But this legacy area is also used on x86_64, so this patch > reserves it there, too. > > If we don't reserve it, we may mistakenly move a PCI device to that area, > as we did here: > > pci_root PNP0A03:00: host bridge window [mem 0xff980800-0xff980bff] > pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff] > pci 0000:00:1f.2: no compatible bridge window for [mem 0xff970000-0xff9707ff] > pci 0000:00:1f.2: BAR 5: assigned [mem 0x000a0000-0x000a07ff] > > as reported by Andy Isaacson at http://lkml.org/lkml/2010/4/6/375 > > I think the fact that the BAR is not within a host bridge window is a > BIOS defect, and it's now more visible because we have "pci=use_crs" as > the default. Using "pci=nocrs" is a workaround, because then we won't > attempt to move the device. that doesn't look right. It seem another thread, erission has one model without VGA, and they use that area for other device MMIO. current for 64bit, We remove [0xa0000, 0x100000) from e820 map if those area is E820_RAM. in e820_reserve_resources(), kernel will reserve range < 1M according to e820 map. that is before pci BAR is claimed. or you can add boot_params.screen_info.orig_video_isVGA == 1 or double check scan pci tree to see if video is there or not YH -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
