Mark Johnston

New panic today: ``` panic: refcount 0xffffa0808003f708 wraparound cpuid = 3 time = 1721744621 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x34 vpanic() at vpanic+0x13c panic() at panic+0x64 __drm_atomic_helper_connector_destroy_state()...

> @rwatson @markjdb @bukinr I found the bug and have a C program that can reproduce the panic. Thank you for the thorough investigation. The links to your reproducers don't...

At long last, I believe that the panics reported here are now fixed in `dev`.

> The same should be fixed in zvol_cdev_open() on FreeBSD and also in zvol_open() on Linux. I pushed an updated patch.

> I don't know why SET_ERROR() ended up different different, but ZFS uses DTRACE_PROBE1() macro in plenty of places. I am not sure what is the difference from SDT_PROBE1(), but...

This apparent bug was introduced in commit `0409d3327371 ("Improve zpool status output, list all affected datasets")`, perhaps @gamanakis could take a look?

> @markjdb could you take a look at #16273? Once it runs through the ZTS I will mark it as non-draft. It looks fine to me. I applied the patch...

> > @markjdb could you take a look at #16273? Once it runs through the ZTS I will mark it as non-draft. > > It looks fine to me. I...

> > I would also drop the sysexits change, as we generally don't add new uses of them. > > @markjdb: The termination status macros are from the standard C...

> @asomers I’m happy to revise this, but I’m not very familiar with FreeBSD’s testing infrastructure. Are you requesting that I rewrite the tests in C specifically? I would feel...