All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Robert Hancock <hancockrwd@gmail.com>,
	Tvrtko Ursulin <tvrtko@ursulin.net>,
	Tvrtko Ursulin <tvrtko.ursulin@sophos.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: Are these MTRR settings correct?
Date: Tue, 15 Dec 2009 10:01:28 -0800	[thread overview]
Message-ID: <4B27CEF8.9010303@kernel.org> (raw)
In-Reply-To: <200912150955.03974.bjorn.helgaas@hp.com>

Bjorn Helgaas wrote:
> On Monday 14 December 2009 06:42:11 pm Yinghai Lu wrote:
>> Robert Hancock wrote:
>>> Something else isn't quite right. It looks like MMCONFIG area should be
>>> reserved:
>>>
>>> [    0.308434] system 00:0c: iomem range 0xe0000000-0xefffffff has been
>>> reserved
>>>
>>> but the code didn't seem to detect that. In fact there doesn't seem to
>>> be any output about whether it was or wasn't reserved, which from the
>>> code it seems there should be.
>>>
>>> Maybe because of that ACPI method execution error?
>> could be sth pnpacpi brokenness?
> 
> Robert, I assume you're referring to this from Tvrtko's post
> (http://lkml.org/lkml/2009/12/13/90):
> 
> [    0.000000]  BIOS-e820: 00000000dffd0000 - 00000000e0000000 (reserved)
> [    0.000000]  BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
> ...
> [    0.250088] PCI: Found AMD Family 10h NB with MMCONFIG support.
> [    0.250091] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
> [    0.250092] PCI: Not using MMCONFIG.
> ...
> [    0.253491] ACPI Error (psargs-0359): [ECEN] Namespace lookup failure, AE_NOT_FOUND
> [    0.253495] ACPI Error (psparse-0537): Method parse/execution failed [\] (Node ffffffff81656ab0), AE_NOT_FOUND
> ...
> [    0.308434] system 00:0c: iomem range 0xe0000000-0xefffffff has been reserved
> 
> I think we're rejecting MMCONFIG in the early call to
> pci_mmcfg_reject_broken(), when we check only E820 resources, not
> ACPI resources.  And indeed, the 0xe0000000-0xefffffff range is
> not mentioned in E820.  Which output did you expect to see?
> 
> I am uncomfortable with this early/late checking and looking at both
> E820 and ACPI.  It just feels hacky and error-prone.  I'm not happy about
> adding Yinghai's special-case "if we found AMD Fam10h, don't check for
> reservations" patch either.

only check ACPI or remove all hostbridge detect related?


YH

  reply	other threads:[~2009-12-15 18:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-13  8:07 Are there MTRR settings correct? Tvrtko Ursulin
2009-12-13  8:26 ` Are these " Tvrtko Ursulin
2009-12-13  9:25   ` Yinghai Lu
2009-12-13 17:19     ` Tvrtko Ursulin
2009-12-13 22:56       ` Yinghai Lu
2009-12-14 11:19         ` Tvrtko Ursulin
2009-12-14 11:25           ` Yinghai Lu
2009-12-14 19:34             ` Tvrtko Ursulin
2009-12-14 19:47               ` Yinghai Lu
2009-12-14 20:16                 ` Tvrtko Ursulin
2009-12-14 20:26                   ` Yinghai Lu
2009-12-15  1:22                     ` Robert Hancock
2009-12-15  1:42                       ` Yinghai Lu
2009-12-15 16:55                         ` Bjorn Helgaas
2009-12-15 18:01                           ` Yinghai Lu [this message]
2009-12-15 20:50                           ` Robert Hancock
2009-12-15 21:09                             ` Jesse Barnes
2009-12-16  0:14                               ` Robert Hancock
2009-12-16  6:26                             ` Yinghai Lu
2009-12-15  2:47                       ` [PATCH] x86/pci: don't check mmconf again if it is from MSR with amd faml0h Yinghai Lu
2009-12-16 20:06                         ` Jesse Barnes
2009-12-16 22:18                           ` Yinghai Lu
2009-12-13 20:26     ` Are these MTRR settings correct? Robert Hancock

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=4B27CEF8.9010303@kernel.org \
    --to=yinghai@kernel.org \
    --cc=bjorn.helgaas@hp.com \
    --cc=hancockrwd@gmail.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tvrtko.ursulin@sophos.com \
    --cc=tvrtko@ursulin.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.