Date: Fri, 6 Jul 2018 09:33:06 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Stefan Parvu <sparvu@kronometrix.org>, freebsd-arm@freebsd.org Subject: Re: RPI3B+ UFS filesystem issues Message-ID: <3ac73628-4174-1277-67d9-fadd16e50891@FreeBSD.org> In-Reply-To: <B58A2AD4-D74F-4D17-9E5E-BF1A802DB71C@kronometrix.org> References: <B58A2AD4-D74F-4D17-9E5E-BF1A802DB71C@kronometrix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/3/18 10:07 PM, Stefan Parvu wrote: > Are these signal of troubles form the filesystem layer ? Im using a Transcend 64GB > https://fi.transcend-info.com/Products/No-697. Dont know if I can benefit from this > card of its full speed on RPI3B+ . > > Im using FreeBSD 12.0 current latest 28 June snapshot: > FreeBSD generic 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r335760: Thu Jun 28 16:32:04 UTC 2018 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 > > lock order reversal: > 1st 0xffff000040d299f0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3916 > 2nd 0xfffffd001582ba00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:289 > stack backtrace: > #0 0xffff0000003eb5e4 at witness_debugger+0x64 > #1 0xffff00000038f2cc at _sx_xlock+0x7c > #2 0xffff0000006124d4 at ufsdirhash_add+0x38 > #3 0xffff000000614f68 at ufs_direnter+0x3b0 > #4 0xffff00000061d43c at ufs_makeinode+0x4b8 > #5 0xffff000000619b14 at ufs_create+0x38 > #6 0xffff0000006ccf10 at VOP_CREATE_APV+0xac > #7 0xffff00000045d9c4 at vn_open_cred+0x264 > #8 0xffff000000456d00 at kern_openat+0x208 > #9 0xffff000000696128 at do_el0_sync+0x4b0 > #10 0xffff00000067c9f0 at handle_el0_sync+0x74 > lock order reversal: > 1st 0xfffffd00038a39c8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1677 > 2nd 0xffff000040d299f0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:282 > 3rd 0xfffffd00038a37e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2572 > stack backtrace: > #0 0xffff0000003eb5e4 at witness_debugger+0x64 > #1 0xffff00000035c340 at lockmgr_xlock_hard+0x6c > #2 0xffff00000035cbbc at __lockmgr_args+0x4ac > #3 0xffff00000060da28 at ffs_lock+0x88 > #4 0xffff0000006cfc58 at VOP_LOCK1_APV+0xac > #5 0xffff00000045e050 at _vn_lock+0x64 > #6 0xffff00000044e5b8 at vget+0x78 > #7 0xffff0000004413bc at vfs_hash_get+0xec > #8 0xffff000000609a58 at ffs_vgetf+0x44 > #9 0xffff000000600698 at softdep_sync_buf+0x9f4 > #10 0xffff00000060e764 at ffs_syncvnode+0x26c > #11 0xffff0000005e8738 at ffs_truncate+0x6b4 > #12 0xffff000000615330 at ufs_direnter+0x778 > #13 0xffff00000061d43c at ufs_makeinode+0x4b8 > #14 0xffff000000619b14 at ufs_create+0x38 > #15 0xffff0000006ccf10 at VOP_CREATE_APV+0xac > #16 0xffff00000045d9c4 at vn_open_cred+0x264 > #17 0xffff000000456d00 at kern_openat+0x208 No these are known false positives in the lock order verifier. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ac73628-4174-1277-67d9-fadd16e50891>