@jhb so the submitter is going to also need to add/bump symbol versions to a bunch of stdio routines? Is that what you're saying?

This looks fine to me, nice catch!

I think this is fine; let's see what justin thinks tomorrow morning!

oh that's a good catch!

Also /proc/iomem, which i think has what you're after in more specific detail:

here's petitboot:

ok, two normal boots and then the boot with this diff attached are at https://people.freebsd.org/~adrian/powerpc64/20260203-D54745-fail-1.txt .

so it didn't finish booting;

ok, its definitely unhappy, stay tuned!

rebase after jhibbits@ recent changes

In D54745#1258964, @tpearson_raptorengineering.com wrote:

When testing, does anyone else have access to a SATA controller that does DMA? I'm sporadically seeing the Blackbird's AHCI controller lock up but I don't know if this is a PE freeze, bad DMA, or something completely unrelated (flaky cabling?):

ahcich1: is ffffffff cs ffffffff ss ffffffff rs ffffffff tfd ffffffff serr ffffffff cmd ffffffff
(ada0:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 40 e8 35 8b 40 24 00 00 00 00 00
(ada0:ahcich1:0:0:0): CAM status: Command timeout
ahcich1: AHCI reset...
(ada0:ahcich1:0:0:0): Retrying command, 3 more tries remain
ahcich1: stopping AHCI engine failed
ahcich1: SATA connect timeout time=100000us status=ffffffff
ahcich1: AHCI reset: device not found
pass0 at ahcich1 bus 0 scbus1 target 0 lun 0
pass0: <Hitachi HDS722020ALA330 JKAOA3MA> s/n JK11A8B9H82U0F detached
ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
ada0: <Hitachi HDS722020ALA330 JKAOA3MA> s/n JK11A8B9H82U0F detached
g_vfs_done(): ada0p2 converting all errors to ENXIO
g_vfs_done():ada0p2[WRITE(offset=212411777024, length=32768)]error = 6 suppressing further ENXIO
panic: UFS: root fs would be forcibly unmounted

(I still haven't forgotten about this diff; I'm going to test it in VMs and on power8 hardware this week.)

i'm ok with accepting the ppc64 side of this; i've run it for days on p8/p9 doing test builds and i've not seen anything weird.

oops, will review tonight/tomorrow, sorry!

sigh, turns out we need to fix something in sdt_machdep.h first:

This is sort of WIP - there's some TODOs in here. I'd like some feedback on the locking changes and whether I missed something. Thanks!

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.