Indeed, this review packs two distinct changes. It targets the deterministic cache/lookup result, exactly as you suggested, so all cached/uncached always performs in same fashion. After untangling the ifp/originifp complexities, it resulted in empty if` condition after /* Check for valid scope ID. */, which made me think of simplifying the scope checks code as well. I'll split this diff into two, to simplify reviewing.

I am not sure if I currently can review this technically in full but we fixed a similar issue by the code you are currently changing in ef0111fdf364e4e87b522025b13aad69067c3fe6 .

I still do not like the idea that layer specifics are inside mbuf structs; I have not committed the @rrs approved https://reviews.freebsd.org/D34298 for reasons that I thought it'll need more discussions.

Do we need to bump the FreeBSD version for this - no?

I'd probably say "Dragonfly via drm-kmod" as you obtained it from drm-kmod?

Makes more code compile for me too. Thank you!

I'll give this a try tonight as well and have a closer look.
It's one of two missing pieces I need; in theory kfifo is the other one but I think that is used so little that I might simply change the code?

Any comment on this one?

Was there a PR for this somewhere? If so, please mention that.

While your description is verbose and expressive I still found it a bit hard to follow; if I get it correctly wakeupwaiting calls hostap_newstate in your case; that updates INIT->RUN, calls ieee80211_create_ibss() which in turn ends up in ieee80211_sta_join1() which then triggers the deferred callback for the AP vap where we only see RUN->RUN (and funnily enough calls back into hostap_newstate again which only hits the debug printf.

I trust you to get this right.

I understand the tiny race; I am pondering if it might be worth mentioning it in the comment?

Rmeove extra () ().

Ignoring all the other things going on now .. do you plan to commit this w/ or w/o the spares to stable/13 within the next 24 hours?

I can confirm that an amd64 releng/13.1 kernel with this does load the i915kms and drm and I get the drmn0 line as well after a short flicker on the screen; I have no X on external USB drive to further test it but the "silent error" seems gone.

In D34754#787676, @imp wrote:

In D34754#787677, @imp wrote:

I'm happy to put, btw, spares in other structures as well, but I'm not familiar enough with the code to know good candidates. I can also to the Static_assert for those as well... Got any suggestions?

Add x11 to subscribers so they know how things proceed.

Closing again in favour of @imp's D34754 .

Can this be two independent changes please?

In D33915#787591, @imp wrote:

...

In D33915#787592, @imp wrote:

I know my diff isn't great for stable/13, but for the release it likely suffices until we can fix the KBI in stable/13 and may be less risk for the release than a bigger fix.

So after MFCing this drm-kmod binary packages on FreeBSD stable/13 and 13.1-RC1 broke; as per MFC rules I appended the field to the end of the struct. https://cgit.freebsd.org/src/commit/?h=releng/13.1&id=c325d9edeff568d3d38891b2916bd5bd0e9bf8e3 However probe will not run if there is something there which is > 0 and we'll treat it as a probe error.

Okay, tested on my arm64 with 64G of main memory loading if_rtw88:
compat.linuxkpi.lkpi_pci_nseg1_fail: 2

Add the ability under compat.linuxkpi.debug to also dump the stack in case
of a single-segment mapping error to see the originating driver part
as suggested by @hselasky.

In D34715#786694, @hselasky wrote:

Why not print the stack backtrace when debug.linuxkpi.debug is set?