On Thu, Jun 06, 2024 at 10:48:01PM +0300, Mike Rapoport wrote: > On Thu, Jun 06, 2024 at 11:04:30AM -0700, Paul E. McKenney wrote: > > On Thu, Jun 06, 2024 at 07:19:40AM -0700, Paul E. McKenney wrote: > > > On Thu, Jun 06, 2024 at 08:13:17AM +0200, Jan Beulich wrote: > > > > On 05.06.2024 22:48, Paul E. McKenney wrote: > > > > > On Wed, Jun 05, 2024 at 09:46:37PM +0200, Jan Beulich wrote: > > > > >> On 05.06.2024 21:07, Paul E. McKenney wrote: > > > > >>> On Mon, Jun 03, 2024 at 07:19:21PM +0530, Naresh Kamboju wrote: > > > > >>>> The following kernel warnings are noticed on x86 devices while booting > > > > >>>> the Linux next-20240603 tag and looks like it is expected to warn users to > > > > >>>> use NUMA_NO_NODE instead. > > > > >>>> > > > > >>>> Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead > > > > >>>> > > > > >>>> The following config is enabled > > > > >>>> CONFIG_NUMA=y > > > > >>> > > > > >>> I am seeing this as well. Is the following commit premature? > > > > >>> > > > > >>> e0eec24e2e19 ("memblock: make memblock_set_node() also warn about use of MAX_NUMNODES") > > > > >>> > > > > >>> Maybe old ACPI tables and device trees need to catch up? > > > > >>> > > > > >>> Left to myself, I would simply remove the WARN_ON_ONCE() from the above > > > > >>> commit, but I would guess that there is a better way. > > > > >> > > > > >> Well, the warning is issued precisely to make clear that call > > > > >> sites need to change. A patch to do so for the two instances > > > > >> on x86 that I'm aware of is already pending maintainer approval. > > > > > > > > > > Could you please point me at that patch so that I can stop repeatedly > > > > > reproducing those two particular issues? > > > > > > > > https://lore.kernel.org/lkml/abadb736-a239-49e4-ab42-ace7acdd4278@xxxxxxxx/ > > > > > > Thank you, Jan! > > > > > > A quick initial test shows that this clears things up. I have started > > > a longer test to check for additional issues. But in the meantime > > > for the issues I was already seeing in the initial test: > > > > > > Tested-by: Paul E. McKenney <paulmck@xxxxxxxxxx> > > > > And the longer test ran without errors as well, so again, thank you! > > > > Any chance of getting this into -next sooner rather than later? > > Should be there tomorrow. Thank you very much! Thanx, Paul