Messages in this thread | | | Date | Mon, 11 Feb 2008 23:38:25 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] Change pci_raw_ops to pci_raw_read/write |
| |
* Andrew Morton <akpm@linux-foundation.org> wrote:
> > please check some updated patches in -mm that could be affected. > > hope it could save you some time > > > > x86-validate-against-acpi-motherboard-resources.patch > > x86-clear-pci_mmcfg_virt-when-mmcfg-get-rejected.patch > > x86-mmconf-enable-mcfg-early.patch > > x86_64-check-msr-to-get-mmconfig-for-amd-family-10h-opteron-v3.patch > > I have unhappy feelings here - the patches seem to be churning a bit > and when I last sent them to Greg and Ingo they received no apparent > response.
i actually carried them for a while and validate-against-acpi-motherboard-resources.patch got a fair bit of test time with positive results. So it has a clear ACK from me.
It's something that looks appealing:
| This path adds validation of the MMCONFIG table against the ACPI | reserved motherboard resources. If the MMCONFIG table is found to be | reserved in ACPI, we don't bother checking the E820 table. The PCI | Express firmware spec apparently tells BIOS developers that | reservation in ACPI is required and E820 reservation is optional, so | checking against ACPI first makes sense. Many BIOSes don't reserve | the MMCONFIG region in E820 even though it is perfectly functional, | the existing check needlessly disables MMCONFIG in these cases.
anything that isolates Linux from BIOS messups should be music to our ears.
i also think the mmconf-enable stuff for Barcelona stuff from Yinghai, albeit not particularly pretty, is probably good too for similar reasons. It makes the kernel boot with noacpi which is a good sign IMO.
I have testsystems that simply do not boot with ACPI turned off - and i have a testsystem that locks up hard if it takes an NMI in certain ACPI AML sequences ... Just Because.
So i'd ACK them just on general principle - earlier versions of the patches were carried in x86.git and caused no particular problems.
but ... then we got complaints from you that stuff collides and that such patches should be carried in your or Greg's tree, so we dropped them. And there was another 100 KLOC of x86 code to worry about ;-)
So i'd suggest to send those patches upstream, they are system enablers and they are at fundamental enough places to be apparent if they cause any breakage i think.
Ingo
| |