Kernel Panic - V6.2 - Reseved memory issue

Kernel Panic - V6.2 - Reseved memory issue

[Lucas Tanure]

Hi,

I am trying to fix a kernel panic I am seeing on my vim3 board (Amlogic A311D).
I don't have enough knowledge about this area, but my current guess is
the kernel is using a piece of memory belonging to ARM-trusted
firmware that I shouldn't.
Log:

[ 9.792966] SError Interrupt on CPU3, code 0x00000000bf000000 -- SError
[ 9.792980] CPU: 3 PID: 3471 Comm: kded5 Tainted: G C 6.2.0 #1
[ 9.792985] Hardware name: Khadas VIM3 (DT)
[ 9.792987] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 9.792991] pc : kmem_cache_free_bulk.part.98+0x1f0/0x528
[ 9.793004] lr : kmem_cache_free_bulk.part.98+0x2f8/0x528
[ 9.793008] sp : ffff80000a2eb7f0
[ 9.793009] x29: ffff80000a2eb7f0 x28: ffff00001f358518 x27: ffff000000008800
[ 9.793016] x26: ffff00000262b300 x25: ffff00000262b300 x24: 0000000000000001
[ 9.793019] x23: ffff00000262b000 x22: 0000000000000000 x21: ffff00001f358538
[ 9.793022] x20: fffffc0000098ac0 x19: 0000000000000004 x18: 0000000000000040
[ 9.793025] x17: 0000000000000018 x16: 00000000000007f8 x15: 0000000000000003
[ 9.793028] x14: 0000000000000006 x13: ffff800008e48550 x12: 0000ffff9dc91fff
[ 9.793031] x11: 0000000000000004 x10: 0000000000000001 x9 : ffff000007e93680
[ 9.793035] x8 : 0000000000000020 x7 : ffff000001d2b100 x6 : 0000000000000007
[ 9.793037] x5 : 0000000000000020 x4 : ffff000000008800 x3 : 0000000000000001
[ 9.793040] x2 : 0000000000000007 x1 : 0000000000000000 x0 : ffff00001f358540
[ 9.793045] Kernel panic - not syncing: Asynchronous SError Interrupt

This doesn't happen with downstream Khadas 6.2 kernel, and that's
because the downstream kernel removed this from
early_init_dt_reserve_memory (drivers/of/fdt.c):

/*
* If the memory is already reserved (by another region), we
* should not allow it to be marked nomap, but don't worry
* if the region isn't memory as it won't be mapped.
*/
if (memblock_overlaps_region(&memblock.memory, base, size) &&
    memblock_is_region_reserved(base, size))
          return -EBUSY;


And this causes 3 MiB of memory belonging to ARM Trusted firmware to
be reserved.

arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi :
/* 3 MiB reserved for ARM Trusted Firmware (BL31) */
secmon_reserved: secmon@5000000 {
        reg = <0x0 0x05000000 0x0 0x300000>;
        no-map;
};

And the mainline kernel fails to reserve that memory:
[    0.000000] OF: fdt: Reserved memory: failed to reserve memory for
node 'secmon@5000000': base 0x0000000005000000, size 3 MiB

It fails to reserve because memblock_overlaps_region and
memblock_is_region_reserved return one.
I think memblock_is_region_reserved is saying the memory is already
reserved by uboot and shouldn't be nomap, but it should.

Is there a bug here?
Why the kernel is failing to reserve this memory?
Is this an u-boot issue?

I would appreciate any help. The current mainline kernel fails 90% of
the time to boot into the Vim3 board.

Best Regards
Lucas Tanure

Re: Kernel Panic - V6.2 - Reseved memory issue

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]

