LKML Archive on
help / color / mirror / Atom feed
From: Robert Hancock <>
To: Andi Kleen <>
Cc: Yinghai Lu <Yinghai.Lu@Sun.COM>, Ingo Molnar <>,
	Andrew Morton <>,
	Greg KH <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH 1/5] x86: validate against acpi motherboard resources
Date: Mon, 18 Feb 2008 14:26:07 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Andi Kleen wrote:
>> With just this patch you will have this problem. You need either the 
>> patch to disable decode during BAR sizing,
> Isn't that one already merged?
> I remember the BAR decoding patch did help with at least one
> of the original failures (there were multiple ones iirc0) 

I believe that one's been dropped as it's not needed if we don't use 
MMCONFIG for non-extended accesses (like we use during BAR sizing). 
(Though, there may still be a case where it's needed, see below.)

> If someone points me to all the patches needed or a tree who 
> has them all applied I can give it a quick spin on the boxes I have here.
> One of the systems where it originally failed I don't have anymore
> though.
>> or the patch to use MMCONFIG 
>> for extended config space only, if you don't have them already.
> That would mean it would boot, but anything that uses extended config
> space would fail. While not as catastrophic as before I'm not sure
> it's that great either. At least there would be still breakage,
> but much more subtle ones.

The only issue on those boards is that since certain device BARs will 
overlap the MMCONFIG area during BAR sizing, if you use MMCONFIG to do 
the accesses used during BAR sizing itself, it'll fail. If you use conf1 
to do the BAR sizing then that problem doesn't happen.

However, I suppose there could be an issue if you hotplugged a device 
(causing BAR sizing) once you'd booted, while extended config space was 
in use on another device. The BAR sizing wouldn't fail, but the guy 
using extended config space would since he's actually reading 
from/writing into the BAR of the device being sized instead of the 
MMCONFIG area. That wouldn't be good. The disable-decode-during-sizing 
patch would avoid that problem.

  reply	other threads:[~2008-02-18 20:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.LKjQjbOw482S/>
     [not found] ` <>
2008-02-16  5:52   ` Robert Hancock
2008-02-16  6:09     ` Yinghai Lu
2008-02-17 16:42       ` Ingo Molnar
2008-02-18 11:31     ` Andi Kleen
2008-02-18 20:26       ` Robert Hancock [this message]
2008-02-15  9:27 Yinghai Lu
2008-02-15 11:11 ` Andi Kleen
2008-02-15 18:46   ` Yinghai Lu
2008-02-15 22:11   ` Yinghai Lu
2008-02-15 22:16     ` Yinghai Lu
2008-02-17 14:06 ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \
    --cc=Yinghai.Lu@Sun.COM \ \ \ \ \ \
    --subject='Re: [PATCH 1/5] x86: validate against acpi motherboard resources' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).