* x86: WARNING: at mm/memblock.c:1339 memblock_set_node - Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead @ 2024-06-03 13:49 Naresh Kamboju 2024-06-05 19:07 ` Paul E. McKenney 0 siblings, 1 reply; 8+ messages in thread From: Naresh Kamboju @ 2024-06-03 13:49 UTC (permalink / raw) To: open list, linux-mm, lkft-triage Cc: Andrew Morton, Mike Rapoport, jbeulich, Dan Carpenter, Arnd Bergmann 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 Boot log: -------- [ 0.008547] ------------[ cut here ]------------ [ 0.008547] Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead [ 0.008553] WARNING: CPU: 0 PID: 0 at mm/memblock.c:1339 memblock_set_node+0xed/0x100 [ 0.008559] Modules linked in: [ 0.008561] CPU: 0 PID: 0 Comm: swapper Not tainted 6.10.0-rc1-next-20240603 #1 [ 0.008563] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS 2.7 12/07/2021 [ 0.008564] RIP: 0010:memblock_set_node+0xed/0x100 [ 0.008567] Code: ea ea ff 00 74 0b 41 bc ff ff ff ff e9 6c ff ff ff 48 89 75 d0 c6 05 5e ea ea ff 01 90 48 c7 c7 c8 e1 c7 a0 e8 d4 36 df fd 90 <0f> 0b 90 90 48 8b 75 d0 eb d2 e8 74 bb f3 fe 0f 1f 40 00 90 90 90 [ 0.008568] RSP: 0000:ffffffffa1003de0 EFLAGS: 00010086 ORIG_RAX: 0000000000000000 [ 0.008570] RAX: 0000000000000000 RBX: ffffffffa149b510 RCX: 0000000000000000 [ 0.008572] RDX: 0000000000000000 RSI: 00000000ffffdfff RDI: 00000000ffffdfff [ 0.008572] RBP: ffffffffa1003e10 R08: 00000000ffffdfff R09: ffffffffa1003b90 [ 0.008573] R10: 0000000000000001 R11: ffffffffa1079440 R12: 0000000000000040 [ 0.008574] R13: 0000000000000000 R14: 000000008ad25c18 R15: 0000000000014770 [ 0.008575] FS: 0000000000000000(0000) GS:ffffffffa135e000(0000) knlGS:0000000000000000 [ 0.008577] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.008578] CR2: ffff9ac23fe01000 CR3: 00000003ff246000 CR4: 00000000000200f0 [ 0.008579] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.008579] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 0.008580] Call Trace: [ 0.008581] <TASK> [ 0.008582] ? show_regs+0x68/0x80 [ 0.008586] ? __warn+0x91/0x140 [ 0.008589] ? memblock_set_node+0xed/0x100 [ 0.008591] ? report_bug+0x175/0x1a0 [ 0.008594] ? fixup_exception+0x2b/0x2f0 [ 0.008597] ? early_fixup_exception+0xb3/0xd0 [ 0.008600] ? do_early_exception+0x1f/0x60 [ 0.008603] ? early_idt_handler_common+0x2f/0x40 [ 0.008606] ? memblock_set_node+0xed/0x100 [ 0.008609] ? __pfx_x86_acpi_numa_init+0x10/0x10 [ 0.008612] numa_init+0x8b/0x610 [ 0.008615] ? topo_register_apic+0x3a/0x130 [ 0.008617] x86_numa_init+0x23/0x70 [ 0.008620] initmem_init+0x12/0x20 [ 0.008622] setup_arch+0x8a3/0xd60 [ 0.008624] ? _printk+0x64/0x80 [ 0.008628] start_kernel+0x76/0x810 [ 0.008630] x86_64_start_reservations+0x1c/0x30 [ 0.008632] x86_64_start_kernel+0xca/0xe0 [ 0.008634] common_startup_64+0x12c/0x138 [ 0.008637] </TASK> [ 0.008638] ---[ end trace 0000000000000000 ]--- metadata: git_ref: master git_describe: next-20240603 git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next Links: - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240603/testrun/24170391/suite/log-parser-boot/tests/ - https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2hM1TaqYoxFAhzHCIRxz84OeUaj - https://storage.tuxsuite.com/public/linaro/lkft/builds/2hM1QI6QEe9bjg1sQrFs41ZSYmk - https://storage.tuxsuite.com/public/linaro/lkft/builds/2hM1QI6QEe9bjg1sQrFs41ZSYmk/config -- Linaro LKFT https://lkft.linaro.org ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86: WARNING: at mm/memblock.c:1339 memblock_set_node - Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead 2024-06-03 13:49 x86: WARNING: at mm/memblock.c:1339 memblock_set_node - Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead Naresh Kamboju @ 2024-06-05 19:07 ` Paul E. McKenney 2024-06-05 19:46 ` Jan Beulich 0 siblings, 1 reply; 8+ messages in thread From: Paul E. McKenney @ 2024-06-05 19:07 UTC (permalink / raw) To: Naresh Kamboju Cc: open list, linux-mm, lkft-triage, Andrew Morton, Mike Rapoport, jbeulich, Dan Carpenter, Arnd Bergmann 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. Thanx, Paul > Boot log: > -------- > [ 0.008547] ------------[ cut here ]------------ > [ 0.008547] Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead > [ 0.008553] WARNING: CPU: 0 PID: 0 at mm/memblock.c:1339 > memblock_set_node+0xed/0x100 > [ 0.008559] Modules linked in: > [ 0.008561] CPU: 0 PID: 0 Comm: swapper Not tainted > 6.10.0-rc1-next-20240603 #1 > [ 0.008563] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS > 2.7 12/07/2021 > [ 0.008564] RIP: 0010:memblock_set_node+0xed/0x100 > [ 0.008567] Code: ea ea ff 00 74 0b 41 bc ff ff ff ff e9 6c ff ff > ff 48 89 75 d0 c6 05 5e ea ea ff 01 90 48 c7 c7 c8 e1 c7 a0 e8 d4 36 > df fd 90 <0f> 0b 90 90 48 8b 75 d0 eb d2 e8 74 bb f3 fe 0f 1f 40 00 90 > 90 90 > [ 0.008568] RSP: 0000:ffffffffa1003de0 EFLAGS: 00010086 ORIG_RAX: > 0000000000000000 > [ 0.008570] RAX: 0000000000000000 RBX: ffffffffa149b510 RCX: 0000000000000000 > [ 0.008572] RDX: 0000000000000000 RSI: 00000000ffffdfff RDI: 00000000ffffdfff > [ 0.008572] RBP: ffffffffa1003e10 R08: 00000000ffffdfff R09: ffffffffa1003b90 > [ 0.008573] R10: 0000000000000001 R11: ffffffffa1079440 R12: 0000000000000040 > [ 0.008574] R13: 0000000000000000 R14: 000000008ad25c18 R15: 0000000000014770 > [ 0.008575] FS: 0000000000000000(0000) GS:ffffffffa135e000(0000) > knlGS:0000000000000000 > [ 0.008577] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 0.008578] CR2: ffff9ac23fe01000 CR3: 00000003ff246000 CR4: 00000000000200f0 > [ 0.008579] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 0.008579] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > [ 0.008580] Call Trace: > [ 0.008581] <TASK> > [ 0.008582] ? show_regs+0x68/0x80 > [ 0.008586] ? __warn+0x91/0x140 > [ 0.008589] ? memblock_set_node+0xed/0x100 > [ 0.008591] ? report_bug+0x175/0x1a0 > [ 0.008594] ? fixup_exception+0x2b/0x2f0 > [ 0.008597] ? early_fixup_exception+0xb3/0xd0 > [ 0.008600] ? do_early_exception+0x1f/0x60 > [ 0.008603] ? early_idt_handler_common+0x2f/0x40 > [ 0.008606] ? memblock_set_node+0xed/0x100 > [ 0.008609] ? __pfx_x86_acpi_numa_init+0x10/0x10 > [ 0.008612] numa_init+0x8b/0x610 > [ 0.008615] ? topo_register_apic+0x3a/0x130 > [ 0.008617] x86_numa_init+0x23/0x70 > [ 0.008620] initmem_init+0x12/0x20 > [ 0.008622] setup_arch+0x8a3/0xd60 > [ 0.008624] ? _printk+0x64/0x80 > [ 0.008628] start_kernel+0x76/0x810 > [ 0.008630] x86_64_start_reservations+0x1c/0x30 > [ 0.008632] x86_64_start_kernel+0xca/0xe0 > [ 0.008634] common_startup_64+0x12c/0x138 > [ 0.008637] </TASK> > [ 0.008638] ---[ end trace 0000000000000000 ]--- > > metadata: > git_ref: master > git_describe: next-20240603 > git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next > > Links: > - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240603/testrun/24170391/suite/log-parser-boot/tests/ > - https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2hM1TaqYoxFAhzHCIRxz84OeUaj > - https://storage.tuxsuite.com/public/linaro/lkft/builds/2hM1QI6QEe9bjg1sQrFs41ZSYmk > - https://storage.tuxsuite.com/public/linaro/lkft/builds/2hM1QI6QEe9bjg1sQrFs41ZSYmk/config > > -- > Linaro LKFT > https://lkft.linaro.org ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86: WARNING: at mm/memblock.c:1339 memblock_set_node - Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead 2024-06-05 19:07 ` Paul E. McKenney @ 2024-06-05 19:46 ` Jan Beulich 2024-06-05 20:48 ` Paul E. McKenney 0 siblings, 1 reply; 8+ messages in thread From: Jan Beulich @ 2024-06-05 19:46 UTC (permalink / raw) To: paulmck, Naresh Kamboju Cc: open list, linux-mm, lkft-triage, Andrew Morton, Mike Rapoport, Dan Carpenter, Arnd Bergmann 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. Jan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86: WARNING: at mm/memblock.c:1339 memblock_set_node - Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead 2024-06-05 19:46 ` Jan Beulich @ 2024-06-05 20:48 ` Paul E. McKenney [not found] ` <eaa90c1a-ae96-4506-90dd-146ce85d311c@suse.com> 0 siblings, 1 reply; 8+ messages in thread From: Paul E. McKenney @ 2024-06-05 20:48 UTC (permalink / raw) To: Jan Beulich Cc: Naresh Kamboju, open list, linux-mm, lkft-triage, Andrew Morton, Mike Rapoport, Dan Carpenter, Arnd Bergmann 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? Thanx, Paul ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <eaa90c1a-ae96-4506-90dd-146ce85d311c@suse.com>]
* Re: x86: WARNING: at mm/memblock.c:1339 memblock_set_node - Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead [not found] ` <eaa90c1a-ae96-4506-90dd-146ce85d311c@suse.com> @ 2024-06-06 14:19 ` Paul E. McKenney 2024-06-06 18:04 ` Paul E. McKenney 0 siblings, 1 reply; 8+ messages in thread From: Paul E. McKenney @ 2024-06-06 14:19 UTC (permalink / raw) To: Jan Beulich Cc: Naresh Kamboju, open list, linux-mm, lkft-triage, Andrew Morton, Mike Rapoport, Dan Carpenter, Arnd Bergmann 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@suse.com/ 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@kernel.org> Thanx, Paul ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86: WARNING: at mm/memblock.c:1339 memblock_set_node - Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead 2024-06-06 14:19 ` Paul E. McKenney @ 2024-06-06 18:04 ` Paul E. McKenney 2024-06-06 19:48 ` Mike Rapoport 0 siblings, 1 reply; 8+ messages in thread From: Paul E. McKenney @ 2024-06-06 18:04 UTC (permalink / raw) To: Jan Beulich Cc: Naresh Kamboju, open list, linux-mm, lkft-triage, Andrew Morton, Mike Rapoport, Dan Carpenter, Arnd Bergmann 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@suse.com/ > > 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@kernel.org> And the longer test ran without errors as well, so again, thank you! Any chance of getting this into -next sooner rather than later? Thanx, Paul ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86: WARNING: at mm/memblock.c:1339 memblock_set_node - Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead 2024-06-06 18:04 ` Paul E. McKenney @ 2024-06-06 19:48 ` Mike Rapoport 2024-06-06 20:17 ` Paul E. McKenney 0 siblings, 1 reply; 8+ messages in thread From: Mike Rapoport @ 2024-06-06 19:48 UTC (permalink / raw) To: Paul E. McKenney Cc: Jan Beulich, Naresh Kamboju, open list, linux-mm, lkft-triage, Andrew Morton, Dan Carpenter, Arnd Bergmann 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@suse.com/ > > > > 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@kernel.org> > > 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. > Thanx, Paul -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: x86: WARNING: at mm/memblock.c:1339 memblock_set_node - Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead 2024-06-06 19:48 ` Mike Rapoport @ 2024-06-06 20:17 ` Paul E. McKenney 0 siblings, 0 replies; 8+ messages in thread From: Paul E. McKenney @ 2024-06-06 20:17 UTC (permalink / raw) To: Mike Rapoport Cc: Jan Beulich, Naresh Kamboju, open list, linux-mm, lkft-triage, Andrew Morton, Dan Carpenter, Arnd Bergmann 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@suse.com/ > > > > > > 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@kernel.org> > > > > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-06-06 20:18 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-03 13:49 x86: WARNING: at mm/memblock.c:1339 memblock_set_node - Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead Naresh Kamboju
2024-06-05 19:07 ` Paul E. McKenney
2024-06-05 19:46 ` Jan Beulich
2024-06-05 20:48 ` Paul E. McKenney
[not found] ` <eaa90c1a-ae96-4506-90dd-146ce85d311c@suse.com>
2024-06-06 14:19 ` Paul E. McKenney
2024-06-06 18:04 ` Paul E. McKenney
2024-06-06 19:48 ` Mike Rapoport
2024-06-06 20:17 ` Paul E. McKenney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox