Re: panic: ffs_valloc: dup alloc

2023-03-17 Thread Vitaliy Makkoveev
> On 17 Mar 2023, at 22:53, Moritz Buhl wrote: > > Any better names? > "ffs-node-lock" > "ffsndlock" ffsnodelk or ffsndlck if the length shouldn’t exceed 8.

Re: panic: ffs_valloc: dup alloc

2023-03-17 Thread Moritz Buhl
Below is an updated diff addressing the following concerns: On Fri, Mar 17, 2023 at 03:45:59PM +0100, Alexander Bluhm wrote: > The FreeBSD Code puts the check_nifree label before the if > (fs->fs_cs(fs, cg).cs_nifree == 0) check. Could you move this chunk > a little up to keep us in sync? On Fri

Re: panic: ffs_valloc: dup alloc

2023-03-17 Thread Mark Kettenis
till active. > ahci0: stopping the port, softreset slot 31 was still active. > ahci0: stopping the port, softreset slot 31 was still active. > ahci0: stopping the port, softreset slot 31 was still active. > ahci0: device didn't come ready after reset, TFD: 0x441 > ahci0: device didn&#

Re: panic: ffs_valloc: dup alloc

2023-03-17 Thread Alexander Bluhm
On Fri, Mar 17, 2023 at 03:23:19PM +0100, Moritz Buhl wrote: > FreeBSD fixed this in 2013: > https://github.com/freebsd/freebsd-src/commit/94f4ac214c403b99cbc44dd6e9cdf4db2cc9b297 > > Below is a diff that addresses this with a exclusive lock > using RW_SLEEPFAIL. The FreeBSD Code puts the check_n

panic: ffs_valloc: dup alloc

2023-03-17 Thread Moritz Buhl
ive. ahci0: device didn't come ready after reset, TFD: 0x441 ahci0: device didn't come ready after reset, TFD: 0x441 mode = 0100644, inum = 7731315, fs = /var panic: ffs_valloc: dup alloc Stopped at db_enter+0x10: popq%rbp TIDPIDUID PRFLAGS PFLAGS CPU COMMAN