From: Jeff Garzik <jeff@garzik.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Adrian Bunk <bunk@stusta.de>,
Jeff Chua <jeff.chua.linux@gmail.com>,
Matthew Wilcox <matthew@wil.cx>, Andi Kleen <ak@suse.de>,
Aaron Durbin <adurbin@google.com>, Andrew Morton <akpm@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
gregkh@suse.de, linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [discuss] Re: 2.6.19-rc4: known unfixed regressions (v3)
Date: Fri, 10 Nov 2006 08:56:00 -0500 [thread overview]
Message-ID: <455484F0.3000506@garzik.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0611080951040.3667@g5.osdl.org>
Linus Torvalds wrote:
> We really should stop using MMCONFIG entirely, until we have a
> per-southbridge true knowledge of what the real decoding is. The BIOS
> tables for this are simply too damn unreliable.
FWIW: MMCONFIG is required for PCI domain support (or "PCI segments" as
ACPI calls them). Only a few mass market OEM boxes exist that need this
-- and they are all pretty new (Opteron multi-core) -- but more are coming.
I have a patch in -mm that works for this. Without the patch, my
sata_mv card and the machine's built-in MPT-Fusion do not appear at all
in PCI bus scans (nor do the associated hard drives) on this production
HP box. So far these machines are rare, /usually/ with a BIOS switch to
turn off PCI domains.
This says nothing about BIOS table reliability, of course. I agree that
MMCONFIG probing is highly unreliable at present. Whitelisting "<2007"
systems like Andi proposed may be the only option in some cases.
Jeff
next prev parent reply other threads:[~2006-11-10 13:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.64.0611080056480.12828@silvia.corp.fedex.com>
[not found] ` <20061107171143.GU27140@parisc-linux.org>
[not found] ` <200611080839.46670.ak@suse.de>
[not found] ` <20061108122237.GF27140@parisc-linux.org>
[not found] ` <Pine.LNX.4.64.0611080803280.3667@g5.osdl.org>
2006-11-08 17:26 ` [discuss] Re: 2.6.19-rc4: known unfixed regressions (v3) Adrian Bunk
2006-11-08 17:49 ` Linus Torvalds
2006-11-08 18:08 ` Linus Torvalds
2006-11-08 18:36 ` Linus Torvalds
2006-11-10 6:25 ` Jeff Chua
2006-11-10 6:43 ` Andrew Morton
2006-11-10 9:21 ` Jeff Chua
2006-11-10 6:56 ` Andi Kleen
2006-11-10 10:16 ` Alan Cox
2006-11-10 14:02 ` Jeff Garzik
2006-11-10 13:56 ` Jeff Garzik [this message]
2006-11-08 18:17 ` Aaron Durbin
2006-11-10 5:53 Jeff Chua
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=455484F0.3000506@garzik.org \
--to=jeff@garzik.org \
--cc=adurbin@google.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=bunk@stusta.de \
--cc=gregkh@suse.de \
--cc=jeff.chua.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=matthew@wil.cx \
--cc=torvalds@osdl.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