On Sun, Apr 02, 2023 at 09:10:36AM +0100, Lucas Tanure wrote:
> Log:
> 
> [ 9.792966] SError Interrupt on CPU3, code 0x00000000bf000000 -- SError
> [ 9.792980] CPU: 3 PID: 3471 Comm: kded5 Tainted: G C 6.2.0 #1
> [ 9.792985] Hardware name: Khadas VIM3 (DT)
> [ 9.792987] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 9.792991] pc : kmem_cache_free_bulk.part.98+0x1f0/0x528
> [ 9.793004] lr : kmem_cache_free_bulk.part.98+0x2f8/0x528
> [ 9.793008] sp : ffff80000a2eb7f0
> [ 9.793009] x29: ffff80000a2eb7f0 x28: ffff00001f358518 x27: ffff000000008800
> [ 9.793016] x26: ffff00000262b300 x25: ffff00000262b300 x24: 0000000000000001
> [ 9.793019] x23: ffff00000262b000 x22: 0000000000000000 x21: ffff00001f358538
> [ 9.793022] x20: fffffc0000098ac0 x19: 0000000000000004 x18: 0000000000000040
> [ 9.793025] x17: 0000000000000018 x16: 00000000000007f8 x15: 0000000000000003
> [ 9.793028] x14: 0000000000000006 x13: ffff800008e48550 x12: 0000ffff9dc91fff
> [ 9.793031] x11: 0000000000000004 x10: 0000000000000001 x9 : ffff000007e93680
> [ 9.793035] x8 : 0000000000000020 x7 : ffff000001d2b100 x6 : 0000000000000007
> [ 9.793037] x5 : 0000000000000020 x4 : ffff000000008800 x3 : 0000000000000001
> [ 9.793040] x2 : 0000000000000007 x1 : 0000000000000000 x0 : ffff00001f358540
> [ 9.793045] Kernel panic - not syncing: Asynchronous SError Interrupt
> 
> This doesn't happen with downstream Khadas 6.2 kernel, and that's
> because the downstream kernel removed this from
> early_init_dt_reserve_memory (drivers/of/fdt.c):
> 
> /*
> * If the memory is already reserved (by another region), we
> * should not allow it to be marked nomap, but don't worry
> * if the region isn't memory as it won't be mapped.
> */
> if (memblock_overlaps_region(&memblock.memory, base, size) &&
>     memblock_is_region_reserved(base, size))
>           return -EBUSY;
> 

What commit on downstream kernel that fix the issue? Can you reproduce
on mainline with above conditional removed? Alternatively, can
you post the downstream fix here?

Also, can you find last working commit on mainline? If so, this is
regression.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Kernel Panic - V6.2 - Reseved memory issue

[Lucas Tanure]

On Sun, Apr 2, 2023 at 1:55 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>
> On Sun, Apr 02, 2023 at 09:10:36AM +0100, Lucas Tanure wrote:
> > Log:
> >
> > [ 9.792966] SError Interrupt on CPU3, code 0x00000000bf000000 -- SError
> > [ 9.792980] CPU: 3 PID: 3471 Comm: kded5 Tainted: G C 6.2.0 #1
> > [ 9.792985] Hardware name: Khadas VIM3 (DT)
> > [ 9.792987] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [ 9.792991] pc : kmem_cache_free_bulk.part.98+0x1f0/0x528
> > [ 9.793004] lr : kmem_cache_free_bulk.part.98+0x2f8/0x528
> > [ 9.793008] sp : ffff80000a2eb7f0
> > [ 9.793009] x29: ffff80000a2eb7f0 x28: ffff00001f358518 x27: ffff000000008800
> > [ 9.793016] x26: ffff00000262b300 x25: ffff00000262b300 x24: 0000000000000001
> > [ 9.793019] x23: ffff00000262b000 x22: 0000000000000000 x21: ffff00001f358538
> > [ 9.793022] x20: fffffc0000098ac0 x19: 0000000000000004 x18: 0000000000000040
> > [ 9.793025] x17: 0000000000000018 x16: 00000000000007f8 x15: 0000000000000003
> > [ 9.793028] x14: 0000000000000006 x13: ffff800008e48550 x12: 0000ffff9dc91fff
> > [ 9.793031] x11: 0000000000000004 x10: 0000000000000001 x9 : ffff000007e93680
> > [ 9.793035] x8 : 0000000000000020 x7 : ffff000001d2b100 x6 : 0000000000000007
> > [ 9.793037] x5 : 0000000000000020 x4 : ffff000000008800 x3 : 0000000000000001
> > [ 9.793040] x2 : 0000000000000007 x1 : 0000000000000000 x0 : ffff00001f358540
> > [ 9.793045] Kernel panic - not syncing: Asynchronous SError Interrupt
> >
> > This doesn't happen with downstream Khadas 6.2 kernel, and that's
> > because the downstream kernel removed this from
> > early_init_dt_reserve_memory (drivers/of/fdt.c):
> >
> > /*
> > * If the memory is already reserved (by another region), we
> > * should not allow it to be marked nomap, but don't worry
> > * if the region isn't memory as it won't be mapped.
> > */
> > if (memblock_overlaps_region(&memblock.memory, base, size) &&
> >     memblock_is_region_reserved(base, size))
> >           return -EBUSY;
> >
>
> What commit on downstream kernel that fix the issue?
Here:
https://github.com/khadas/linux/commit/2cb57b1071bf69f615fedc999b7ecacf2cde7228

 Can you reproduce
