Jesse Barnes wrote:
On Sunday, April 29, 2007, Robert Hancock wrote:
Problem is that even if we read the MMCONFIG table location from the
hardware registers, that doesn't mean we can trust the result. It could
be that the BIOS hasn't lied about where it put the table, it just stuck
it someplace
On Sunday, April 29, 2007, Robert Hancock wrote:
> Problem is that even if we read the MMCONFIG table location from the
> hardware registers, that doesn't mean we can trust the result. It could
> be that the BIOS hasn't lied about where it put the table, it just stuck
> it someplace completely
Andi Kleen wrote:
I tried adapting a patch by Rajesh Shah to do this for current kernels:
The Intel patches checked against ACPI which also didn't work in all cases.
You're right the e820 check is overzealous and has a lot of false positives,
but it is the only generic way we know right now
>
> I tried adapting a patch by Rajesh Shah to do this for current kernels:
The Intel patches checked against ACPI which also didn't work in all cases.
You're right the e820 check is overzealous and has a lot of false positives,
but it is the only generic way we know right now to handle a
I tried adapting a patch by Rajesh Shah to do this for current kernels:
The Intel patches checked against ACPI which also didn't work in all cases.
You're right the e820 check is overzealous and has a lot of false positives,
but it is the only generic way we know right now to handle a common
Andi Kleen wrote:
I tried adapting a patch by Rajesh Shah to do this for current kernels:
The Intel patches checked against ACPI which also didn't work in all cases.
You're right the e820 check is overzealous and has a lot of false positives,
but it is the only generic way we know right now
On Sunday, April 29, 2007, Robert Hancock wrote:
Problem is that even if we read the MMCONFIG table location from the
hardware registers, that doesn't mean we can trust the result. It could
be that the BIOS hasn't lied about where it put the table, it just stuck
it someplace completely
Jesse Barnes wrote:
On Sunday, April 29, 2007, Robert Hancock wrote:
Problem is that even if we read the MMCONFIG table location from the
hardware registers, that doesn't mean we can trust the result. It could
be that the BIOS hasn't lied about where it put the table, it just stuck
it someplace
Chuck Ebbert wrote:
Robert Hancock wrote:
I've seen a lot of systems (including brand new Xeon-based servers from
IBM and HP) that output messages on boot like:
PCI: BIOS Bug: MCFG area at f000 is not E820-reserved
PCI: Not using MMCONFIG.
So Microsoft is explicitly telling the BIOS
Chuck Ebbert wrote:
Robert Hancock wrote:
I've seen a lot of systems (including brand new Xeon-based servers from
IBM and HP) that output messages on boot like:
PCI: BIOS Bug: MCFG area at f000 is not E820-reserved
PCI: Not using MMCONFIG.
So Microsoft is explicitly telling the BIOS
Robert Hancock wrote:
> I've seen a lot of systems (including brand new Xeon-based servers from
> IBM and HP) that output messages on boot like:
>
> PCI: BIOS Bug: MCFG area at f000 is not E820-reserved
> PCI: Not using MMCONFIG.
>
>
> So Microsoft is explicitly telling the BIOS developers
Robert Hancock wrote:
I've seen a lot of systems (including brand new Xeon-based servers from
IBM and HP) that output messages on boot like:
PCI: BIOS Bug: MCFG area at f000 is not E820-reserved
PCI: Not using MMCONFIG.
So Microsoft is explicitly telling the BIOS developers that
I've seen a lot of systems (including brand new Xeon-based servers from
IBM and HP) that output messages on boot like:
PCI: BIOS Bug: MCFG area at f000 is not E820-reserved
PCI: Not using MMCONFIG.
As I understand it, this is sort of a sanity check mechanism to make
sure the MCFG address
I've seen a lot of systems (including brand new Xeon-based servers from
IBM and HP) that output messages on boot like:
PCI: BIOS Bug: MCFG area at f000 is not E820-reserved
PCI: Not using MMCONFIG.
As I understand it, this is sort of a sanity check mechanism to make
sure the MCFG address
14 matches
Mail list logo
