- User Since
- May 1 2016, 5:02 PM (334 w, 6 d)
Thu, Sep 8
Apr 12 2022
Tested on FreeBSD 14.0-CURRENT #76 main-n254675-1ea833a5729: Tue Apr 12 03:47:07 PDT 2022 email@example.com:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1400056 1400056
Aug 1 2021
This worked for me.
Mar 12 2021
Tested again after Warner's last change; no issues:
Mar 11 2021
I re-tested after imp@'s update of Thu, Mar 11, 09:24; no issues:
Mar 10 2021
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.
Jan 7 2021
I tested this (at work); it works in our workload (and avoids a severe performance regression).
Oct 1 2020
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.
Jul 3 2020
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.
Jul 2 2020
Overcome by Events
Sep 5 2019
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 firstname.lastname@example.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1300045 1300045
Nov 9 2018
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.
Nov 4 2018
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 email@example.com:/common/S1/obj/usr/src/sys/GENERIC amd64
Oct 31 2018
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.
Oct 28 2018
I've updated the diff a bit in response to some suggestions -- thanks for those!
Oct 25 2018
Given the changes, this morning, I:
Oct 24 2018
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.
Oct 22 2018
Sep 4 2018
Looks good to me, and the patch applied against head @r338438 cleanly.
Aug 31 2018
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:
Aug 15 2018
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.
Aug 14 2018
I'll vote "no objection." (The issue doesn't really affect the bulk of my use,)
Aug 4 2018
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).
Apr 1 2018
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.):
Jan 6 2018
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").
Dec 12 2017
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.
Oct 24 2017
Apr 11 2017
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).
Dec 16 2016
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.
Aug 30 2016
Aug 29 2016
May 1 2016
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 firstname.lastname@example.org:/common/S4/obj/usr/src/sys/CANARY amd64