this is good work! i would like to figure out how to describe the "why" this extra stuff is necessary though, so lemme noodle on that a bit first.

Ok, i'm now actively looking at this.

Lemme see which I can delete and which I need to keep and use.

It's in here just in case i need it when figuring out WOL. I'd much prefer we figure out WOL :P

nice catch!

In D55667#1273924, @olce wrote:

(Alternative: Don't compile this on 32-bit architectures at all, if if_iwx in reality does not support those.)

also - are D55492 and D55564 supposed to be tested together in a stack? which should be applied first?

First up - the alignment should be what the hardware supports, not what the ethernet type supports. Eg, if the virtio API supports 1 byte alignment and it's not hugely inefficient to do so then that's what you should create the DMA tag with.
There's a bunch of un-fun stuff around RX alignment of buffers versus the network stack requirements - notably the IP stack will do unaligned accesses and will trip an exception if you don't enable unaligned access or handle it in said exception handler.
This typically comes up when you have hardware with 4 byte alignment requirements but you need to start the mbuf at a 2 byte offset so a non-VLAN ethernet header will result in the IP header starting at a 4 byte alignment.
(Honestly though it's 2026 and we should just finally fix the IP/TCP stack..) So just keep that in mind if you're trialing 1 byte hardware alignment and you see weird shenanigans with RX path mbufs.

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