On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> Yinghai Lu wrote:
> > On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> >> Thomas Gleixner wrote:
> >>> On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
> Yinghai Lu wrote:
> > No!
> >
> > MMCONFIG will not work
On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> Yinghai Lu wrote:
> > On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> >> Thomas Gleixner wrote:
> >>> On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
> Yinghai Lu wrote:
> > No!
> >
> > MMCONFIG will not work
Yinghai Lu wrote:
On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
Thomas Gleixner wrote:
On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
Yinghai Lu wrote:
No!
MMCONFIG will not work with acpi=off any more.
I don't think this is unreasonable. The ACPI MCFG table is how we are
Yinghai Lu wrote:
>>> We all know how correct ACPI tables are. Specifications are nice,
>>> reality tells a different story.
>> MMCONFIG can't be used without ACPI in any case unless we know where the
>> table is using chipset-specific knowledge (i.e. reading the registers
>> directly). Doing tha
On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> Yinghai Lu wrote:
> > No!
> >
> > MMCONFIG will not work with acpi=off any more.
>
> I don't think this is unreasonable. The ACPI MCFG table is how we are
> supposed to learn about the area in the first place. If we can't get the
> table locat
On 9/22/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> Thomas Gleixner wrote:
> > On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
> >> Yinghai Lu wrote:
> >>> No!
> >>>
> >>> MMCONFIG will not work with acpi=off any more.
> >> I don't think this is unreasonable. The ACPI MCFG table is how
Thomas Gleixner wrote:
On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
Yinghai Lu wrote:
No!
MMCONFIG will not work with acpi=off any more.
I don't think this is unreasonable. The ACPI MCFG table is how we are
supposed to learn about the area in the first place. If we can't get the
On Sat, 2007-09-22 at 10:28 -0600, Robert Hancock wrote:
> Yinghai Lu wrote:
> > No!
> >
> > MMCONFIG will not work with acpi=off any more.
>
> I don't think this is unreasonable. The ACPI MCFG table is how we are
> supposed to learn about the area in the first place. If we can't get the
> tabl
Yinghai Lu wrote:
No!
MMCONFIG will not work with acpi=off any more.
I don't think this is unreasonable. The ACPI MCFG table is how we are
supposed to learn about the area in the first place. If we can't get the
table location via an approved mechanism, and can't validate it doesn't
overlap
On 9/21/07, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> On 9/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > From: Robert Hancock <[EMAIL PROTECTED]>
> >
> > This path adds validation of the MMCONFIG table against the ACPI reserved
> > motherboard resources. If the MMCONFIG table is found to be r
On 9/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> From: Robert Hancock <[EMAIL PROTECTED]>
>
> 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. T
From: Robert Hancock <[EMAIL PROTECTED]>
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 developer
12 matches
Mail list logo
