On 11/29/2010 01:32 PM, Bjorn Helgaas wrote: > > Oops, egg on my face. In this case, there *is* an ACPI INT0800 device > at 0xff000000-0xffffffff, which should prevent us from allocating that > space for anything else. Only problem is, we IGNORE that useful bit of > information. > Eep... why? >> It is certainly reasonable to block off the last chunk of the 32-bit >> address space. Some systems double-decode it to avoid issues with >> A20M#, so I would argue that we should avoid at least 2 MiB. >> >> As far as discovering them from the BIOS, there is a way to do it -- >> E820. This is a fallback for the case where the BIOS has plain and >> simply failed to provide it, and so a heuristic is probably the best we >> can do. Probing is extremely unsafe. > > I think it's clearly a bug that Linux ignores ACPI resource information > (except PNP0C01/PNP0C02 motherboard devices). If we fix that bug, it > will fix Matthew's 2530p. I would definitely agree with that. > We might still want a patch like this current one because it could > work around some BIOS defects, and because I think it's too late to > fix the ACPI resource problem for .37. But I'm not convinced we > should reserve more than Windows does, because that may keep us from > discovering other important Linux problems. I'm not so sure about that... it feels like a pretty weak argument that we might work on some machines even though our code isn't perfect. -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
