From: Linus Torvalds <torvalds@linux-foundation.org>
To: Richard Henderson <rth@twiddle.net>
Cc: Chuck Ebbert <cebbert@redhat.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Daniel Ritz <daniel.ritz@gmx.ch>, Greg KH <greg@kroah.com>,
Keith Packard <keithp@keithp.com>,
Bjorn Helgaas <bjorn.helgaas@hp.com>
Subject: Re: PCI resource problems caused by improper address rounding
Date: Thu, 20 Dec 2007 17:00:39 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.0.9999.0712201650090.21557@woody.linux-foundation.org> (raw)
In-Reply-To: <20071221003913.GA6220@twiddle.net>
On Thu, 20 Dec 2007, Richard Henderson wrote:
>
> This breaks in odd cases where the amount of memory in the system
> is not a nice round number. Like throwing two 128MB sticks into
> a system that already has 2gb. A 512MB allocation will get placed
> back at 2gb, on top of the end of ram.
No, no, you misunderstand.
The kernel *always* takes known memory allocations into account. The
"minimum PCI starting allocation" value is not there to protect memory we
know about: the resource management already does that!
So if you have real memory of 2GB+128MB, and you want a 512MB allocation,
then yes, maybe the "preferred starting point" would be rounded back down
to 2GB, but the resource allocator would still take known resources into
account, and skip that address as being a conflict, and then try the next
address that suits the alignment requirements, and try to see if there's a
big enough hole at the 2.5GB mark.
So it would all work fine.
The reason we have that "min" parameter is not because of those _known_
resources, it's exactly because we have been bitten too many times by
BIOSes that lay out magic undocumented resources in memory that we simply
don't know about, because they aren't standard BAR resources, but some
other special magic stuff. Things like the special ACPI areas that the
northbridge recognizes, but aren't exposed as regular BAR's, but as just
magic registers hidden in some undocumented NB register space.
So the reason we have those PCIBIOS_MIN_IO/MEM things is not because we'd
trample on top of memory without them, it's because we might trample the
BIOS resources that it never told us about!
Quite often, that's things like stolen RAM that doesn't show up in the
e820 tables (it *should* show up as "reserved", but BIOS writers are
generally incompetent drug-addicts picked up from the streets, who just
randomly change BIOS tables until Windows boots on the machine), or the
afore-mentioned magic IO registers for some special motherboard resource.
> In order to get this kind of thing to work, you'd have to have a hard
> and a soft minimum.
We do have that "hard limit" - the resource management keeps track of all
the resources it already knows about. The "soft limit" is exactly that
PCIBIOS_MIN_MEM (which on a PC is that "pci_mem_start" variable). It's
just a hint, but it's a pretty important one, exactly because we've been
burned so many times by crap firmware and undocumented memory and MMIO
ranges.
Linus
next prev parent reply other threads:[~2007-12-21 1:03 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-18 0:25 Chuck Ebbert
2007-12-18 0:57 ` Linus Torvalds
2007-12-18 17:34 ` Chuck Ebbert
2007-12-18 18:21 ` Linus Torvalds
2007-12-18 20:22 ` Richard Henderson
2007-12-18 21:09 ` Linus Torvalds
2007-12-18 21:46 ` Chuck Ebbert
2007-12-18 21:56 ` Linus Torvalds
2007-12-18 22:17 ` Richard Henderson
2007-12-18 21:51 ` Richard Henderson
2007-12-18 22:31 ` Linus Torvalds
2007-12-19 1:38 ` Linus Torvalds
2007-12-20 21:52 ` Richard Henderson
2007-12-20 22:24 ` Linus Torvalds
2007-12-21 0:39 ` Richard Henderson
2007-12-21 1:00 ` Linus Torvalds [this message]
2007-12-21 2:28 ` Benjamin Herrenschmidt
2007-12-18 22:16 ` Keith Packard
2007-12-19 0:29 ` Bjorn Helgaas
2007-12-18 21:23 ` Ivan Kokshaysky
2007-12-18 21:46 ` Linus Torvalds
2007-12-20 8:46 ` Ivan Kokshaysky
2007-12-20 21:21 ` Benjamin Herrenschmidt
2007-12-22 9:12 ` Andrew Morton
2007-12-22 9:20 ` Andrew Morton
2007-12-20 21:10 ` Benjamin Herrenschmidt
2007-12-22 9:22 ` Andrew Morton
[not found] <fa.WmGIH8th8MfmciABVSBi6whxeFE@ifi.uio.no>
[not found] ` <fa.Obg5E3fyax+MaF94//uo40q/Zyk@ifi.uio.no>
[not found] ` <fa./6K5nXEIpws4VU8HtJhQjF4AoGg@ifi.uio.no>
[not found] ` <fa.V82IIxMkW3eu+9B44NfoyYYQDP4@ifi.uio.no>
[not found] ` <fa.DM9AyNQQtam66XpKVeXeqS639os@ifi.uio.no>
[not found] ` <fa.f5O3U527Rv8DNk05hDFRjdCaeFE@ifi.uio.no>
2007-12-19 0:11 ` Robert Hancock
2007-12-19 0:55 ` Chuck Ebbert
2007-12-19 1:12 ` Richard Henderson
2007-12-19 3:12 ` Linus Torvalds
[not found] ` <fa.PJGSMm4TIW6lRYng/jDqooIvj8U@ifi.uio.no>
[not found] ` <fa.0UHHdYi5zqyJ2xOPhNk/BhJkxYM@ifi.uio.no>
2007-12-19 0:18 ` Robert Hancock
2007-12-19 0:38 ` 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=alpine.LFD.0.9999.0712201650090.21557@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=bjorn.helgaas@hp.com \
--cc=cebbert@redhat.com \
--cc=daniel.ritz@gmx.ch \
--cc=greg@kroah.com \
--cc=ink@jurassic.park.msu.ru \
--cc=keithp@keithp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rth@twiddle.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 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®