After building the src.conf man page, update the WITHOUT_SERVICESDB entry to
generate something that looks more sensible.

Sort by alpha as per @emaste.

Adding my "ok" pending bnxt review by @shurd

In D15211#330309, @sbruno wrote:

root@lab:/home/sbruno/bsd/fbsd_head # env | grep SRCCONF
SRCCONF=/home/sbruno/bsd/src.conf.efitest
root@lab:/home/sbruno/bsd/fbsd_head # cat ${SRCCONF}
WTTHOUT_EFI="YES"
root@lab:/home/sbruno/bsd/fbsd_head # make delete-old DESTDIR=/tftpboot/netboot
>>> Removing old files (only deletes safe to delete libs)
>>> Old files removed
>>> Removing old directories
>>> Old directories removed
To remove old libraries run 'make delete-old-libs'.
root@lab:/home/sbruno/bsd/fbsd_head # make delete-old MK_EFI=no DESTDIR=/tftpboot/netboot                                                                                                                                                    
>>> Removing old files (only deletes safe to delete libs)
remove /tftpboot/netboot/usr/sbin/efibootmgr?

In D15211#330335, @emaste wrote:

Is setting it in the environment expected to work? What about make SRCCONF=/foo/bar/baz ...?

Don't nuke *all* the efi tools if OPENSSL isn't installed. (imp)

hrm ... WITH_EFI="NO" has zero effect as well. So, I'm stumped.

Pending no further review comments, this will go in the tree on Monday, May 31. That way folks can yell at me when we all get together in Ottawa.

WITHOUT_EFI="YES" seems to do nothing.

Exclude MK_EFI things if OPENSSL is unset with some better
syntax.

Add missing LDIRS for uefisign

In D15211#330017, @emaste wrote:

In D15211#329988, @sbruno wrote:

In D15211#329987, @imp wrote:

No, we've always just used efiFOO for the efi programs.

Oh, so you're saying that "uefisign" should be a symlink to efisign? I don't know the background here.

Yeah, we had efi in the loader from before UEFI existed, and now also have efibootmgr, efidp and efivar userland binaries.

In D15211#329987, @imp wrote:

No, we've always just used efiFOO for the efi programs.

In D15211#320576, @imp wrote:

while you're here, maybe it's time to do the uefisign -> efisign with a legacy link.

Regenerate after some of the pkg base stuff hit the tree.

@johalun0_gmail.com Can this be regenerated against head when you get to it in the morning?

Remove MACRO for pyo files

Resort pkg-plist via makeplist.

My spider sense is tingling as well.

In D15523#328831, @cem wrote:

cpucontrol print on multiple input files could be a lot more clear :(. I disambiguated it by copying fam17h to its own directory:

$ mkdir tmp
$ cp -a work/stage/usr/local/share/cpucontrol/microcode_amd_fam17h.bin tmp
$ sudo cpucontrol -vvv -n -d ./tmp -u /dev/cpuctl0
amd10h_probe: family: 0x17
cpucontrol: skipping ./tmp/.: is a directory
cpucontrol: skipping ./tmp/..: is a directory
amd10h_update: signature: 0x800f11
cpucontrol: found cpu family 0xf model 0x1 stepping 0x1 extfamily 0x8 extmodel 0.
cpucontrol: microcode revision 0x8001129
amd10h_update: installed_cpu: 0x600f20
amd10h_update: installed_cpu: 0x610f01
amd10h_update: installed_cpu: 0x700f01
amd10h_update: installed_cpu: 0x800f12
amd10h_update: installed_cpu: 0x800f11
cpucontrol: equiv_id: 8011
$ echo $?
0

Nothing in /var/log/messages. Patch level is 0x8001129 per x86info.

This is on TR (fam 17h). Does that help? :-)

Hrm. I guess this *is* working, at least for the EPYC I have at work.

In D15523#328555, @markj wrote:

In D15523#327973, @sbruno wrote:

Trying out some debugging here. Can someone apply this patch
https://people.freebsd.org/~sbruno/cpucontrol.diff.txt

And send me the results of something like the following?

I get the same output, i.e., "CPU is not found in the equivalence table" for all files.

Update to catch linux-firmware commit 7518922bd5b98b137af7aaf3c836f5a498e91609

This had no effect on my AMD FX-8150, which is to be expected.

Was this the patch that we discussed on our call? Does this fix your TX checksum problems on IXL?

Adapt tag settings to provide a pkg version that is compatible
with old versioning and possible new versioning.

Pending trivial cleanups pointed out by @cem , approved.

In D11003#327485, @jtl wrote:

In D11003#327482, @sbruno wrote:

Is everyone on this review fine with me committing this? With the inheritance code removed, I believe there are no further objections or questions.

Have you addressed all of @rwatson's comments?

I've been meaning to review this, but have been delayed. I would appreciate a few extra days to look it over.

Trying out some debugging here. Can someone apply this patch
https://people.freebsd.org/~sbruno/cpucontrol.diff.txt

In D15523#327969, @emaste wrote:

On my AMD Ryzen Threadripper 1950X I see Microcode patch level: 0x8001127 before and after trying the microcode in this review (i.e., the new microcode_amd_fam17h.bin either does not contain microcode for Threadripper, or is not getting applied).

In D15523#327855, @jmd wrote:

On a AMD Threadripper 1900X I see "microcode updating..." and output of the CPU information. On a Carrizo APU, I see "microcode updating..." and "done", nothing else. How to check it DTRT?

On my FX-8150, previous update was:

I don't believe that I have access to a Broadwell host at the moment. However, this works fine for my machines.

Is everyone on this review fine with me committing this? With the inheritance code removed, I believe there are no further objections or questions.

In D15387#326994, @eadler wrote:

In D15387#326992, @sbruno wrote:

Do you need to update ObsoleteFiles in order to remove the old version?

This is just moving the source files. It installs to the same place.

Do you need to update ObsoleteFiles in order to remove the old version?

Synchronize intel-ucode-split to svn r333742

Use the proper syntax for USE_QT5= for the global QT5 requires.

I guess this is the proper way to do OPTIONS_SUB here. I dunno.

For reasons that I don't understand, poudriere testport seems to
invoke Makefile commands differently than poudriere bulk commands.

Synch ucode-split.c to svn r333661