> on mainline with above conditional removed?
No, without that code mainline works fine.


Alternatively, can
> you post the downstream fix here?
Same https://github.com/khadas/linux/commit/2cb57b1071bf69f615fedc999b7ecacf2cde7228

>
> Also, can you find last working commit on mainline? If so, this is
> regression.
That is difficult as 5.13.0 has the line:
OF: fdt: Reserved memory: failed to reserve memory for node
'secmon@5000000': base 0x0000000005000000, size 3 MiB
But doesn't crash. It could be that no process used that address so no crash.

>
> Thanks.
>
> --
> An old man doll... just what I always wanted! - Clara

Re: Kernel Panic - V6.2 - Reseved memory issue

[Lucas Tanure]

On Mon, Apr 3, 2023 at 12:29 PM Lucas Tanure <tanure@linux.com> wrote:
>
> On Sun, Apr 2, 2023 at 1:55 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> >
> > On Sun, Apr 02, 2023 at 09:10:36AM +0100, Lucas Tanure wrote:
> > > Log:
> > >
> > > [ 9.792966] SError Interrupt on CPU3, code 0x00000000bf000000 -- SError
> > > [ 9.792980] CPU: 3 PID: 3471 Comm: kded5 Tainted: G C 6.2.0 #1
> > > [ 9.792985] Hardware name: Khadas VIM3 (DT)
> > > [ 9.792987] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > [ 9.792991] pc : kmem_cache_free_bulk.part.98+0x1f0/0x528
> > > [ 9.793004] lr : kmem_cache_free_bulk.part.98+0x2f8/0x528
> > > [ 9.793008] sp : ffff80000a2eb7f0
> > > [ 9.793009] x29: ffff80000a2eb7f0 x28: ffff00001f358518 x27: ffff000000008800
> > > [ 9.793016] x26: ffff00000262b300 x25: ffff00000262b300 x24: 0000000000000001
> > > [ 9.793019] x23: ffff00000262b000 x22: 0000000000000000 x21: ffff00001f358538
> > > [ 9.793022] x20: fffffc0000098ac0 x19: 0000000000000004 x18: 0000000000000040
> > > [ 9.793025] x17: 0000000000000018 x16: 00000000000007f8 x15: 0000000000000003
> > > [ 9.793028] x14: 0000000000000006 x13: ffff800008e48550 x12: 0000ffff9dc91fff
> > > [ 9.793031] x11: 0000000000000004 x10: 0000000000000001 x9 : ffff000007e93680
> > > [ 9.793035] x8 : 0000000000000020 x7 : ffff000001d2b100 x6 : 0000000000000007
> > > [ 9.793037] x5 : 0000000000000020 x4 : ffff000000008800 x3 : 0000000000000001
> > > [ 9.793040] x2 : 0000000000000007 x1 : 0000000000000000 x0 : ffff00001f358540
> > > [ 9.793045] Kernel panic - not syncing: Asynchronous SError Interrupt
> > >
> > > This doesn't happen with downstream Khadas 6.2 kernel, and that's
> > > because the downstream kernel removed this from
> > > early_init_dt_reserve_memory (drivers/of/fdt.c):
> > >
> > > /*
> > > * If the memory is already reserved (by another region), we
> > > * should not allow it to be marked nomap, but don't worry
> > > * if the region isn't memory as it won't be mapped.
> > > */
> > > if (memblock_overlaps_region(&memblock.memory, base, size) &&
> > >     memblock_is_region_reserved(base, size))
> > >           return -EBUSY;
> > >
> >
> > What commit on downstream kernel that fix the issue?
> Here:
> https://github.com/khadas/linux/commit/2cb57b1071bf69f615fedc999b7ecacf2cde7228
>
>  Can you reproduce
> > on mainline with above conditional removed?
> No, without that code mainline works fine.
>
>
> Alternatively, can
> > you post the downstream fix here?
> Same https://github.com/khadas/linux/commit/2cb57b1071bf69f615fedc999b7ecacf2cde7228
>
> >
> > Also, can you find last working commit on mainline? If so, this is
> > regression.
> That is difficult as 5.13.0 has the line:
> OF: fdt: Reserved memory: failed to reserve memory for node
> 'secmon@5000000': base 0x0000000005000000, size 3 MiB
> But doesn't crash. It could be that no process used that address so no crash.
>
> >
> > Thanks.
> >
> > --
> > An old man doll... just what I always wanted! - Clara

