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
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
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/[email protected]/
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/[email protected]/
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 <[email protected]>
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/[email protected]/
>
> 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 <[email protected]>
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/[email protected]/
> >
> > 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 <[email protected]>
>
> 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.
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/[email protected]/
> > >
> > > 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 <[email protected]>
> >
> > 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