mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®