* file system crash
@ 2026-03-17 10:58 Renaud Barbier
2026-03-17 11:15 ` Ahmad Fatoum
0 siblings, 1 reply; 4+ messages in thread
From: Renaud Barbier @ 2026-03-17 10:58 UTC (permalink / raw)
To: Barebox List
I have a BSP (not upstreamed) using a ARMv9 that I rebased fromv2025.06 to 2026.01. This board has a SPI NOR with a UBI volume.
The system starts perfectly.
When doing an umount or ls -l or reset barebox crashes. Debugging the code, the cdevname pointer in destroy_inode is sometimes (set to 0xffffffff) or the string corrupted. Also below the filename is corrupted.
OWBOOT> / ls -l /mnt/primary
ERROR: RENAUD: cdev_by_name: name = cs0 filename = .ӿk
ERROR: RENAUD: cdev_by_name: name = m25p0 filename = .ӿk
ERROR: RENAUD: cdev_by_name: name = m25p0.barebox filename = .ӿk
ERROR: RENAUD: cdev_by_name: name = m25p0.secondary-barebox filename = .ӿk
ERROR: RENAUD: cdev_by_name: name = m25p0.barebox-environment filename = .ӿk
…
One can see the filename above is corrupted
During reset:
ERROR: RENAUD: devfs_open: cdevname = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = cs0 filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = m25p0 filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = m25p0.barebox filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = m25p0.secondary-barebox filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = m25p0.barebox-environment filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = m25p0.env-secondary filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: name = m25p0.boot-vars filename = m25p0.boot-vars
ERROR: RENAUD: cdev_by_name: found cdev m25p0.boot-vars
ERROR: fs_remove: ENTER
ERROR: ubifs_remove: ENTER
ERROR: ubifs_remove: END
ERROR: destroy_inode: inode = bff36380
ERROR: destroy_inode: cdevname@ = bff3647c
ERROR: RENAUD: destroy_inode cdevname: tc`, len = 5 ???
!block_is_last(block)common/tlsf.c 253
[<dfd8387c>] (unwind_backtrace+0x0/0xe4) from [<dfd0a0dc>] (block_next+0x38/0x48)
[<dfd0a0dc>] (block_next+0x38/0x48) from [<dfd0a0f8>] (block_link_next+0xc/0x14)
[<dfd0a0f8>] (block_link_next+0xc/0x14) from [<dfd0a76c>] (tlsf_free+0x48/0x108)
[<dfd0a76c>] (tlsf_free+0x48/0x108) from [<dfd65a74>] (destroy_inode+0x84/0x188)
[<dfd65a74>] (destroy_inode+0x84/0x188) from [<dfd671cc>] (dentry_kill+0x18/0x54)
[<dfd671cc>] (dentry_kill+0x18/0x54) from [<dfd67e24>] (fs_remove+0x144/0x1b0)
[<dfd67e24>] (fs_remove+0x144/0x1b0) from [<dfd12230>] (devices_shutdown+0x54/0x68)
[<dfd12230>] (devices_shutdown+0x54/0x68) from [<dfd0221c>] (shutdown_barebox+0x44/0x58)
[<dfd0221c>] (shutdown_barebox+0x44/0x58) from [<dfd48244>] (cmd_reset+0x114/0x154)
[<dfd48244>] (cmd_reset+0x114/0x154) from [<dfd06160>] (execute_command+0x4c/0x90)
[<dfd06160>] (execute_command+0x4c/0x90) from [<dfd0dc98>] (run_list_real.isra.0+0x810/0x8c0)
[<dfd0dc98>] (run_list_real.isra.0+0x810/0x8c0) from [<dfd0d13c>] (parse_stream_outer+0x130/0x1f4)
[<dfd0d13c>] (parse_stream_outer+0x130/0x1f4) from [<dfd0df04>] (run_shell+0x74/0xb4)
[<dfd0df04>] (run_shell+0x74/0xb4) from [<dfd01e80>] (start_barebox+0x58/0x9c)
[<dfd01e80>] (start_barebox+0x58/0x9c) from [<dfd7f1b8>] (barebox_non_pbl_start+0xc4/0xdc)
[<dfd7f1b8>] (barebox_non_pbl_start+0xc4/0xdc) from [<dfd00004>] (__bare_init_start+0x0/0x10)
Again, it seems there is memory corruption of cdevname
Has anybody seen this?
Note this is not happening with barebox v2025.12.0 and I did notice there was lots of rework on the fs directory from v2026.01
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: file system crash
2026-03-17 10:58 file system crash Renaud Barbier
@ 2026-03-17 11:15 ` Ahmad Fatoum
2026-03-17 14:31 ` Renaud Barbier
0 siblings, 1 reply; 4+ messages in thread
From: Ahmad Fatoum @ 2026-03-17 11:15 UTC (permalink / raw)
To: Renaud Barbier, Barebox List
Hello Renaud,
On 3/17/26 11:58 AM, Renaud Barbier wrote:
> I have a BSP (not upstreamed) using a ARMv9 that I rebased fromv2025.06 to 2026.01. This board has a SPI NOR with a UBI volume.
> The system starts perfectly.
ARMv9 or ARM9?
Can you rerun with CONFIG_KASAN=y and report the output?
Thanks,
Ahmad
>
> When doing an umount or ls -l or reset barebox crashes. Debugging the code, the cdevname pointer in destroy_inode is sometimes (set to 0xffffffff) or the string corrupted. Also below the filename is corrupted.
> OWBOOT> / ls -l /mnt/primary
> ERROR: RENAUD: cdev_by_name: name = cs0 filename = .ӿk
> ERROR: RENAUD: cdev_by_name: name = m25p0 filename = .ӿk
> ERROR: RENAUD: cdev_by_name: name = m25p0.barebox filename = .ӿk
> ERROR: RENAUD: cdev_by_name: name = m25p0.secondary-barebox filename = .ӿk
> ERROR: RENAUD: cdev_by_name: name = m25p0.barebox-environment filename = .ӿk
> …
> One can see the filename above is corrupted
>
> During reset:
> ERROR: RENAUD: devfs_open: cdevname = m25p0.boot-vars
> ERROR: RENAUD: cdev_by_name: name = cs0 filename = m25p0.boot-vars
> ERROR: RENAUD: cdev_by_name: name = m25p0 filename = m25p0.boot-vars
> ERROR: RENAUD: cdev_by_name: name = m25p0.barebox filename = m25p0.boot-vars
> ERROR: RENAUD: cdev_by_name: name = m25p0.secondary-barebox filename = m25p0.boot-vars
> ERROR: RENAUD: cdev_by_name: name = m25p0.barebox-environment filename = m25p0.boot-vars
> ERROR: RENAUD: cdev_by_name: name = m25p0.env-secondary filename = m25p0.boot-vars
> ERROR: RENAUD: cdev_by_name: name = m25p0.boot-vars filename = m25p0.boot-vars
> ERROR: RENAUD: cdev_by_name: found cdev m25p0.boot-vars
> ERROR: fs_remove: ENTER
> ERROR: ubifs_remove: ENTER
> ERROR: ubifs_remove: END
> ERROR: destroy_inode: inode = bff36380
> ERROR: destroy_inode: cdevname@ = bff3647c
> ERROR: RENAUD: destroy_inode cdevname: tc`, len = 5 ???
> !block_is_last(block)common/tlsf.c 253
> [<dfd8387c>] (unwind_backtrace+0x0/0xe4) from [<dfd0a0dc>] (block_next+0x38/0x48)
> [<dfd0a0dc>] (block_next+0x38/0x48) from [<dfd0a0f8>] (block_link_next+0xc/0x14)
> [<dfd0a0f8>] (block_link_next+0xc/0x14) from [<dfd0a76c>] (tlsf_free+0x48/0x108)
> [<dfd0a76c>] (tlsf_free+0x48/0x108) from [<dfd65a74>] (destroy_inode+0x84/0x188)
> [<dfd65a74>] (destroy_inode+0x84/0x188) from [<dfd671cc>] (dentry_kill+0x18/0x54)
> [<dfd671cc>] (dentry_kill+0x18/0x54) from [<dfd67e24>] (fs_remove+0x144/0x1b0)
> [<dfd67e24>] (fs_remove+0x144/0x1b0) from [<dfd12230>] (devices_shutdown+0x54/0x68)
> [<dfd12230>] (devices_shutdown+0x54/0x68) from [<dfd0221c>] (shutdown_barebox+0x44/0x58)
> [<dfd0221c>] (shutdown_barebox+0x44/0x58) from [<dfd48244>] (cmd_reset+0x114/0x154)
> [<dfd48244>] (cmd_reset+0x114/0x154) from [<dfd06160>] (execute_command+0x4c/0x90)
> [<dfd06160>] (execute_command+0x4c/0x90) from [<dfd0dc98>] (run_list_real.isra.0+0x810/0x8c0)
> [<dfd0dc98>] (run_list_real.isra.0+0x810/0x8c0) from [<dfd0d13c>] (parse_stream_outer+0x130/0x1f4)
> [<dfd0d13c>] (parse_stream_outer+0x130/0x1f4) from [<dfd0df04>] (run_shell+0x74/0xb4)
> [<dfd0df04>] (run_shell+0x74/0xb4) from [<dfd01e80>] (start_barebox+0x58/0x9c)
> [<dfd01e80>] (start_barebox+0x58/0x9c) from [<dfd7f1b8>] (barebox_non_pbl_start+0xc4/0xdc)
> [<dfd7f1b8>] (barebox_non_pbl_start+0xc4/0xdc) from [<dfd00004>] (__bare_init_start+0x0/0x10)
>
> Again, it seems there is memory corruption of cdevname
>
> Has anybody seen this?
>
> Note this is not happening with barebox v2025.12.0 and I did notice there was lots of rework on the fs directory from v2026.01
>
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: file system crash
2026-03-17 11:15 ` Ahmad Fatoum
@ 2026-03-17 14:31 ` Renaud Barbier
2026-03-25 13:39 ` Renaud Barbier
0 siblings, 1 reply; 4+ messages in thread
From: Renaud Barbier @ 2026-03-17 14:31 UTC (permalink / raw)
To: Ahmad Fatoum, Barebox List
I meant ARM Cortex-A9
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: 17 March 2026 11:16
> To: Renaud Barbier <Renaud.Barbier@ametek.com>; Barebox List
> <barebox@lists.infradead.org>
> Subject: Re: file system crash
>
> ***NOTICE*** This came from an external source. Use caution when
> replying, clicking links, or opening attachments.
>
> Hello Renaud,
>
> On 3/17/26 11:58 AM, Renaud Barbier wrote:
> > I have a BSP (not upstreamed) using a ARMv9 that I rebased fromv2025.06
> to 2026.01. This board has a SPI NOR with a UBI volume.
> > The system starts perfectly.
>
> ARMv9 or ARM9?
>
> Can you rerun with CONFIG_KASAN=y and report the output?
>
> Thanks,
> Ahmad
>
> >
> > When doing an umount or ls -l or reset barebox crashes. Debugging the
> code, the cdevname pointer in destroy_inode is sometimes (set to 0xffffffff)
> or the string corrupted. Also below the filename is corrupted.
> > OWBOOT> / ls -l /mnt/primary
> > ERROR: RENAUD: cdev_by_name: name = cs0 filename = .ӿk
> > ERROR: RENAUD: cdev_by_name: name = m25p0 filename = .ӿk
> > ERROR: RENAUD: cdev_by_name: name = m25p0.barebox filename = .ӿk
> > ERROR: RENAUD: cdev_by_name: name = m25p0.secondary-barebox
> filename =
> > .ӿk
> > ERROR: RENAUD: cdev_by_name: name = m25p0.barebox-environment
> filename
> > = .ӿk … One can see the filename above is corrupted
> >
> > During reset:
> > ERROR: RENAUD: devfs_open: cdevname = m25p0.boot-vars
> > ERROR: RENAUD: cdev_by_name: name = cs0 filename = m25p0.boot-vars
> > ERROR: RENAUD: cdev_by_name: name = m25p0 filename = m25p0.boot-
> vars
> > ERROR: RENAUD: cdev_by_name: name = m25p0.barebox filename =
> > m25p0.boot-vars
> > ERROR: RENAUD: cdev_by_name: name = m25p0.secondary-barebox
> filename =
> > m25p0.boot-vars
> > ERROR: RENAUD: cdev_by_name: name = m25p0.barebox-environment
> filename
> > = m25p0.boot-vars
> > ERROR: RENAUD: cdev_by_name: name = m25p0.env-secondary filename
> =
> > m25p0.boot-vars
> > ERROR: RENAUD: cdev_by_name: name = m25p0.boot-vars filename =
> > m25p0.boot-vars
> > ERROR: RENAUD: cdev_by_name: found cdev m25p0.boot-vars
> > ERROR: fs_remove: ENTER
> > ERROR: ubifs_remove: ENTER
> > ERROR: ubifs_remove: END
> > ERROR: destroy_inode: inode = bff36380
> > ERROR: destroy_inode: cdevname@ = bff3647c
> > ERROR: RENAUD: destroy_inode cdevname: tc`, len = 5 ???
> > !block_is_last(block)common/tlsf.c 253 [<dfd8387c>]
> > (unwind_backtrace+0x0/0xe4) from [<dfd0a0dc>] (block_next+0x38/0x48)
> > [<dfd0a0dc>] (block_next+0x38/0x48) from [<dfd0a0f8>]
> > (block_link_next+0xc/0x14) [<dfd0a0f8>] (block_link_next+0xc/0x14)
> > from [<dfd0a76c>] (tlsf_free+0x48/0x108) [<dfd0a76c>]
> > (tlsf_free+0x48/0x108) from [<dfd65a74>] (destroy_inode+0x84/0x188)
> > [<dfd65a74>] (destroy_inode+0x84/0x188) from [<dfd671cc>]
> > (dentry_kill+0x18/0x54) [<dfd671cc>] (dentry_kill+0x18/0x54) from
> > [<dfd67e24>] (fs_remove+0x144/0x1b0) [<dfd67e24>]
> > (fs_remove+0x144/0x1b0) from [<dfd12230>]
> (devices_shutdown+0x54/0x68)
> > [<dfd12230>] (devices_shutdown+0x54/0x68) from [<dfd0221c>]
> > (shutdown_barebox+0x44/0x58) [<dfd0221c>]
> (shutdown_barebox+0x44/0x58)
> > from [<dfd48244>] (cmd_reset+0x114/0x154) [<dfd48244>]
> > (cmd_reset+0x114/0x154) from [<dfd06160>]
> (execute_command+0x4c/0x90)
> > [<dfd06160>] (execute_command+0x4c/0x90) from [<dfd0dc98>]
> > (run_list_real.isra.0+0x810/0x8c0)
> > [<dfd0dc98>] (run_list_real.isra.0+0x810/0x8c0) from [<dfd0d13c>]
> > (parse_stream_outer+0x130/0x1f4) [<dfd0d13c>]
> > (parse_stream_outer+0x130/0x1f4) from [<dfd0df04>]
> > (run_shell+0x74/0xb4) [<dfd0df04>] (run_shell+0x74/0xb4) from
> > [<dfd01e80>] (start_barebox+0x58/0x9c) [<dfd01e80>]
> > (start_barebox+0x58/0x9c) from [<dfd7f1b8>]
> > (barebox_non_pbl_start+0xc4/0xdc) [<dfd7f1b8>]
> > (barebox_non_pbl_start+0xc4/0xdc) from [<dfd00004>]
> > (__bare_init_start+0x0/0x10)
> >
> > Again, it seems there is memory corruption of cdevname
> >
> > Has anybody seen this?
> >
> > Note this is not happening with barebox v2025.12.0 and I did notice
> > there was lots of rework on the fs directory from v2026.01
> >
> >
> >
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 |
> https://urldefense.com/v3/__http://www.pengutronix.de/__;!!HKOSU0g!Hv
> VLvDMwr4aG6adXKP423MJRiCOajT_knP3fHFk3vN4LRN7EFCIpUvSk44un5KtT
> BGf-4O9jlbZGI0ejeILvpghDZVQ$ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: file system crash
2026-03-17 14:31 ` Renaud Barbier
@ 2026-03-25 13:39 ` Renaud Barbier
0 siblings, 0 replies; 4+ messages in thread
From: Renaud Barbier @ 2026-03-25 13:39 UTC (permalink / raw)
To: Ahmad Fatoum, Barebox List
I have enabled KASAN but not output came from the barebox ELF. I can only see message from the PBL.
I later realize that if I replace in start_barebox, "pr_debug("initcall-> %pS\n", *initcall);" by just puts("call initcall\n"); I get two outputs
So that means the barebox load does not comes out of globalvar_init.
I did see a store instructions of value 0xf1f1f1f1 to an invalid address using my ICE. Wonder if F1 could be related to
#define KASAN_STACK_LEFT 0xF1
I skipped KASAN that for now and using old fashion debugging came down to:
static struct inode *ubifs_alloc_inode(struct super_block *sb)
{
struct ubifs_inode *ui;
ui = kmem_cache_alloc(ubifs_inode_slab, GFP_NOFS);
if (!ui)
return NULL;
memset((void *)ui + sizeof(struct inode), 0,
sizeof(struct ubifs_inode) - sizeof(struct inode));
mutex_init(&ui->ui_mutex);
spin_lock_init(&ui->ui_lock);
+
return &ui->vfs_inode;
};
This function does not clear ui->vfs_inode which can contain stale data.
If I add ui->vfs_inode.cdevname = NULL; the crash described a few email down below does not appears and I can see the contain of the directory. Doing so, it is likely I am hiding the real problem.
ls -l /mnt/primary/
ERROR: S_IFLNK: alloc ui->data = bfd2cd80 ***
lrwxrwxrwx 12 fit.itb -> fitImage.itb
-rwxr-xr-x 8327352 fitImage.itb
...
Calling the reset command later, I see:
OWBOOT> / reset
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfd29800
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee8140
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee82c0
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee7e80
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee8000
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee7bc0
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee7d40
ERROR: RENAUD: ubifs_destroy_inode ui->data = bfd2cd80 ***
ERROR: RENAUD: tlsf_free: freeing ptr = 0xbfd2cd80, block = 0xbfd2cd74, size = 67
!block_is_free(block) && "block already marked as free"common/tlsf.c 1061 [<dfd84abc>] (unwind_backtrace+0x0/0xe4) from [<dfd0b520>] (tlsf_free+0x70/0x144) [<dfd0b520>] (tlsf_free+0x70/0x144) from [<dfd6bb40>] (ubifs_destroy_inode+0x30/0x60) [<dfd6bb40>] (ubifs_destroy_inode+0x30/0x60) from [<dfd67328>] (destroy_inode+0x40/0x50) [<dfd67328>] (destroy_inode+0x40/0x50) from [<dfd6898c>] (dentry_kill+0x18/0x54) [<dfd6898c>] (dentry_kill+0x18/0x54) from [<dfd68a00>] (dentry_delete_subtree.isra.0+0x38/0x48)
ERROR: RENAUD: ubifs_destroy_inode ui = bfd2c380
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee7940
ERROR: RENAUD: ubifs_destroy_inode ui->data = 00000000
ERROR: RENAUD: ubifs_destroy_inode ui = bfee7800
Keeping investigating, this issue
> -----Original Message-----
> From: barebox <barebox-bounces@lists.infradead.org> On Behalf Of Renaud
> Barbier
> Sent: 17 March 2026 14:32
> To: Ahmad Fatoum <a.fatoum@pengutronix.de>; Barebox List
> <barebox@lists.infradead.org>
> Subject: RE: file system crash
>
> ***NOTICE*** This came from an external source. Use caution when
> replying, clicking links, or opening attachments.
>
> I meant ARM Cortex-A9
>
> > -----Original Message-----
> > From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> > Sent: 17 March 2026 11:16
> > To: Renaud Barbier <Renaud.Barbier@ametek.com>; Barebox List
> > <barebox@lists.infradead.org>
> > Subject: Re: file system crash
> >
> > ***NOTICE*** This came from an external source. Use caution when
> > replying, clicking links, or opening attachments.
> >
> > Hello Renaud,
> >
> > On 3/17/26 11:58 AM, Renaud Barbier wrote:
> > > I have a BSP (not upstreamed) using a ARMv9 that I rebased
> > > fromv2025.06
> > to 2026.01. This board has a SPI NOR with a UBI volume.
> > > The system starts perfectly.
> >
> > ARMv9 or ARM9?
> >
> > Can you rerun with CONFIG_KASAN=y and report the output?
> >
> > Thanks,
> > Ahmad
> >
> > >
> > > When doing an umount or ls -l or reset barebox crashes. Debugging
> > > the
> > code, the cdevname pointer in destroy_inode is sometimes (set to
> > 0xffffffff) or the string corrupted. Also below the filename is corrupted.
> > > OWBOOT> / ls -l /mnt/primary
> > > ERROR: RENAUD: cdev_by_name: name = cs0 filename = .ӿk
> > > ERROR: RENAUD: cdev_by_name: name = m25p0 filename = .ӿk
> > > ERROR: RENAUD: cdev_by_name: name = m25p0.barebox filename = .ӿk
> > > ERROR: RENAUD: cdev_by_name: name = m25p0.secondary-barebox
> > filename =
> > > .ӿk
> > > ERROR: RENAUD: cdev_by_name: name = m25p0.barebox-environment
> > filename
> > > = .ӿk … One can see the filename above is corrupted
> > >
> > > During reset:
> > > ERROR: RENAUD: devfs_open: cdevname = m25p0.boot-vars
> > > ERROR: RENAUD: cdev_by_name: name = cs0 filename = m25p0.boot-
> vars
> > > ERROR: RENAUD: cdev_by_name: name = m25p0 filename =
> m25p0.boot-
> > vars
> > > ERROR: RENAUD: cdev_by_name: name = m25p0.barebox filename =
> > > m25p0.boot-vars
> > > ERROR: RENAUD: cdev_by_name: name = m25p0.secondary-barebox
> > filename =
> > > m25p0.boot-vars
> > > ERROR: RENAUD: cdev_by_name: name = m25p0.barebox-environment
> > filename
> > > = m25p0.boot-vars
> > > ERROR: RENAUD: cdev_by_name: name = m25p0.env-secondary
> filename
> > =
> > > m25p0.boot-vars
> > > ERROR: RENAUD: cdev_by_name: name = m25p0.boot-vars filename =
> > > m25p0.boot-vars
> > > ERROR: RENAUD: cdev_by_name: found cdev m25p0.boot-vars
> > > ERROR: fs_remove: ENTER
> > > ERROR: ubifs_remove: ENTER
> > > ERROR: ubifs_remove: END
> > > ERROR: destroy_inode: inode = bff36380
> > > ERROR: destroy_inode: cdevname@ = bff3647c
> > > ERROR: RENAUD: destroy_inode cdevname: tc`, len = 5 ???
> > > !block_is_last(block)common/tlsf.c 253 [<dfd8387c>]
> > > (unwind_backtrace+0x0/0xe4) from [<dfd0a0dc>]
> (block_next+0x38/0x48)
> > > [<dfd0a0dc>] (block_next+0x38/0x48) from [<dfd0a0f8>]
> > > (block_link_next+0xc/0x14) [<dfd0a0f8>] (block_link_next+0xc/0x14)
> > > from [<dfd0a76c>] (tlsf_free+0x48/0x108) [<dfd0a76c>]
> > > (tlsf_free+0x48/0x108) from [<dfd65a74>] (destroy_inode+0x84/0x188)
> > > [<dfd65a74>] (destroy_inode+0x84/0x188) from [<dfd671cc>]
> > > (dentry_kill+0x18/0x54) [<dfd671cc>] (dentry_kill+0x18/0x54) from
> > > [<dfd67e24>] (fs_remove+0x144/0x1b0) [<dfd67e24>]
> > > (fs_remove+0x144/0x1b0) from [<dfd12230>]
> > (devices_shutdown+0x54/0x68)
> > > [<dfd12230>] (devices_shutdown+0x54/0x68) from [<dfd0221c>]
> > > (shutdown_barebox+0x44/0x58) [<dfd0221c>]
> > (shutdown_barebox+0x44/0x58)
> > > from [<dfd48244>] (cmd_reset+0x114/0x154) [<dfd48244>]
> > > (cmd_reset+0x114/0x154) from [<dfd06160>]
> > (execute_command+0x4c/0x90)
> > > [<dfd06160>] (execute_command+0x4c/0x90) from [<dfd0dc98>]
> > > (run_list_real.isra.0+0x810/0x8c0)
> > > [<dfd0dc98>] (run_list_real.isra.0+0x810/0x8c0) from [<dfd0d13c>]
> > > (parse_stream_outer+0x130/0x1f4) [<dfd0d13c>]
> > > (parse_stream_outer+0x130/0x1f4) from [<dfd0df04>]
> > > (run_shell+0x74/0xb4) [<dfd0df04>] (run_shell+0x74/0xb4) from
> > > [<dfd01e80>] (start_barebox+0x58/0x9c) [<dfd01e80>]
> > > (start_barebox+0x58/0x9c) from [<dfd7f1b8>]
> > > (barebox_non_pbl_start+0xc4/0xdc) [<dfd7f1b8>]
> > > (barebox_non_pbl_start+0xc4/0xdc) from [<dfd00004>]
> > > (__bare_init_start+0x0/0x10)
> > >
> > > Again, it seems there is memory corruption of cdevname
> > >
> > > Has anybody seen this?
> > >
> > > Note this is not happening with barebox v2025.12.0 and I did notice
> > > there was lots of rework on the fs directory from v2026.01
> > >
> > >
> > >
> >
> > --
> > Pengutronix e.K. | |
> > Steuerwalder Str. 21 |
> >
> https://urldefense.com/v3/__http://www.pengutronix.de/__;!!HKOSU0g!Hv
> >
> VLvDMwr4aG6adXKP423MJRiCOajT_knP3fHFk3vN4LRN7EFCIpUvSk44un5KtT
> > BGf-4O9jlbZGI0ejeILvpghDZVQ$ |
> > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-03-25 13:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-03-17 10:58 file system crash Renaud Barbier
2026-03-17 11:15 ` Ahmad Fatoum
2026-03-17 14:31 ` Renaud Barbier
2026-03-25 13:39 ` Renaud Barbier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox