LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Nathan Fontenot <nfont@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/pseries: Track LMB nid instead of using device tree
Date: Tue, 25 Sep 2018 11:17:57 +1000	[thread overview]
Message-ID: <878t3q5q9m.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <514f0192-4403-4305-1c2b-41dc752bcd36@linux.vnet.ibm.com>

Nathan Fontenot <nfont@linux.vnet.ibm.com> writes:
> On 09/19/2018 11:38 PM, Michael Ellerman wrote:
>> Nathan Fontenot <nfont@linux.vnet.ibm.com> writes:
>>> When removing memory we need to remove the memory from the node
>>> it was added to instead of looking up the node it should be in
>>> in the device tree.
>>>
>>> During testing we have seen scenarios where the affinity for a
>>> LMB changes due to a partition migration or PRRN event. In these
>>> cases the node the LMB exists in may not match the node the device
>>> tree indicates it belongs in. This can lead to a system crash
>>> when trying to DLAPR remove the LMB after a migration or PRRN
>>> event. The current code looks up the node in the device tree to
>>> remove the LMB from, the crash occurs when we try to offline this
>>> node and it does not have any data, i.e. node_data[nid] == NULL.
>> 
>> This isn't building for 32-bit etc:
>> 
>> arch/powerpc/mm/drmem.c: In function 'init_drmem_v1_lmbs':
>> arch/powerpc/mm/drmem.c:371:14: error: implicit declaration of function 'memory_add_physaddr_to_nid' [-Werror=implicit-function-declaration]
>>    lmb->nid = memory_add_physaddr_to_nid(lmb->base_addr);
>>               ^
>> cc1: all warnings being treated as errors
>> scripts/Makefile.build:317: recipe for target 'arch/powerpc/mm/drmem.o' failed
>> 
>> See the failed checks here:
>>   https://patchwork.ozlabs.org/patch/969150/
>> 
>> 
>> Probably drmem.c should only be compiled for 64-bit NUMA etc.
>
> Looks like the root cause is that memory hotplug relies on sparsemem which
> is not supported on 32-bit.

Yeah that could be it.

Making drmem.c built just for MEMORY_HOTPLUG would make sense.

> This patch is also going to need a refresh to apply cleanly due to other
> patches that have gone in. I'll re-submit after looking at the build break issues more.

OK thanks.

cheers

      reply	other threads:[~2018-09-25  1:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12 16:45 [PATCH] powerpc/pseries: Track LMB nid instead of using device tree Nathan Fontenot
2018-09-20  4:38 ` Michael Ellerman
2018-09-24 14:33   ` Nathan Fontenot
2018-09-25  1:17     ` Michael Ellerman [this message]

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=878t3q5q9m.fsf@concordia.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=nfont@linux.vnet.ibm.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