Hi,
I git bisect point it out commit that even reverting it would trigger the panic.
So this is a memory corruption problem that a simple git bisect will
not find the correct offending commit.

I managed to understand a little more about the issue:
1 ) early_init_fdt_scan_reserved_mem is executed first, reserves
[0x0000000005000000-0x00000000052fffff] but doesn't mark as no-map.
2 ) early_init_dt_reserve_memory tries to mark that region as nomap,
but it is already reserved and memblock_overlaps_region and
memblock_is_region_reserved return true, so it fails to mark as nomap.
3 ) kernel uses that memory and crashes

I think we have two options here:
1) Allow early_init_dt_reserve_memory mark nomap memory that is already reserved
2) Make early_init_fdt_scan_reserved_mem reserve with the flag nomap
if necessary. I don't know if that's possible.

Question MM guys, Mike Rapoport and Andrew Morton:
- Is it possible to make early_init_fdt_scan_reserved_mem reserve
memory with flags?
- It ok for early_init_fdt_scan_reserved_mem to mark regions already
reserved as nomap?

Thanks
Lucas

Re: Kernel Panic - V6.2 - Reseved memory issue

[Christian Hewitt]

> On 2 Apr 2023, at 12:10 pm, Lucas Tanure <tanure@linux.com> wrote:
> 
> Hi,
> 
> I am trying to fix a kernel panic I am seeing on my vim3 board (Amlogic A311D).
> I don't have enough knowledge about this area, but my current guess is
> the kernel is using a piece of memory belonging to ARM-trusted
> firmware that I shouldn't.
> Log:
> 
> [ 9.792966] SError Interrupt on CPU3, code 0x00000000bf000000 -- SError
> [ 9.792980] CPU: 3 PID: 3471 Comm: kded5 Tainted: G C 6.2.0 #1
> [ 9.792985] Hardware name: Khadas VIM3 (DT)
> [ 9.792987] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 9.792991] pc : kmem_cache_free_bulk.part.98+0x1f0/0x528
> [ 9.793004] lr : kmem_cache_free_bulk.part.98+0x2f8/0x528
> [ 9.793008] sp : ffff80000a2eb7f0
> [ 9.793009] x29: ffff80000a2eb7f0 x28: ffff00001f358518 x27: ffff000000008800
> [ 9.793016] x26: ffff00000262b300 x25: ffff00000262b300 x24: 0000000000000001
> [ 9.793019] x23: ffff00000262b000 x22: 0000000000000000 x21: ffff00001f358538
> [ 9.793022] x20: fffffc0000098ac0 x19: 0000000000000004 x18: 0000000000000040
> [ 9.793025] x17: 0000000000000018 x16: 00000000000007f8 x15: 0000000000000003
> [ 9.793028] x14: 0000000000000006 x13: ffff800008e48550 x12: 0000ffff9dc91fff
> [ 9.793031] x11: 0000000000000004 x10: 0000000000000001 x9 : ffff000007e93680
> [ 9.793035] x8 : 0000000000000020 x7 : ffff000001d2b100 x6 : 0000000000000007
> [ 9.793037] x5 : 0000000000000020 x4 : ffff000000008800 x3 : 0000000000000001
> [ 9.793040] x2 : 0000000000000007 x1 : 0000000000000000 x0 : ffff00001f358540
> [ 9.793045] Kernel panic - not syncing: Asynchronous SError Interrupt
> 
> This doesn't happen with downstream Khadas 6.2 kernel, and that's
> because the downstream kernel removed this from
> early_init_dt_reserve_memory (drivers/of/fdt.c):
> 
> /*
> * If the memory is already reserved (by another region), we
> * should not allow it to be marked nomap, but don't worry
> * if the region isn't memory as it won't be mapped.
> */
> if (memblock_overlaps_region(&memblock.memory, base, size) &&
>    memblock_is_region_reserved(base, size))
>          return -EBUSY;
> 
> 
> And this causes 3 MiB of memory belonging to ARM Trusted firmware to
> be reserved.
> 
> arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi :
> /* 3 MiB reserved for ARM Trusted Firmware (BL31) */
> secmon_reserved: secmon@5000000 {
>        reg = <0x0 0x05000000 0x0 0x300000>;
>        no-map;
> };
> 
> And the mainline kernel fails to reserve that memory:
> [    0.000000] OF: fdt: Reserved memory: failed to reserve memory for
> node 'secmon@5000000': base 0x0000000005000000, size 3 MiB
> 
> It fails to reserve because memblock_overlaps_region and
> memblock_is_region_reserved return one.
> I think memblock_is_region_reserved is saying the memory is already
> reserved by uboot and shouldn't be nomap, but it should.
> 
> Is there a bug here?
> Why the kernel is failing to reserve this memory?
> Is this an u-boot issue?
> 
> I would appreciate any help. The current mainline kernel fails 90% of
> the time to boot into the Vim3 board.

