That should work in my case, at least. Thanks!

I do find "$OBJTOP"/secure/lib/libcrypto/aria.o, so that seems "better" from my perspective. Yeah, @sjg is a good one to ask about these things. :-)

Removing the directories in question worked for me, for a source upgrade from main-n263767-764464af4968 -> main-n263782-59833b089e78 on one of the three machines I tried this morning, so that seems fine to me.

After applying the patch to my ports tree (at main-n615777-7e591c4f2380), my poudriere-devel package-builder was able to build www/chromium successfully; the resulting package installed on my laptop and appears to run as usual.

Now that this is committed, I see (empirically) that the identifier "guest_ncpus" (src/usr.sbin/bhyve/qemu_fwcfg.c:237) is undeclared.

Tested on FreeBSD 14.0-CURRENT #76 main-n254675-1ea833a5729: Tue Apr 12 03:47:07 PDT 2022 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1400056 1400056

This worked for me.

Tested again after Warner's last change; no issues:

I re-tested after imp@'s update of Thu, Mar 11, 09:24; no issues:

My "build machine" runs a plain GENERIC kernel, so when it's running head, the INVARIANTS option is enabled. Its normal daily update got to main-n245338-221622ec0c8e, but after updating sources to main-n245363-b3dac3913dc9, it panicked (after successful build/install/reboot) before entering multi-user mode. Likewise after updating to main-n245372-d1cbe7908986.

I tested this (at work); it works in our workload (and avoids a severe performance regression).

After having noted the problem (during a test for merging from r364434 to r366011), I tested again after applying the patch. [Gleb actually applied the patch and built the image; I ran the tests] Test cluster is 22 control/canary pairs of machines, each pair of which has slightly different hardware -- all amd64, though; the problem was evident with 18 of the canaries without the patch, and after applying the patch, no issues were seen.

My opinion? Implementor's "artistic license" call. :-)

I certainly have no objection to someone using the idea(s) and committing code based on what's here. That said, this has been sitting here since October 2018.

Overcome by Events

I tried the change, on a system:
FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #662 r351837M/351846: Thu Sep 5 04:17:23 PDT 2019 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1300045 1300045

Thanks. This is not urgent -- I've been kinda sitting on it for years. And please consider this a proof of concept to illustrate the nature of the problem and a possible solution: I am not hung up on any part of the implementation.

A real-world example: the "uname -a" strings from my home "build machine" as of this morning:
s1.0:FreeBSD freebeast.catwhisker.org 11.2-STABLE FreeBSD 11.2-STABLE #847 r340058M/340097: Sat Nov 3 04:02:51 PDT 2018 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC amd64

Works for me as-is in 13.0-CURRENT @r339912M & 12.0-BETA2 @r339910M. 11.2-STABLE @r339881M needed the original .Dd line in the man page patch tweaked a bit to match expectations, but the text of that change and the code changes work as-is.

I've updated the diff a bit in response to some suggestions -- thanks for those!

Given the changes, this morning, I:

I tested this, as my laptop had panicked after updating from r339583 to r339639. I first updated sources to r339681, then applied the patch (via 'svn patch'); did the normal update, rebooted, and the em0 NIC worked just fine -- certainly no panic.

Looks good to me, and the patch applied against head @r338438 cleanly.

Overall, quite good: thank you. Above are mostly nits. I note, though that when I tried applying the patch to src/sbin/ipfw/ipfw.8 @338406, I got one rejection:

OK; I tested on my laptop (while failed to boot using the Lua loader at r337834), and after applying the patch, issuing "make clean" in src/stand, and rebuilding/installing, the laptop booted OK. Prior to applying the patch, /boot/loader was 516096 bytes; the loader built after applying the patch is 421888 bytes.

I was remiss in failing to note that the change in question reduced the size of the loader from 516096 to 421888 bytes.

Tested on my "build machine" (BIOS & MBR); no observed difference in behavior (from before the patch), so "does no harm" as far as I can tell so far.

I'll vote "no objection." (The issue doesn't really affect the bulk of my use,)

The above change allowed a kernel to load on my laptop[[ https://wiki.freebsd.org/Laptops/Dell_Precision_M4800?highlight=(\bCategoryLaptop\b)| Dell Precision M4800 ]] after updating from r337232 -> r337285; without the change, the kernel was unloadable ("Can't load kernel") and I didn't even get a loader menu (e.g., to facilitate loading a different kernel).

I like the idea -- particularly including the year. As for "logging in UTC," I found an approach that does fairly well (though it is a bit of a configuration hack): Just run the machines in UTC, but augment /etc/rc.conf (or similar) with (e.g.):

I tested this earlier today: having built head/amd64 @r327616, first verified that output counters were rarely being updated, then I "cloned" that slice, used "svn patch" to apply the patch, rebuilt the kernel, and rebooted. (All of this worked without incident or drama.) Once rebooted, I used "scp" to copy a large file from the laptop to a machine on a different network here at home; I was pleased to note that the traffic counters on the laptop showed a very close correspondence with the counters on the router (where the NICs are em(4), and "just work").

FWIW, I've had occasion to use man a few times on serial consoles (among other environments). IIRC, the main reason I switched the PAGER for myself was because (at the time), when more reached the end of the data, it would exit; that made searching backwards from the end rather challenging.

I've had 'PAGER=less' since before 2009/09/24 22:42:36 (earliest revision of ~/.cshrc I have) -- quite possibly since before my first experience with FreeBSD per se (which would have been 1998), as I used BSDi and SunOS before that.

At work, I built a version of our environment based on head/amd64 @314568, then built another after applying this set of patches. I have been running this pair of images on several (matched pairs) of our "appliances" since about 2017-04-10 03:00:00 UTC -- almost 36 hrs. as of this writing. So far, there's been no apparent difference in behavior for our workload (that I have been able to detect).

I tried it (by unpacking the tarball referenced in the message to the ports list as security/openvpn-test, then running

portmaster -o security/openvpn-test openvpn-2.3.14

on my laptop running FreeBSD/amd64 stable/11@r310109.

I was going to just upload the typescripts for the "ifconfig -v wlan0 list chan," but I don't see how to "To add files, drag and drop them into the comment text area." -- it makes no sense.

Applied (via "svn patch") on top of:
FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #405 r298876M/298876:1100106: Sun May 1 05:15:48 PDT 2016 root@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64
successfully.