Jorgen Lundman

I appreciate very much you made it part of ICP, it means nearly no work needs to be done for me.

Are these related? ``` In file included from /var/lib/buildbot/slaves/zfs/FreeBSD_stable_13_amd64__TEST_/build/zfs/module/os/freebsd/zfs/dmu_os.c:39: /var/lib/buildbot/slaves/zfs/FreeBSD_stable_13_amd64__TEST_/build/zfs/include/sys/dmu_objset.h:76:15: error: field 'os_meta_dnode' with variable sized type 'dnode_phys_t' (aka 'struct dnode_phys') not at the end of a struct or class...

Ah ok, fixed the build bot so it runs, next freebsd can fix the build :)

I'll have look, I was more worried I had broken it

Old ticket, but came across something similar at https://github.com/openzfsonwindows/openzfs/issues/364#issuecomment-2101862948 I wonder if `failmode=continue` is in use here as well, and if there was a `zio_wait restarting hung I/O for pool`...

Can we have the `asm_linkage.h` changes in here, or do I need to do them in a future PR?

macOS results - unsure if not using `x18` changed anything, but then I can crash it using `generic` as well. This adds `asm_linkage,h` for aarch64 [f6fa7f5a584d4bbf889974e3bacb237a60dd7e95](https://github.com/openzfsonosx/openzfs-fork/commit/f6fa7f5a584d4bbf889974e3bacb237a60dd7e95) These are the changes...

Oh I see, ok I can fix macOS with: ``` #if defined(_KERNEL) && !defined(__APPLE__) BLAKE3_CTX *ctx = blake3_per_cpu_ctx[CPU_SEQID_UNSTABLE]; #else BLAKE3_CTX *ctx = kmem_alloc(sizeof (*ctx), KM_SLEEP); #endif ``` Ie, allocate it...

> The part below can't be changed to !APPLE within kernel space... the KM_SLEEP may sleep and some state is vanished then, because entering another cpu. Ah interesting. `kmem_alloc()` worked...

> We should include the PAGE and PAGEOFF defines for aarch64 in FreeBSD an Linux within this patchset also ... Ah I missed that, they are just empty on those...