On Tue, Jun 24, 2025 at 05:21:56PM +0200, Jeremie Courreges-Anglas wrote: > > I think it's uvm_purge(), as far as I can see it happens when building > rust with cvs up -D2025/06/04 in /sys, not with -D2025/06/03. Maybe I > missed lang/rust when testing the diff. > > This is with additional MP_LOCKDEBUG support for mutexes, and > __mp_lock_spinout = 50L * INT_MAX. > > Suggested by claudio: tr /t 0t269515 fails.
Should be fixed, at least for CPUs that ddb actually managed to stop... > WITNESS doesn't flag an obvious lock ordering issue. I'm not even > sure there is one. It also happen with CPU_MAX_BUSY_CYCLES == 64. > > Maybe we're still hammering too much the locks? Input and ideas to > test welcome. Right now I'm running with just uvm_purge() reverted. Reverting uvm_purge() did not help. I've been able to reproduce the hangs up to cvs up -D2025/05/18, backporting the arm64 ddb trace fix, mpi's mutex backoff diff and the mtx_enter MP_LOCKDEBUG diff. Currently trying to reproduce with cvs up -D2025/05/07 as suggested by dlg. -- jca
