From owner-freebsd-arm@freebsd.org Fri Jul 6 16:33:08 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC5431038281 for ; Fri, 6 Jul 2018 16:33:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60D9189CDD for ; Fri, 6 Jul 2018 16:33:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id A974E10AFD4; Fri, 6 Jul 2018 12:33:07 -0400 (EDT) Subject: Re: RPI3B+ UFS filesystem issues To: Stefan Parvu , freebsd-arm@freebsd.org References: From: John Baldwin Message-ID: <3ac73628-4174-1277-67d9-fadd16e50891@FreeBSD.org> Date: Fri, 6 Jul 2018 09:33:06 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 06 Jul 2018 12:33:07 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 16:33:08 -0000 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