Re: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ /..../sys/cam/nvme/nvme_da.c:469

2024-05-25 Thread Alexander Leidinger
Am 2024-05-22 22:45, schrieb Alexander Leidinger: Am 2024-05-22 20:53, schrieb Warner Losh: First order: Looks like we're trying to schedule a trim, but that fails due to a malloc issue. So then, since it's a malloc issue, we wind up trying to automatically reschedule this I/O, which recurs

Re: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ /..../sys/cam/nvme/nvme_da.c:469

2024-05-22 Thread Alexander Leidinger
Am 2024-05-22 20:53, schrieb Warner Losh: First order: Looks like we're trying to schedule a trim, but that fails due to a malloc issue. So then, since it's a malloc issue, we wind up trying to automatically reschedule this I/O, which recurses into the driver with a bad lock held and boop.

Re: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ /..../sys/cam/nvme/nvme_da.c:469

2024-05-22 Thread Warner Losh
First order: Looks like we're trying to schedule a trim, but that fails due to a malloc issue. So then, since it's a malloc issue, we wind up trying to automatically reschedule this I/O, which recurses into the driver with a bad lock held and boop. Can you reproduce this? If so, can you test thi

_mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ /..../sys/cam/nvme/nvme_da.c:469

2024-05-22 Thread Alexander Leidinger
Hi, I got the panic in $Subject. Anyone an idea? Complete crashlog available at https://wiki.leidinger.net/core.txt.6 (1.2 MB) Short version: ---snip--- [11417] KDB: stack backtrace: [11417] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe043133f830 [11417] vpanic() at v