1. Fix interface removal panic when there are entries in the queue. (reported by @glebius)
2. Fix late call to KASSERT. @glebius done.

OK, looks like adding the "-usb -usbdevice mouse" option to qemu causes the panic Adrian saw.

FWIW on my POWER9 qemu box, I get a good boot even with the USB controller turned on:

Sigh. Can you share your qemu command line so we're testing using the same peripherals / CPU setup?

nope, still no dice

ok, lemme try this latest one in qemu real quick, hold.

Fourth time's the charm? Tested to work on both pSeries/POWER9 and PowerNV/POWER9 -- hopefully POWER8 is similarly functional.

Thanks for the check. I'm able to reproduce and am working on it. On initial glance, it looks like we're calling bounce_bus_dmamap_complete() on a tag that was never created with bounce_bus_dmamap_create(), and I need to find out if that's expected or something we need to trap / ignore.

Is this going to be MFC'ed?

Here is the report sorted by authors of the commit (if someone desires to check descripton and section attribution)

I continue to look for keyworkd to locate documentation commits ('Man Pages' section) . Previous relnotes have much more man entries, comparing to this version.

Update with feedback

Ok, lets see how it goes. If it starts break again, I will put if SIZEOF_LONG==8 around the code in sys/event.h and kern/kern_umtx.c etc.

Quoting part of my recent mail on src-committers@:

But since there are uses of 'freebsd32.h' unconditionally on all platforms (in 'kern_umtx.c' at least), and since we also check sizes of structures, I think we should at least ensure that 'struct foo32' on a 32-bit arch is type compatible with 'struct foo' on the same arch.

And I do not see that as unsustainable, on the contrary, it is very simple to achieve: Have all 'foo32' types boil down to exactly 'foo' on 32-bit architectures, which is what we are supposed to do already for structures by compat' design. 'freebsd32_uint64_t' you introduced typically supports that. That's the why of https://reviews.freebsd.org/D55283, which fixes commit 87632ddf67b0 ("openzfs sys/types32.h: use abi_compat.h for time32_t") where defining 'time32_t' to 'in32_t' for 32-bit architectures appears to have been an arbitrary choice of yours, which in practice by luck does not change the whole size of 'struct ffclock_estimate32' because 'struct bintime32''s one does not change either as even if its field 'sec' was incorrectly sized after you commit (this is what D55283 fixes), the 'frac' one is 64-bit and 64-bit aligned on all non-x86 architectures so its offset in 'struct bintime32' stays the same.

So, again, I think the rule of thumb should just be: Type 'foo32' is compatible with 'foo' on 32-bit architectures and has same alignment. That's the only thing that makes sense if 'struct *32' are visible on 32-bit architectures.

Sorry, I am back again, I am going to take a look this weekend.