ok, this one boots fine in p8 pseries and p9 pseries, but p8 powernv it .. just hangs during boot and eventually ends up at OPAL.

In D55315#1266124, @tpearson_raptorengineering.com wrote:

Seeing the same problem with just D54745, D55313, and D55314. I suppose it's possible D54745 could shift things around enough to make the problem appear, but I'm not comfortable merging code into the DMA system when I already know we're violating platform constraints (without D54745 I know for a fact we're allocating bounce buffer in an illegal region and Bad Things via undefined behavior are likely -- just because we get away with it long enough to boot doesn't mean we're not going to get data corruption and lockups later on).

ok, does this happen without this domain change? can you just try D55312, D55313, D55314?

oh interesting. is this different from straight -head? If it is then i need to fix it. If it isn't then it's expected behaviour!

refactor

refactor

refactor

refactor

migrate this to /just/ do rwlock migration, not the iteration stuff.

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