public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Rajesh Shah <rajesh.shah@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>,
	Brice Goglin <brice@myri.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] PCI extended conf space when MMCONFIG disabled because of e820
Date: Thu, 22 Jun 2006 00:32:19 +0200	[thread overview]
Message-ID: <200606220032.19388.ak@suse.de> (raw)
In-Reply-To: <20060621151942.A17228@unix-os.sc.intel.com>

On Thursday 22 June 2006 00:19, Rajesh Shah wrote:
> On Wed, Jun 14, 2006 at 11:47:57PM -0700, Arjan van de Ven wrote:
> > 
> > > We need to improve this "mmconfig disabled" anyhow. Having the extended
> > > config space unavailable on lots of machines is also far from a viable
> > > solution :)
> > 
> > it's unlikely to be many machines though.
> > 
> I just noticed today - this check killed PCI Express on 3 of the 4
> machines I normally use for testing.

What do you mean with killed PCI Express? PCI Express should
work even without extended config space, except error handling.

Error handling seems to be still a quite obscure feature,
not used by many people - so booting is more important than
supporting it. Still would be good to support it of course.

You're saying that you have lots of machines where the mmconfig
aperture is not fully reserved in e820?

Is it partially reserved (not for all busses) or not at all?


> Sure enough, the ACPI namespace for the "broken" machines lists
> the MMCFG resources as indicated above, and PCI Express works fine
> otherwise. I haven't looked yet whether it's possible to add this
> check in the code, have you looked into that option? I understand
> the PCI firmware spec is not necessarily the final authority on
> this, but a _lot_ of BIOS developers read that to figure out what
> to do...

If someone does a patch to double check it against the ACPI name space
I'm not opposed to let it overrule the e820 heuristic.

The point of this code is to pragmatically detect BIOS with obviously 
broken setups. It's not about standards lawyering.

-Andi
 

  reply	other threads:[~2006-06-21 22:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-14 21:07 [RFC] PCI extended conf space when MMCONFIG disabled because of e820 Brice Goglin
2006-06-14 21:09 ` Arjan van de Ven
2006-06-15  1:45   ` Andi Kleen
2006-06-15  1:57   ` Brice Goglin
2006-06-15  6:47     ` Arjan van de Ven
2006-06-21 22:19       ` Rajesh Shah
2006-06-21 22:32         ` Andi Kleen [this message]
2006-06-22  0:15           ` Rajesh Shah
2006-06-22  9:27             ` Arjan van de Ven
2006-06-23  7:41               ` Rajesh Shah
  -- strict thread matches above, loose matches on Subject: below --
2006-06-15  8:41 Chuck Ebbert
2006-06-15 13:18 ` Arjan van de Ven
2006-06-15 14:32   ` Barry Scott

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=200606220032.19388.ak@suse.de \
    --to=ak@suse.de \
    --cc=arjan@linux.intel.com \
    --cc=brice@myri.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rajesh.shah@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox