On Sun, May 21, 2023 at 06:11:42PM -0400, Kurt Miller wrote: > > > > On May 17, 2023, at 2:39 PM, Kurt Miller <k...@intricatesoftware.com> wrote: > > > > On May 13, 2023, at 3:07 PM, Kurt Miller <k...@intricatesoftware.com > > <mailto:k...@intricatesoftware.com>> wrote: > >> > >> On May 13, 2023, at 9:16 AM, Kurt Miller <k...@intricatesoftware.com> > >> wrote: > >>> > >>> On May 12, 2023, at 10:26 AM, Martin Pieuchot <m...@openbsd.org> wrote: > >>>> > >>>> On 09/05/23(Tue) 20:02, Kurt Miller wrote: > >>>>> While building devel/jdk/1.8 on May 3rd snapshot I noticed the build > >>>>> freezing > >>>>> and processes getting stuck like ps. After enabling ddb.console I was > >>>>> able to > >>>>> reproduce the livelock and capture cpu traces. Dmesg at the end. > >>>>> Let me know if more information is needed as this appears to be rather > >>>>> reproducible on my T4-1. > >>>> > >>>> It seems that all CPUs are waiting for the KERNEL_LOCK(). Doing ps /o > >>>> in ddb(4) should show us which CPU is currently holding it. I can't > >>>> figure it out just by looking at the traces below. > >>>> > > I managed to get WITNESS working on sparc64. Here’s what it found: > > ddb{0}> show witness /b > Number of known direct relationships is 255 > > Lock order reversal between "&mp->mnt_lock"(rwlock) and > "&ip->i_lock"(rrwlock)! > Lock order "&mp->mnt_lock"(rwlock) -> "&ip->i_lock"(rrwlock) first seen at: > #0 rrw_enter+0x58 > #1 VOP_LOCK+0x5c > #2 vn_lock+0x9c > #3 vget+0x12c > #4 cache_lookup+0x308 > #5 ufs_lookup+0x11c > #6 VOP_LOOKUP+0x40 > #7 vfs_lookup+0x2fc > #8 namei+0x37c > #9 ffs_mount+0x340 > #10 sys_mount+0x2fc > #11 syscall+0x3c4 > #12 syscall_setup+0x134 > > Lock order "&ip->i_lock"(rrwlock) -> "&mp->mnt_lock"(rwlock) first seen at: > #0 vfs_busy+0x34 > #1 vfs_lookup+0x39c > #2 namei+0x37c > #3 sys___realpath+0x1bc > #4 syscall+0x3c4 > #5 syscall_setup+0x134 >
I have seen these WITNESS warnings on other systems as well. I doubt this is the problem. IIRC this warning is because sys_mount() is doing it wrong but it is not really an issue since sys_mount is not called often. -- :wq Claudio
