mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Yinghai Lu <yinghai@kernel.org>
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 09:55:03 -0700	[thread overview]
Message-ID: <200912150955.03974.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <4B26E973.6080305@kernel.org>

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.

I assume that Windows runs on this box without requiring per-machine
hacks in the kernel.  Linux should be able to do the same, and the fact
that we can't is telling us we're doing somethign wrong.  We should fix
whatever's wrong rather than papering over it.

Bjorn

  reply	other threads:[~2009-12-15 16:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-13  8:07 Are there " 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 [this message]
2009-12-15 18:01                           ` Yinghai Lu
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=200912150955.03974.bjorn.helgaas@hp.com \
    --to=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 \
    --cc=yinghai@kernel.org \
    /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

all inboxes | Powered by JetHome®