Adding the wider powerpc umbrella, so others can take a look as well.

the "extint-gpio1" check returned NULL

The type NULL checks are good. I think the whole of the changes for pmu_send() are a bit overkill. Could you test with just the one line I pointed out, and the rest reverted?

In D54639#1248394, @imp wrote:

You could combine the two lines too by

OFFSET=$((0x$(hd...) ))

You could combine the two lines too by

OFFSET=$((0x$(hd...) ))

I can make the case both ways... so either is fine for me.

option #2, thanks warner! this is cleaner!

Impressive

(no changes planned, please review!)

FYI, all other arches unconditionally STAILQ_INIT() the list in allocated maps. 32-bit arm initializes the list twice which is somewhat confusing.

Should this also be applied to stand/powerpc/boot1.chrp/bootinfo.txt?

Recently got this patch working on 13.1, quiets the fans down on my Late 2003 PowerBook5,2. In fact the fans are barely on as far as I can tell, I'll have to investigate temperatures.

This was superseded by https://reviews.freebsd.org/D36420

In D36234#835283, @alfredo wrote:

Make this change powerpc* only in order to unbreak pfsync module and
the test infrastructure.

I'm also seeing this issue when zfs tries to mount my partition.

Considering PowerPC has been broken for quite some time, this seems a good approach, while the real issue on LLD or the kernel linker is not resolved.

Make this change powerpc* only in order to unbreak pfsync module and
the test infrastructure.

In D36234#822496, @markj wrote:

This is rather strange. The description makes it sound like there is a bug somewhere in powerpc relocation handling, nothing specifically to do with cpuset code.

working with gsoc student on ppc64 Linuxulator we see the same relocation problem with copyin/copyout calls from loadable modules

In D36234#822496, @markj wrote:

This is rather strange. The description makes it sound like there is a bug somewhere in powerpc relocation handling, nothing specifically to do with cpuset code.
Until the problem is better understood, I don't think it's appropriate to commit something like this - how do you know that the bug won't require another workaround next week?

This is rather strange. The description makes it sound like there is a bug somewhere in powerpc relocation handling, nothing specifically to do with cpuset code.

I think this is fine as is.
There's no need to check for nfs in the middle of a string, unless there's some use case I'm unaware of...

In D33603#796461, @alfredo wrote:

I like the idea! However I burned an DVD for a PowerBook G4 and I only see the regular disc icon.
What's your device model? (based on other sources your patch looks correct. Maybe my firmware is too old for this feature)