From: Ingo Molnar <mingo@elte.hu>
To: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Yinghai Lu <yinghai@kernel.org>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
Matthew Wilcox <matthew@wil.cx>,
linux-pci@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 2/3] pci: don't assume pref memio are 64bit -v2
Date: Sat, 18 Apr 2009 22:25:11 +0200 [thread overview]
Message-ID: <20090418202511.GA30144@elte.hu> (raw)
In-Reply-To: <20090418200909.GA23229@jurassic.park.msu.ru>
* Ivan Kokshaysky <ink@jurassic.park.msu.ru> wrote:
> On Sat, Apr 18, 2009 at 01:44:51AM -0700, Yinghai Lu wrote:
> > and BIOS set
> > [ 0.240007] pci 0000:00:01.0: bridge 64bit mmio pref: [0xbdf00000-0xddefffff]
>
> An obvious BIOS bug, the bridge base overlaps the physical low RAM
> (0x00000000-0xc0000000). Technically speaking, this nonsense
> *happens* to work on Intel hardware, so it seems to be quite
> common bug nowadays - BIOS writers get lost in ACPI and other
> "useful" stuff contradicting the PCI specs.
it doesnt matter whether we call it a BIOS bug or not.
> ...
>
> > + /* don't allocate too high if the pref mem doesn't support 64bit*/
> > + if ((res->flags & (IORESOURCE_PREFETCH | PCI_PREF_RANGE_TYPE_64)) ==
> > + IORESOURCE_PREFETCH)
> > + max = 0xffffffff;
>
> This effectively destroys non-x86 64-bit arches. You've been told about
> that before, so I'm really surprised to see this "patch" once again.
>
> Categorically NACKed.
You can ridicule the patch and can NAK it (and rightfully so, it's
wrong), but you seem to miss the simple fact that this solves a very
real problem.
So consider this patch a documentation and analysis of a real
problem which made Linux work on hardware where it did not work
before. That's more valuable than 95% of our commits btw.
> P.S. I recall that I had a patch that addressed the issue, and
> Ingo made some reasonable comments about it. Will post it
> tomorrow.
That should have been pursued far more agressively.
Thanks,
Ingo
next prev parent reply other threads:[~2009-04-18 20:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-18 8:43 [PATCH 1/3] x86/pci: fix -1 calling to e820_all_mapped with mmconfig Yinghai Lu
2009-04-18 8:44 ` [PATCH 2/3] pci: don't assume pref memio are 64bit -v2 Yinghai Lu
2009-04-18 9:15 ` Ingo Molnar
2009-04-18 17:01 ` Yinghai Lu
2009-04-18 20:09 ` Ivan Kokshaysky
2009-04-18 20:25 ` Ingo Molnar [this message]
2009-04-18 8:46 ` [PATCH 3/3] pci: don't printout if the bus res size is 0 Yinghai Lu
2009-04-18 9:16 ` Ingo Molnar
2009-04-18 9:17 ` [PATCH 1/3] x86/pci: fix -1 calling to e820_all_mapped with mmconfig Ingo Molnar
2009-04-22 22:04 ` Jesse Barnes
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=20090418202511.GA30144@elte.hu \
--to=mingo@elte.hu \
--cc=ink@jurassic.park.msu.ru \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=torvalds@linux-foundation.org \
--cc=yinghai@kernel.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