ci4...@gmail.com (Chavdar Ivanov) writes: >I just got: >--------------
>Nov 4 11:50:40 rpi /netbsd: [ 91750.0747877] panic: kernel diagnostic >assertion "(flags & (PR_WAITOK|PR_NOWAIT)) == PR_NOWAIT" failed: file >"/home/sysbuild/src/sys/kern/subr_pool.c", line 864 >Nov 4 11:50:40 rpi /netbsd: [ 91750.0747877] cpu0: Begin traceback... >Nov 4 11:50:40 rpi /netbsd: [ 91750.0950326] 0x8b519d5c: netbsd:db_panic+0xc >Nov 4 11:50:40 rpi /netbsd: [ 91750.0950326] 0x8b519d74: netbsd:vpanic+0x138 >Nov 4 11:50:40 rpi /netbsd: [ 91750.0950326] 0x8b519d8c: >netbsd:kern_assert+0x40 >Nov 4 11:50:40 rpi /netbsd: [ 91750.1050626] 0x8b519de4: netbsd:pool_get+0x728 >Nov 4 11:50:40 rpi /netbsd: [ 91750.1050626] 0x8b519e2c: >netbsd:pool_cache_get_slow+0x1c0 >Nov 4 11:50:40 rpi /netbsd: [ 91750.1156185] 0x8b519e74: >netbsd:pool_cache_get_paddr+0x224 >Nov 4 11:50:40 rpi /netbsd: [ 91750.1156185] 0x8b519f14: netbsd:fork1+0x9c That's uvm_uarea_alloc() failing, which must not happen. The bug seems to be in uarea_poolpage_alloc() that may return NULL if PMAP_MAP_POOLPAGE fails, even when called with PR_WAITOK. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."