From: Loic Prylli <loic@myri.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Tony Camuso <tcamuso@redhat.com>, Greg KH <gregkh@suse.de>,
linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]
Date: Thu, 20 Dec 2007 13:49:04 -0500 [thread overview]
Message-ID: <476AB920.7040604@myri.com> (raw)
In-Reply-To: <20071220181603.GF29690@parisc-linux.org>
On 12/20/2007 1:16 PM, Matthew Wilcox wrote:
>
> Bad deduction. What's happening is that the write to the BAR is causing
> it to overlap the decode for mmconfig space. So the mmconfig write to
> set the BAR back never gets through.
>
> I have a different idea to fix this problem. Instead of writing
> 0xffffffff, we could look for an unused bit of space in the E820 map and
> write, say, 0xdfffffff to the low 32-bits of a BAR. Then it wouldn't
> overlap, and we could find its size using MMCONFIG.
>
> Does anyone know how Windows handles these machines? Obviously, if it's
> using MMCONFIG, it'd have the same problems. Does it just use type 1
> for initial sizing? Or does it use type 1 for all accesses below 256
> bytes?
>
Always using type 1 for accesses below 256 bytes looks like a very very
attractive solution
I know we had a lot of older kernels over the last two years that we
patched like that (we needed MMCONFIG for our own device development
purposes, but we also needed our machines to boot and discover all
devices reliably). Recent kernels works fine out of the box on all
hardware we have, but all this sometimes tricky and apparently endless
work (in big part because of buggy BIOSes) about MMCONFIG would probably
become relatively easy by limiting the aim to have MMCONFIG work when it
is required (for cfg-space accesses >= 256).
Loic
next prev parent reply other threads:[~2007-12-20 18:49 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-20 12:28 [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG] Tony Camuso
2007-12-20 17:22 ` Greg KH
2007-12-20 17:35 ` Matthew Wilcox
2007-12-20 18:04 ` Tony Camuso
2007-12-20 18:16 ` Matthew Wilcox
2007-12-20 18:30 ` Tony Camuso
2007-12-20 18:36 ` Matthew Wilcox
2007-12-20 18:49 ` Loic Prylli [this message]
2007-12-20 19:04 ` Tony Camuso
2007-12-20 19:08 ` Matthew Wilcox
2007-12-20 19:50 ` Ivan Kokshaysky
2007-12-20 20:17 ` Tony Camuso
2007-12-20 20:27 ` Tony Camuso
2008-01-08 3:41 ` Tony Camuso
2007-12-20 20:05 ` Loic Prylli
2007-12-20 20:15 ` Matthew Wilcox
2007-12-20 20:56 ` Loic Prylli
2007-12-20 21:00 ` Matthew Wilcox
2007-12-20 21:55 ` Loic Prylli
2007-12-20 19:37 ` Tony Camuso
2007-12-20 20:04 ` Matthew Wilcox
2007-12-20 20:15 ` Tony Camuso
2007-12-23 20:16 ` Loic Prylli
2007-12-23 20:55 ` Matthew Wilcox
2007-12-23 22:40 ` Loic Prylli
2007-12-24 8:09 ` Grant Grundler
2007-12-20 18:25 ` Tony Camuso
2007-12-20 21:57 ` Greg KH
2007-12-20 22:36 ` Tony Camuso
2007-12-20 22:40 ` Greg KH
2007-12-20 23:21 ` Tony Camuso
2007-12-21 2:07 ` Loic Prylli
2007-12-24 8:28 ` Grant Grundler
2008-01-08 3:20 ` [PATCH 0/5]PCI: x86 MMCONFIG Tony Camuso
2008-01-08 4:56 ` Greg KH
2008-01-08 13:14 ` Tony Camuso
2008-01-08 13:36 ` Greg KH
2008-01-08 13:44 ` Tony Camuso
-- strict thread matches above, loose matches on Subject: below --
2007-12-20 12:28 [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG] Tony Camuso
[not found] <fa.HvUNJ45qy60H427u0v9fNt3Gc7E@ifi.uio.no>
[not found] ` <fa.uuzqvr64HFsgxfiWwhEmE16Di6c@ifi.uio.no>
[not found] ` <fa.zhxdNN/1rfQhfJLVmdGBjvKYrCM@ifi.uio.no>
[not found] ` <fa.z1qlON6DA9ubBPFdrEcaFTMgYOY@ifi.uio.no>
[not found] ` <fa.U/SCC1Gvd3nSOpkMu5vcsSPYyPE@ifi.uio.no>
[not found] ` <fa.d8kGTkzOZH22bXRIRiakqgOPBM4@ifi.uio.no>
2007-12-21 0:44 ` Robert Hancock
2007-12-21 1:35 ` Tony Camuso
2007-12-21 1:42 ` Tony Camuso
2007-12-21 14:59 ` Bhavana Nagendra
2007-12-21 2:15 ` Robert Hancock
2007-12-21 2:44 ` Tony Camuso
2007-12-21 3:40 ` Loic Prylli
2007-12-21 4:07 ` Tony Camuso
2007-12-21 2:09 ` Tony Camuso
2007-12-21 14:11 ` Andi Kleen
[not found] ` <fa.pdOcVPk2gFn5iK76ExRH6Ow+NPw@ifi.uio.no>
2007-12-22 16:41 ` Robert Hancock
[not found] ` <fa.AlLzUeumrcT2SswgOn6MxKfDE0U@ifi.uio.no>
[not found] ` <fa.wIE0QfzMAxr82X049FecszlEnQY@ifi.uio.no>
[not found] ` <fa.2jJbe4cdXLfOVhNWVxdIjsW8GQc@ifi.uio.no>
[not found] ` <fa.JiW7yU0G/EdLOCYcPOacl/XVocc@ifi.uio.no>
[not found] ` <fa.PI93hBriZRT9ggytQ5eY/446Tno@ifi.uio.no>
2007-12-24 17:13 ` 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=476AB920.7040604@myri.com \
--to=loic@myri.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=matthew@wil.cx \
--cc=tcamuso@redhat.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;
as well as URLs for NNTP newsgroup(s).