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!

do 32 bit as well, thanks jhibbits

accepting; save the manpage include, please shuffle that :p

should be 1, not 2

just do slirp for now, bofh@ says the libfdt/meson internal use is intentional