* 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