public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chuck Ebbert <cebbert@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	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: Tue, 18 Dec 2007 18:18:40 -0600	[thread overview]
Message-ID: <47686360.1010208@shaw.ca> (raw)
In-Reply-To: <fa.0UHHdYi5zqyJ2xOPhNk/BhJkxYM@ifi.uio.no>

Linus Torvalds wrote:
> 
> On Tue, 18 Dec 2007, Chuck Ebbert wrote:
> 
>> On 12/18/2007 04:09 PM, Linus Torvalds wrote:
>>> I wonder what the heck is the point of that pnp entry. Just for fun, can 
>>> you try to just disable CONFIG_PNP, and see if it all works then?
>> pnpacpi=off should work.
>>
>> PnP is also trying (and failing) to reserve all physical memory.
> 
> Yeah, that really is a pretty confused-looking pnp table thing. But I have 
> absolutely zero idea how PnP is even supposed to work - the whole thing is 
> just a total hack for Windows, afaik.
> 
> The sad part is that *normally* the right thing to do about almost any 
> BIOS information is what we do right now: just avoid that magic address 
> range like the plague, because we have no clue what the heck the BIOS is 
> up to. But it looks like in this particular case, some of the problems 
> may arise exactly *because* we avoid that range.
> 
> It would be good to know what Windows does. If ACPI is found, does it 
> perhaps just ignore all the PnP entries these days?
> 
> 			Linus

ACPI is where those PnP entries are coming from (on any modern system 
anyway). They do show up in Device Manager as devices with resources 
(the one that reserves all of system RAM on my machine is labeled 
"System board", others like the one that reserves the MMCONFIG aperature 
are "Motherboard resources" - the name is based on the PNP device ID, I 
believe).

It could be that Windows is stupid enough that it will map things over 
top of physical RAM if the BIOS doesn't explicitly reserve it like that. 
  I suspect based on some comments in Microsoft documents that Windows 
uses the E820 table to figure out where the RAM is, and ACPI/PnP 
information to figure out where IO mappings are, but may not really 
combine those two pieces of information into one overall map like Linux 
does, which would explain why it needs to reserve all physical RAM..

(As mentioned in another post, I would guess the BIOS is reserving that 
memory range since it's the MMCONFIG aperture..)

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/


  parent reply	other threads:[~2007-12-19  0:20 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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           ` PCI resource problems caused by improper address rounding 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 [this message]
2007-12-19  0:38   ` Robert Hancock
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
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

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=47686360.1010208@shaw.ca \
    --to=hancockr@shaw.ca \
    --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 \
    --cc=torvalds@linux-foundation.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