From: Bjorn Helgaas <helgaas@kernel.org>
To: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Cc: Yicong Yang <yangyicong@hisilicon.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
fangjian 00545541 <f.fangjian@huawei.com>
Subject: Re: PCI: bus resource allocation error
Date: Tue, 11 Feb 2020 13:43:28 -0600 [thread overview]
Message-ID: <20200211194328.GA230920@google.com> (raw)
In-Reply-To: <SL2P216MB04433D05965A7D1C0E6A4BD680180@SL2P216MB0443.KORP216.PROD.OUTLOOK.COM>
On Tue, Feb 11, 2020 at 01:43:16PM +0000, Nicholas Johnson wrote:
> If the BIOS assigned the resources with different packing than what the
> kernel would do, then the rescan may not fit into the space. You can try
> pci=realloc,nocrs if you have not already. Your system looks like it is
> ARM64 so you cannot use pci=nocrs, unfortunately.
"pci=nocrs" is a poor workaround for BIOS and Linux bugs. It is
guaranteed to break hot-add on multi-host bridge systems because _CRS
is what tells us what resources go to each bridge. Even on
single-bridge systems "pci=nocrs" is dangerous because it may cause
Linux to assign resources that aren't routed to PCI or are being used
by other devices.
It's fine for debugging, but it's never the right long-term answer.
> The ideal situation is
> if the kernel throws away everything the BIOS did and does everything
> itself (assuming that this will not cause platform conflicts).
I do not think this is the ideal situation. If the assignment done by
BIOS works, I think Linux should leave it alone.
If the BIOS assignment *doesn't* work, or if we hot-add a device and
can't assign resources to it, sure, it makes sense for Linux to try to
reassign things. But we should not throw away the BIOS assignments as
a matter of course.
Bjorn
next prev parent reply other threads:[~2020-02-11 19:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-09 3:35 PCI: bus resource allocation error Yicong Yang
2020-01-09 4:27 ` Bjorn Helgaas
2020-01-09 10:31 ` Yicong Yang
2020-01-09 21:55 ` Bjorn Helgaas
2020-01-09 23:55 ` Nicholas Johnson
2020-01-10 0:08 ` Bjorn Helgaas
2020-01-09 23:00 ` Bjorn Helgaas
2020-01-10 7:08 ` Yicong Yang
2020-01-10 7:33 ` Yicong Yang
2020-01-10 7:40 ` Nicholas Johnson
2020-01-14 8:25 ` Yicong Yang
2020-02-11 10:36 ` Yicong Yang
2020-02-11 13:43 ` Nicholas Johnson
2020-02-11 19:43 ` Bjorn Helgaas [this message]
2020-02-18 3:18 ` Yicong Yang
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=20200211194328.GA230920@google.com \
--to=helgaas@kernel.org \
--cc=f.fangjian@huawei.com \
--cc=linux-pci@vger.kernel.org \
--cc=nicholas.johnson-opensource@outlook.com.au \
--cc=yangyicong@hisilicon.com \
/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;
as well as URLs for NNTP newsgroup(s).