> 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
