Hm, this is an interesting problem/question.

oh this is a good catch!

looks good plz land

compile tested

rw_init_flags() -> rw_init()

nope, still no dice

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

Just tried the latest diff on power9/pseries qemu, it panics differently now

ok i thought this was OK on power9 but it seems not:

ok, tried with 8g in the VM instead of 2g, same issue.

and from justin on irc

This boots fine in qemu-system-ppc64 pseries9 + power9, but in qemu-system-ppc64 pseries-8.0 + power8, it immediately panics on boot with

I think it's fine to land as-is. Yes, the vlog vs vprintf discussion should happen soon. :-)

oh crap i missed testing this; lemme test this on -HEAD today on the G5 and POWER8.

As mentioned on IRC, I think we should create _PATH_DEBUG_PREFIX or something similar to hide the /usr/lib/debug path.

• convert the superpage lock path to use the iterator lock
• and another function involved as well

delete old code

updated; i removed the recursive lock as now we shouldn't be recursing.

update

In D54355#1260823, @kris_tranception.com wrote:

I can see that int _flags2 was added to FILE ten years ago and only one bit has been defined leaving 31 unused bits, precisely what's needed to represent any non-negative file descriptor.
So I'm reworking this to not add a new field but rather continue using short _file for <32768 and the high 31 bits of _flags2 for descriptors >32767 && <0x7fffffff; the size of FILE will not need to change.

not needed now!

I did, I tried searching for 'pkg search git-arc' ;-P

looks good, land when you're ready!

@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.