From: Dave Hansen <dave.hansen@intel.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
linux-pci@vger.kernel.org, x86@kernel.org, helgaas@kernel.org
Cc: linuxarm@huawei.com, Ingo Molnar <mingo@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
martin@geanix.com
Subject: Re: [PATCH V2] x86: Fix an issue with invalid ACPI NUMA config
Date: Tue, 11 Dec 2018 10:19:49 -0800 [thread overview]
Message-ID: <a5a938d3-ecc9-028a-3b28-610feda8f3f8@intel.com> (raw)
In-Reply-To: <20181211094737.71554-1-Jonathan.Cameron@huawei.com>
On 12/11/18 1:47 AM, Jonathan Cameron wrote:
> When the PCI code later comes along and calls acpi_get_node() for any PCI
> card below the root port, it navigates up the ACPI tree until it finds the
> _PXM value in the root port. This value is then passed to
> acpi_map_pxm_to_node().
>
> As numa_off has not been set on x86 it tries to allocate a NUMA node, from
> the unused set, without setting up all the infrastructure that would
> normally accompany such a call.
FWIW, this _sounds_ like the real problem here. We're allowing an
allocation to proceed without some infrastructure that we require.
Shouldn't we be detecting that this infrastructure is not in place and
warn about *it* at least?
I'm a bit worried that this is just papering over an unknown error to
make a hang go away. It seems a bit too far away from the root cause.
next prev parent reply other threads:[~2018-12-11 18:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 9:47 [PATCH V2] x86: Fix an issue with invalid ACPI NUMA config Jonathan Cameron
2018-12-11 18:19 ` Dave Hansen [this message]
2018-12-12 9:39 ` Jonathan Cameron
2018-12-20 15:12 ` Bjorn Helgaas
2018-12-20 17:13 ` Dave Hansen
2018-12-20 19:57 ` Bjorn Helgaas
2019-01-28 11:31 ` Jonathan Cameron
2019-01-28 23:13 ` Bjorn Helgaas
2019-01-29 9:51 ` Jonathan Cameron
2019-01-29 19:05 ` Bjorn Helgaas
2019-01-29 19:45 ` Jonathan Cameron
2019-01-29 21:10 ` Bjorn Helgaas
2019-02-07 10:12 ` Jonathan Cameron
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=a5a938d3-ecc9-028a-3b28-610feda8f3f8@intel.com \
--to=dave.hansen@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=dave.hansen@linux.intel.com \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=luto@kernel.org \
--cc=martin@geanix.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=x86@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;
as well as URLs for NNTP newsgroup(s).