From: Olivier Galibert <galibert@pobox.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: linux-kernel@vger.kernel.org, Arjan van de Ven <arjan@infradead.org>
Subject: Re: [PATCH] update MMConfig patches w/915 support
Date: Tue, 16 Jan 2007 20:28:00 +0100 [thread overview]
Message-ID: <20070116192800.GB4192@dspnet.fr.eu.org> (raw)
In-Reply-To: <200701081327.16019.jbarnes@virtuousgeek.org>
On Mon, Jan 08, 2007 at 01:27:15PM -0800, Jesse Barnes wrote:
> On Monday, January 8, 2007 12:45 pm, Olivier Galibert wrote:
> > On Sun, Jan 07, 2007 at 11:44:16AM -0800, Jesse Barnes wrote:
> > > For reference, here's the probe routine I tried for 965, probably
> > > something dumb wrong with it that I'm not seeing atm.
> >
> > It shouldn't have mattered in your case, but base_address is limited
> > to 32bits. There is a 32 bits reserved zone after it so hope is not
> > to be lost, but in any case the current code can't handle over-4G
> > base addresses at that point.
> >
> > Does the bios or your '965 give a correct acpi mmconfig entry?
>
> I should have captured the debug printk I put in while testing. I think
> the base address specified in the register was 0xf0000000, with a size
> of 256M marked enabled. Arjan points out that this likely conflicts
> with other BIOS mappings, which is probably why I saw my machine hang
> when I tried to use it.
>
> As for ACPI, I assume you mean the MCFG table? I haven't looked at it,
> but the stock kernel complains about a lack of the MCFG range in the
> e820 table and subsequently disables mmconfig.
>
> But won't the bridge register value control what actually gets decoded?
> If so, it sounds like this BIOS is buggy wrt mmconfig mapping in
> general; good thing I'm not using any PCIe devices I guess...
Yeah. I've checked the docs, I think I know what's going on. On one
hand, if the chipset is configured to have the range somewhere, it is
decoded before anything external to the chipset, be it ram or mmaped
i/o. So the information you get from the chipset should not be able
to conflict with anything by definition, it's the anything that
wouldn't be visible.
But in your case of a f0000000-ffffffff mapping, something else
interesting is going on: it's conflicting with other internal
registers of the chipset, which, being fixed address, probably have
priority. So you probably have to either reduce the range so that the
chipset registers aren't touched, or drop mmconfig if the address is
f0000000.
Technically, we can have the exact same problem with the other
chipsets. BIOSen suck.
OG.
next prev parent reply other threads:[~2007-01-16 19:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-07 19:42 Jesse Barnes
2007-01-07 19:44 ` Jesse Barnes
2007-01-08 20:45 ` Olivier Galibert
2007-01-08 21:27 ` Jesse Barnes
2007-01-16 19:28 ` Olivier Galibert [this message]
2007-01-22 21:55 ` Jesse Barnes
2007-01-08 20:32 ` Olivier Galibert
2007-01-08 21:22 ` Jesse Barnes
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=20070116192800.GB4192@dspnet.fr.eu.org \
--to=galibert@pobox.com \
--cc=arjan@infradead.org \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.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®