I will add the following references to the commits:

While this review was in progress, 20190511 was released. Reset to that version.

Use GH_TAGNAME a bit more thoughout the build as suggested by swills.

Apparently arc doesn't use relative path by default. Delete unrelated tree changes.

Implement @mat suggestions for USE_GH

Yeah, just changing VREF_ENABLE_MASK was insufficient. I think I'll just commit this so people can use it for their newer desktops/laptops.

This seems like a good accounting change. Thanks.

Thanks for digging into this.

This looks good from the user side as the machine is humming along quite nicely. Thank you for digging into this!

Patched the build tree in the freebsd.org cluster and installed -current + this review on the pkg build server. You can track builds here when it starts spinning up in about an hour.

bump to see if phabricator shovels some emails.

trivial bump to generate email.

@shurd any objections from the peanut gallery?

Ports revision r489228 based on different patches has been committed.

r481915 | sbruno | 2018-10-12 11:51:37 -0600 (Fri, 12 Oct 2018) | 11 lines

In D18470#396630, @jeffrey.e.pieper_intel.com wrote:

In D18470#396629, @sbruno wrote:

In D18470#396626, @jeffrey.e.pieper_intel.com wrote:

We are seeing tx hangs with UDP using multiple clients when offloads are disabled. Cannot reproduce on 12.0-RELEASE. Reproducible on X520 and X550.

Huh? Does this review break things for you? Or are you bringing up a new problem?

Just reporting issues/regressions we found while testing this :)

In D18470#396626, @jeffrey.e.pieper_intel.com wrote:

We are seeing tx hangs with UDP using multiple clients when offloads are disabled. Cannot reproduce on 12.0-RELEASE. Reproducible on X520 and X550.

Doesn't this patch need to be conditional somehow (FreeBSD versions < 12 don't need this).

I guess this will wait for @jeffrey.e.pieper_intel.com to test or approve? This looks correct to my eye.

Agreed. Feel free to commit this at your leisure.

This panic is fairly reliable on our Power8 box. Is it related to this change or is it unrelated? I'm not convinced this panic should keep this review blocked as it resolves other things.

panic: Memory modified after free 0xc0000000850584a0(32) val=0 @ 0xc0000000850584a0

In D17806#393519, @leonardo.bianconi_eldorado.org.br wrote:

The reason of segmentation fault when treating the 0x1500 exception
was because it was being treated as a non-hypervisor trap, which
consider the registers srr0/srr1. As this trap is an hypervisor one,
the values were being placed in hsrr0/hsrr1.
Just changed the enter point for hypertrap, which saves the value of
hsrr0 and hsrr1 in srr0 and srr1.

In D10776#390549, @emaste wrote:

Is it acceptable if some binaries fail?

This has become a real issue - @sbruno found wc did not work on ERL, fixed in rS341140. This is somewhat independent of whether we have the #ifdefs or not though.

Oof. I got a different panic, that may or may not be useful.

Meaningless update to test that phab is still working

Running this on the Tyan Power8 hosts now. I'll report back in a day or two after we get some poudriere runs under our belt.

Is there any intention to rebase this to -current?

Nuke extra pkgname suffix

In D17772#379922, @mav wrote:

Have you tried to investigate whether keeping only VREF_ENABLE_MASK would be enough? It could have some more sense in general, since the driver has no way to know what VREF is needed in specific case. Same time other bits there are pretty logical.

Address man page review comments. Word wrap at 80 columns.

Address man page style review for new lines and correct case of BIOS use.

Add a man page update like a good dev.

This is probably completely wrong on multiple levels, but this certainly does allow me to use my headphones again on my Skylake Intel HDA box.

This definitely fixes the build and runtime of clementine-player (qt4).

In D17618#376145, @yuripv wrote:

Sean, could you please give this a try on ref12-ppc64?

This is running live on the host archon.nyi.freebsd.org that hosts ref12-ppc64.freebsd.org. We can do buildworlds and network things now. This is awesome.

In D17603#376077, @sbruno wrote:

In D17603#376024, @yuripv wrote:

issue fixed (wchar_t, that is (unsigned) int, is *4* bytes).

Now the amd64 cross-built locale data matches the one built natively on powerpc64.

Updating ref12-ppc64 for verification.

In D17603#376024, @yuripv wrote:

issue fixed (wchar_t, that is (unsigned) int, is *4* bytes).

Now the amd64 cross-built locale data matches the one built natively on powerpc64.

In D17603#375981, @yuripv wrote:

In D17603#375980, @sbruno wrote:

In D17603#375978, @yuripv wrote:

In D17603#375975, @sbruno wrote:

I'll apply this to the fbsd cluster build.

The build host is amd64 and builds multiple targets, aarch64, i386, powerpc64 and amd64. What information would you like from the builds?

I'd really like to compare results from native EB (e.g. powerpc64) build for /usr/share/locale with what amd64 cross-build produces.

Ok. I'll update ref12-ppc64 to this review (product of cross build) and then you can natively do a buildworld there to see what it looks like?

Thank you!

In D17603#375978, @yuripv wrote:

In D17603#375975, @sbruno wrote:

I'll apply this to the fbsd cluster build.

The build host is amd64 and builds multiple targets, aarch64, i386, powerpc64 and amd64. What information would you like from the builds?

I'd really like to compare results from native EB (e.g. powerpc64) build for /usr/share/locale with what amd64 cross-build produces.

I'll apply this to the fbsd cluster build.