On 09/15/2010 03:44 PM, Bjorn Helgaas wrote: > > I'd like to do that, but I don't see a good way to do it yet. > > We saw the problem on a T3500, a T3400, and a T4500, and I'm sure there > are others. So I don't know how to identify the affected machines. > > And I don't know how to identify the invalid ranges, because I suspect > it depends on the memory size. I think it would be quite unusual for > a window to start 1MB under the nice 256MB boundary, but I'm not sure > I'm ready to say that's always illegal. > > On these machines, the [mem 0xbff00000-0xbfffffff] area is actually > reported as reserved in the E820 map, and I first thought we could > simply rely on that. But I'm not really comfortable with that either, > because I don't think there's a dependable relationship between those > E820 entries and ACPI and PCI devices. For one thing, I experimented > with Windows, and it happily places PCI devices in reserved areas, > and I think we're likely to trip over more BIOS bugs if we rely on > something Windows doesn't. > > I suspect Windows would blow up, too, if we could somehow fill up the > rest of the window and force it to allocate the bottom. But since > it's only a 1MB area, I think that would be very difficult to do > unless there's some way to tweak PCI BARs before booting Windows. > If we put PCI devices in E820 RESERVED areas that's a bug, plain and simple. We should absolutely not doing so! To some degree I don't care if Windows does or not ... that is the documented mechanism for reserving address space, and we should respect that. Furthermore, we use the same mechanism internally for reserving address space. Furthermore, the only potentially bad outcome is reserving excessive address space, which is in general safer than the opposite. So let's just fix this. -hpa -- 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
