x86: WARNING: at mm/memblock.c:1339 memblock_set_node - Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead
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/tes... - https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2hM1TaqYoxF... - https://storage.tuxsuite.com/public/linaro/lkft/builds/2hM1QI6QEe9bjg1sQrFs4... - https://storage.tuxsuite.com/public/linaro/lkft/builds/2hM1QI6QEe9bjg1sQrFs4...
-- Linaro LKFT https://lkft.linaro.org
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/tes...
- https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2hM1TaqYoxF...
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2hM1QI6QEe9bjg1sQrFs4...
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2hM1QI6QEe9bjg1sQrFs4...
-- Linaro LKFT https://lkft.linaro.org
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
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
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/
Jan
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
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
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
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
-
Jan Beulich -
Mike Rapoport -
Naresh Kamboju -
Paul E. McKenney