I pushed the last changes before I'd noticed the better wording
suggestions in the review. Also include a note that not all lines will
have a timestampe. Some multi-line messages are generated with sbuf, and
when those are pushed, only the first line will have the
timestamp. Document this quirky behavior as well since fixing it likely
won't happen soon. CAM periph drivers generate all the lines in their
announce message together so they aren't intermingled with other things,
for example.
Suggested by: allanjude, emaste, rpokala
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D35139
Differential Revision: https://reviews.freebsd.org/D35141
jhb changed the newbus ABI and it's affecting some ports. Bump the
version to give them something to key off of for the removal of the
devclass arg from some macros. In theory the change should have been
ABI neutral, but there some build breakage with drm-kmod so better
to bump than not.
Sponsored by: Netflix
Today, kern.msgbuf_show_timestamp=1 will give 1 second granularity
timestamps on dmesg lines. When kern.msgbuf_show_timestamp=2, we'll
produce microsecond level graunlarity.
For example:
old (== 1):
[13] Dual Console: Video Primary, Serial Secondary
[14] lo0: link state changed to UP
[15] bxe0: NIC Link is Up, 10000 Mbps full duplex, Flow control: ON - receive & transmit
[15] bxe0: link state changed to UP
new (== 2):
[13.807015] Dual Console: Video Primary, Serial Secondary
[14.544150] lo0: link state changed to UP
[15.272044] bxe0: NIC Link is Up, 10000 Mbps full duplex, Flow control: ON - receive & transmit
[15.272052] bxe0: link state changed to UP
Sponsored by: Netflix
Previously we invoked the sysctl with a NULL buffer to query the size,
allocated a buffer, then invoked it again to fetch the data.
As we only handle the case where the sysctl provides data of the
expected size we can just allocate a correctly-sized buffer to begin
with.
Reported by: Thomas Hurst via Twitter
Reviewed by: kevans
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35140
The old fixed-point arithmetic used for calculating load averages had an
overflow at 1024. So on systems with extremely high load, the observed
load average would actually fall back to 0 and shoot up again, creating
a kind of sawtooth graph.
Fix this by using 64-bit math internally, while still reporting the load
average to userspace as a 32-bit number.
Sponsored by: Axcient
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D35134
