On 22.4.2021. 13:42, Mark Kettenis wrote: >> Date: Thu, 22 Apr 2021 13:09:34 +0200 >> From: Alexander Bluhm <alexander.bl...@gmx.net> >> >> On Thu, Apr 22, 2021 at 12:33:13PM +0200, Hrvoje Popovski wrote: >>> r620-1# papnpaiancini:cc :p :op >>> opooolo_llc_ac_caccahhceh_ei_eti_tieetmme_mm__amgamigacigci__cc_hccehhcekcekc:: >>> k :m bmubmfubfuppflp llc pc pcuup uf rfferree eel el iilsitss tm tom >>> omddoidfiiifeifeidde:d ::i ti etietmme m >>> a daddardd rd0 r0 >>> xx0fxfffffffffffffddf88d08c0cc0c6c76afc9b3f04500400++01+61 610 6x0 >>> fx0fxffffffffffdffdf88d08 >>> 00020720d72a8c0049703eb!ef!e==!0=x009x59x95995b9ebbaee3ae3ae344ef54f5a4bff7db07990a9 >> >> Wow. 3 CPUs panic in pool_cache_get() pool_cache_item_magic_check >> simultaneously. This makes me think we may have a bug there. > > Note that POOL_DEBUG was disabled until very recently. That may > affect both: > > 1. The point at which pool corruption is reported >
when i'm sending report i have witness enabled with kern.pool_debug=1 kern.splassert=2 > 2. The benchmark results. benchmark results are without pool_debug although differences are not so big .. to send panic without pool_debug and splassert?
