On Mon, 26 Apr 2010 11:34:36 -0700 Andy Isaacson <adi@xxxxxxxxxxxxx> wrote: > On Fri, Apr 23, 2010 at 05:05:24PM -0600, Bjorn Helgaas wrote: > > On Wednesday 21 April 2010 01:31:20 pm Andy Isaacson wrote: > > > On Tue, Apr 20, 2010 at 10:33:50PM -0700, Yinghai wrote: > > > > Update e820 at first, and later put them resource tree. > > > > Reserved that early, will not be allocated to unassigned PCI BAR > > > > > > > > v3: remove probe_roms() that is not needed, because whole range is reserved > > > > already > > > > > > Test booted this patch series on the problematic t3400, seems to work > > > fine. dmesg attached to bug 15744. > > > > Thanks for testing (again). I'm not confident that this series is > > going to be successful, so I started looking for other approaches. > > > > I can't reproduce the exact problem you're seeing, but in my > > kludged-up attempt, the patch below is enough to keep us from > > assigning the space below 1MB to a device. > > > > Would you guys (Andy & Andy, what a coincidence :-)) mind giving > > it a try? This is intended to work on top of current upstream, > > with no other patches required. > > > > Bjorn > > > > > > commit 7fb707eb97fdf6dc4fa4b127f127f8d00223afc7 > > Author: Bjorn Helgaas <bjorn.helgaas@xxxxxx> > > Date: Fri Apr 23 15:22:10 2010 -0600 > > > > x86/PCI: never allocate PCI MMIO resources below BIOS_END > > > > When we move a PCI device or assign resources to a device not configured > > by the BIOS, we want to avoid the BIOS region below 1MB. Note that if the > > BIOS places devices below 1MB, we leave them there. > > Works for me. dmesg at > https://bugzilla.kernel.org/attachment.cgi?id=26150 Great, thanks for testing. Applied this one to my for-linus tree. I still thing Yinghai's patches should go in as well (marking regions as busy seems like good housekeeping), but with this fixed they're a better fit for -next. Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- 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
