This has two goals:
- Exercize call to unp_dispose() via soshutdown() instead of sofree()
- Make sure that shutdown indeed dereferences the fd stored
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D35122
The code for the "shift" block in the COPY macro set the pointer for
the next copy block to the wrong value. In this case, the link-layer
header would be overwritten by the network-layer header. This case is
difficult or impossible to exercise in the current driver without
changing the value of the hw.genet.tx_hdr_min sysctl. Correct the
pointer. While here, remove a line in the macro that was marked
"unneeded", which was actually wrong.
PR: 263824
Submitted by: jiahali@blackberry.com
MFC after: 2 weeks
- Make descriptions a bit more human-friendly.
- Don't attempt to probe fan safe speeds, this model does not provide
one.
PR: 260781
MFC after: 2 weeks
One of the SMMU interrupt lines (priq) is optional and may be ommited in FDT.
Tested on ARM Morello Board, which has three SMMU units: first two have four
interrupt lines, last one has three interrupt lines.
Sponsored by: UKRI
There are many places where we copyin Linux timespec from the userspace
and then convert it to the kernel timespec. To avoid code duplication
add a tiny halper for doing this.
MFC after: 2 weeks
As native i386 time_t is still 32-bit, check that the user-provided 64-bit
tv_sec value fits to the kernel time_t, return EOVERFLOW if not.
MFC after: 2 weeks
Assuming the kernel would use random data, the 64-bit Linux kernel ignores
upper 32 bits of tv_nsec of struct timespec64 for 32-bit binaries.
MFC after: 2 weeks
There are many places where we convert natvie timespec and copyout it to
the userspace. To avoid code duplication add a tiny halper for doing this.
MFC after: 2 weeks
If 'options RSS' is set we bind the epair tasks to different CPUs. We
must take care to not keep the current thread bound to the last CPU when
we return to userspace.
MFC after: 1 week
Sponsored by: Orange Business Services
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