The issue was raised before by Stefan Agner here:

https://lore.kernel.org/linux-arm-kernel/40ca11f84b7cdbfb9ad2ddd480cb204a@agner.ch/

The thread sort of points at the general issue but the conversation
fizzled out and didn’t lead to any changes. At one point Stefan made
a suggestion about reverting part of the code, leading to this patch
in my own patchset:

https://github.com/chewitt/linux/commit/9633c9b24f6f16afdb7fa8c2e163b6ea7a7ac5f8

The issue is still present and the patch does work around it. The
crashes would probably show up more, only a large percentage of
distros that actively support Amlogic boards (and several vendors)
are picking chunks of my curated LibreELEC patchset for their own
kernels and thus that patch is quite widely used.

Christian

Re: Kernel Panic - V6.2 - Reseved memory issue

[Linux regression tracking (Thorsten Leemhuis)]

Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.

This is apparently is a regression and thus got on my radar.

This all sounds a bit unfortunate. What can we do to get this properly
solved? Which commit actually causes this? I wonder if poking maintainer
higher in the hierarchy might help getting this finally fixed.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot poke

On 02.04.23 15:11, Christian Hewitt wrote:
>> On 2 Apr 2023, at 12:10 pm, Lucas Tanure <tanure@linux.com> wrote:
>>
>> I am trying to fix a kernel panic I am seeing on my vim3 board (Amlogic A311D).
>> I don't have enough knowledge about this area, but my current guess is
>> the kernel is using a piece of memory belonging to ARM-trusted
>> firmware that I shouldn't.
>> Log:
>>
>> [ 9.792966] SError Interrupt on CPU3, code 0x00000000bf000000 -- SError
>> [ 9.792980] CPU: 3 PID: 3471 Comm: kded5 Tainted: G C 6.2.0 #1
>> [ 9.792985] Hardware name: Khadas VIM3 (DT)
>> [ 9.792987] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> [ 9.792991] pc : kmem_cache_free_bulk.part.98+0x1f0/0x528
>> [ 9.793004] lr : kmem_cache_free_bulk.part.98+0x2f8/0x528
>> [ 9.793008] sp : ffff80000a2eb7f0
>> [ 9.793009] x29: ffff80000a2eb7f0 x28: ffff00001f358518 x27: ffff000000008800
>> [ 9.793016] x26: ffff00000262b300 x25: ffff00000262b300 x24: 0000000000000001
>> [ 9.793019] x23: ffff00000262b000 x22: 0000000000000000 x21: ffff00001f358538
>> [ 9.793022] x20: fffffc0000098ac0 x19: 0000000000000004 x18: 0000000000000040
>> [ 9.793025] x17: 0000000000000018 x16: 00000000000007f8 x15: 0000000000000003
>> [ 9.793028] x14: 0000000000000006 x13: ffff800008e48550 x12: 0000ffff9dc91fff
>> [ 9.793031] x11: 0000000000000004 x10: 0000000000000001 x9 : ffff000007e93680
>> [ 9.793035] x8 : 0000000000000020 x7 : ffff000001d2b100 x6 : 0000000000000007
>> [ 9.793037] x5 : 0000000000000020 x4 : ffff000000008800 x3 : 0000000000000001
>> [ 9.793040] x2 : 0000000000000007 x1 : 0000000000000000 x0 : ffff00001f358540
>> [ 9.793045] Kernel panic - not syncing: Asynchronous SError Interrupt
>>
>> This doesn't happen with downstream Khadas 6.2 kernel, and that's
>> because the downstream kernel removed this from
>> early_init_dt_reserve_memory (drivers/of/fdt.c):
>>
>> /*
>> * If the memory is already reserved (by another region), we
>> * should not allow it to be marked nomap, but don't worry
>> * if the region isn't memory as it won't be mapped.
>> */
>> if (memblock_overlaps_region(&memblock.memory, base, size) &&
>>    memblock_is_region_reserved(base, size))
>>          return -EBUSY;
>>
>>
>> And this causes 3 MiB of memory belonging to ARM Trusted firmware to
>> be reserved.
>>
>> arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi :
>> /* 3 MiB reserved for ARM Trusted Firmware (BL31) */
>> secmon_reserved: secmon@5000000 {
>>        reg = <0x0 0x05000000 0x0 0x300000>;
>>        no-map;
>> };
>>
>> And the mainline kernel fails to reserve that memory:
>> [    0.000000] OF: fdt: Reserved memory: failed to reserve memory for
>> node 'secmon@5000000': base 0x0000000005000000, size 3 MiB
>>
>> It fails to reserve because memblock_overlaps_region and
>> memblock_is_region_reserved return one.
>> I think memblock_is_region_reserved is saying the memory is already
>> reserved by uboot and shouldn't be nomap, but it should.
>>
>> Is there a bug here?
>> Why the kernel is failing to reserve this memory?
>> Is this an u-boot issue?
>>
>> I would appreciate any help. The current mainline kernel fails 90% of
>> the time to boot into the Vim3 board.
> 
> The issue was raised before by Stefan Agner here:
> 
> https://lore.kernel.org/linux-arm-kernel/40ca11f84b7cdbfb9ad2ddd480cb204a@agner.ch/
> 
> The thread sort of points at the general issue but the conversation
> fizzled out and didn’t lead to any changes. At one point Stefan made
> a suggestion about reverting part of the code, leading to this patch
> in my own patchset:
> 
> https://github.com/chewitt/linux/commit/9633c9b24f6f16afdb7fa8c2e163b6ea7a7ac5f8
> 
> The issue is still present and the patch does work around it. The
> crashes would probably show up more, only a large percentage of
> distros that actively support Amlogic boards (and several vendors)
> are picking chunks of my curated LibreELEC patchset for their own
> kernels and thus that patch is quite widely used.
> 
> Christian
> 

Re: Kernel Panic - V6.2 - Reseved memory issue

[Linux regression tracking #adding (Thorsten Leemhuis)]

[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]

[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]

On 02.04.23 10:10, Lucas Tanure wrote:
> 
> I am trying to fix a kernel panic I am seeing on my vim3 board (Amlogic A311D).
> I don't have enough knowledge about this area, but my current guess is
> the kernel is using a piece of memory belonging to ARM-trusted
> firmware that I shouldn't.
> 

Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot (note: the version specified below here might not be fully
accurate):

#regzbot ^introduced v5.9..v5.15
#regzbot title amlogic boards: random kernel panics (memory corruption)
#regzbot monitor:
https://lore.kernel.org/linux-arm-kernel/40ca11f84b7cdbfb9ad2ddd480cb204a@agner.ch/
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.

Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for
details.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.