zeke icon indicating copy to clipboard operation
zeke copied to clipboard

Mounting a third fatfs sb causes crashes

Open OlliV opened this issue 4 years ago • 1 comments

It seems to be a race condition as it looks like everything is working better and better when more debugging is enabled, e.g. enabling proc.c dyndebug almost fixes it. The crash doesn't always happen immediately when a fatfs is accessed but after a few commands that will read the fs.

# mount -t fatfs /dev/emmc0p2 /home
4:fs/fatfs/fatfs.c:429: fatfs::create_inode: retval for //tish.histfile: -45
4:fs/fatfs/fatfs.c:429: fatfs::create_inode: retval for //tish.histfile: -45
4:fs/fatfs/fatfs.c:398: fatfs::create_inode: Create & open ok
4:fs/fatfs/fatfs.c:419: fatfs::create_inode: ok
4:fs/fatfs/src/ff.c:522: sync_fs(fs b0x0080a2fc)
4:fs/fatfs/fatfs_diskio.c:134: fatfs_disk_ioctl(ff_fs 8, cmd 24, buff b0x00000000, bsize 0)
4:fs/fatfs/src/ff.c:522: sync_fs(fs b0x0080a2fc)
4:fs/fatfs/fatfs_diskio.c:134: fatfs_disk_ioctl(ff_fs 8, cmd 24, buff b0x00000000, bsize 0)
4:fs/fatfs/fatfs.c:820: fatfs:0::fatfs_mknod: ok
4:fs/fatfs/src/ff.c:2495: f_sync(fp b0x0085012c)
4:fs/fatfs/src/ff.c:522: sync_fs(fs b0x0080a2fc)
4:fs/fatfs/fatfs_diskio.c:134: fatfs_disk_ioctl(ff_fs 8, cmd 24, buff b0x00000000, bsize 0)
4:fs/fatfs/fatfs.c:656: fatfs:11::fatfs_lookup: vn found in vfs_hash (b0x00814994)
4:fs/fatfs/fatfs.c:429: fatfs::create_inode: retval for //usr/bin: -45
4:fs/fatfs/fatfs.c:656: fatfs:14::fatfs_lookup: vn found in vfs_hash (b0x00811784)
4:fs/fatfs/fatfs.c:656: fatfs:2726::fatfs_lookup: vn found in vfs_hash (b0x0081adb4)
4:fs/fatfs/src/ff.c:2495: f_sync(fp b0x0081ae1c)
mount: flags: 0, options: "", vfstype: "fatfs" src: "/dev/emmc0p2", dst: "/home"
4:fs/fatfs/fatfs.c:400: fatfs::create_inode: Open ok
4:fs/fatfs/fatfs.c:419: fatfs::create_inode: ok
4:fs/fatfs/fatfs.c:656: fatfs:3::fatfs_lookup: vn found in vfs_hash (b0x0080c414)
4:fs/fatfs/fatfs_diskio.c:134: fatfs_disk_ioctl(ff_fs 9, cmd 21, buff b0x008e3c1e, bsize 2)
4:fs/fatfs/fatfs.c:400: fatfs::create_inode: Open ok
4:fs/fatfs/fatfs.c:1132: fatfs:0::get_mp_stat: mp not set
2:fs/fatfs/fatfs.c:967: fatfs:0::fatfs_stat: vnode->sb->mountpoint should be set
4:fs/fatfs/fatfs.c:419: fatfs::create_inode: ok
# ls
4:fs/fatfs/fatfs.c:656: fatfs:0::fatfs_lookup: vn found in vfs_hash (b0x008500c4)
4:fs/fatfs/src/ff.c:2495: f_sync(fp b0x0085012c)
4:fs/fatfs/src/ff.c:522: sync_fs(fs b0x0080a2fc)
4:fs/fatfs/fatfs_diskio.c:134: fatfs_disk_ioctl(ff_fs 8, cmd 24, buff b0x00000000, bsize 0)
4:fs/fatfs/fatfs.c:656: fatfs:11::fatfs_lookup: vn found in vfs_hash (b0x00814994)
4:fs/fatfs/fatfs.c:429: fatfs::create_inode: retval for //usr/bin: -45
4:fs/fatfs/fatfs.c:656: fatfs:14::fatfs_lookup: vn found in vfs_hash (b0x00811784)
4:fs/fatfs/fatfs.c:656: fatfs:2594::fatfs_lookup: vn found in vfs_hash (b0x008380f4)
4:fs/fatfs/src/ff.c:2495: f_sync(fp b0x0083815c)
0:hal/arm11/arm11_mmu_dab.c:160: DAB handling failed: -59
0:hal/mmu.c:223: Fatal Data Abort:
pc: 0x0003f554
(i)fsr: 0x00000005 (Section translation)
(i)far: 0x00a4d374
proc info:
pid: 9
tid: 23
name: ls
insys: 0
psr = 0x20000192
r0  = 0x00a4d374
r1  = 0x00000000
r2  = 0x00000000
r3  = 0x00000001
r4  = 0x00021e28
r5  = 0x00000009
r6  = 0x00000000
r7  = 0x00300290
r8  = 0x00002000
r9  = 0x00000002
r10 = 0x00001f08
r11 = 0x0ffff010
r12 = 0x00a4d4a8
sp  = 0x00001e98
lr  = 0x00021e28
pc  = 0x0003f554
Oops, Kernel panic
hal/arm11/arm11_mmu_dab.c:192:  Can't handle data abort

OlliV avatar Jun 13 '20 13:06 OlliV

Before c94e57c0b982a979f958594db02bc94029ae3c24 there was no clear error shown but instead everything was just stuck. When it occurred with proc.c dyndebug, it was then apparent that the COW handler was spinning in a DAB loop.

OlliV avatar Jun 13 '20 13:06 OlliV