ok so I had a chat with jessica, and after some more digging to try and understand what's going on here, I see both views:

I haven't evaluated what's going on with 32 bit powerpc, but 64 bit powerpc this seems OK so far. I've been going through the ppc64 elfv2 abi v1.5 (https://files.openpower.foundation/s/cfA2oFPXbbZwEBK) and it does look like all of the relocs we're doing aren't instruction ones.

In D54221#1240836, @ivy wrote:

after my last comment, i ran into an unexpected make(1) crash while running this patch. i need to do some more testing to see if this is actually the cause, but i suggest holding off on landing it for now.

ok, but on insistence from jrtc27 i added some debug logging here and it's never actually invoking syncicache in my tests.

cleanup

This works for me on freebsd-16 on power8, I'm doing test buildworld -j32 on it right now!

ok, I cleaned this up and have tested it in a chroot constantly doing buildkernel. It didn't trigger any make failures so far.

remove extra mttb()

don't duplicate the section, thanks ppl

Note: you can test this for ppc64 by using power8/power9 VMs:

ok, now that i have power8 hardware up and running, what should i be on the lookout for?
Just the same devinfo/dmesg resource assignment, devices found, etc?

I agree. There's a reason EINTR is something userland is supposed to handle and restart in a documented way, and it's "so the kernel doesn't have to bend over backwards to restart things."

works for me!

I'm in the process of documenting / getting powernv8 and powernv9 qemu guests up and running.
(And I now have a power8 booting freebsd powernv so I can test it on real hardware as well.)

Any other comments? I'd like to land this into -HEAD this week and see how it plays out!

In D48099#1252897, @emaste wrote:

What do we expect to do with the remaining patches in this stack?

Oh, there's no callers of ieee80211_ampdu_request() outside of net80211? I was worried that the existing AMPDU implementing drivers would hiccup with the return value changing!

yeah, without it the ampdu retry stuff eventually stops retrying until the counter loops around again for the comparison to work

thanks!

I had to undo the sys/conf/NOTES part because aq doesn't compile on ! amd64 right now. It's using calls to readl/writel.

landed!

hi! please resubmit this with the correct tab indents so I can apply it to the tree and push upstream. Thanks!

its' ok i'll land it

The manpage could do with a bit more work but we can work on that a bit after landing. Lemme get some more eyeballs on this.

nice catch!

In D54639#1248394, @imp wrote:

You could combine the two lines too by

OFFSET=$((0x$(hd...) ))

option #2, thanks warner! this is cleaner!

(no changes planned, please review!)

let's land this and then figure out how to expand the spin mutexes a bit to cover features a bit cleaner.
(And then see i they really NEED to be spin mutexes..)

yeah, looking at asmc again with spin mutex use i really don't want to clean that up whilst removing GIANT here.
it should be ok-ish for now.

I had a chat with seuros on discord about it. I think its fine as an intermediary step, but I do think it'll be worth revisiting the driver locking later and pushing more stuff into functionality locks rather than per device IO locks.

@emaste how's this look to you?

oops! good catch

landed, thanks!

approved! want me to land it?

it's a bit terse, but i think it's fine!

thanks for pushing forward documentation updates!