This fixes duplicate mails (one from cron, one from periodic)
when a periodic run is not finished bfore the next one starts.
The man page states that the intended use case is cron, and
the error handling of the lockf invocation handles this case
explicitely, as such no error message for the "interactive"
use was considered.
When there's an open PR and/or a Differential Revision, people
evaluating the pull request will want to look at them. Suggest that the
submitter include this information to make it easier to process.
Sponsored by: Netflix
Create a slightly longer version of the inforamtion available in the
handbook in the file that Github displays for more information about
contributing.
Sponsored by: Netflix
Replace a cast '0' for a null pointers with NULL
Replace a 'goto loop' with a do-while loop in ufs and ext2fs.
Cast cp pointer to uintptr_t to test to see if it's aligned rather than long.
[ minor tweaks based on my & hps' review, reworded commit message ]
Reviewed by: imp, hps
Pull Request: https://github.com/freebsd/freebsd-src/pull/547
There exists hardware that has no ethernet address burned into
the EEPROM. Loading if_re on such a HW brings the device up
with '00:00:00:00:00:00' as the address, and that doesn't get
you too far in a real network.
PR: 262406
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/670
Signed-off-by: Evgeni Golov <evgeni@debian.org>
Differential Revision: https://reviews.freebsd.org/D34485
The comment above bintime2timespec() says:
When converting between timestamps on parallel timescales of differing
resolutions it is historical and scientific practice to round down.
However, the delta_nsec value is a time difference and not a timestamp. Also
the rounding errors accumulate in the frequency accumulator, see hardpps().
So, rounding to the closest integer is probably slightly better.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/604
Let A be the current calculation of the frequency accumulator (pps_fcount)
update in pps_event()
scale = (uint64_t)1 << 63;
scale /= captc->tc_frequency;
scale *= 2;
bt.sec = 0;
bt.frac = 0;
bintime_addx(&bt, scale * tcount);
bintime2timespec(&bt, &ts);
hardpps(tsp, ts.tv_nsec + 1000000000 * ts.tv_sec);
and hardpps(..., delta_nsec):
u_nsec = delta_nsec;
if (u_nsec > (NANOSECOND >> 1))
u_nsec -= NANOSECOND;
else if (u_nsec < -(NANOSECOND >> 1))
u_nsec += NANOSECOND;
pps_fcount += u_nsec;
This change introduces a new calculation which is slightly simpler and more
straight forward. Name it B.
Consider the following sample values with a tcount of 2000000100 and a
tc_frequency of 2000000000 (2GHz).
For A, the scale is 9223372036. Then scale * tcount is 18446744994337203600
which is larger than UINT64_MAX (= 18446744073709551615). The result is
920627651984 == 18446744994337203600 % UINT64_MAX. Since all operands are
unsigned the result is well defined through modulo arithmetic. The result of
bintime2timespec(&bt, &ts) is 49. This is equal to the correct result
1000000049 % NANOSECOND.
In hardpps(), both conditional statements are not executed and pps_fcount is
incremented by 49.
For the new calculation B, we have 1000000000 * tcount is 2000000100000000000
which is less than UINT64_MAX. This yields after the division with tc_frequency
the correct result of 1000000050 for delta_nsec.
In hardpps(), the first conditional statement is executed and pps_fcount is
incremented by 50.
This shows that both methods yield roughly the same results. However, method B
is easier to understand and requires fewer conditional statements.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/604
Use local variables for the captured timehand and timecounter in pps_event().
This fixes a potential issue in the nsec preparation for hardpps(). Here the
timecounter was accessed through the captured timehand after the generation was
checked.
Make a snapshot of the relevent timehand values early in pps_event(). Check
the timehand generation only once during the capture and event processing. Use
atomic_thread_fence_acq() similar to the other readers.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/604
- Remove write-only variables, or hide them in cases where their use is
conditional or commented out.
- Check for errors from cmd_apply() in nmreplay.
- Use ANSI C definitions.
Reviewed by: vmaffione
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38752
If NANO_LAYOUT is set, then use /usr/obj/nanobsd.${NANO_NAME}.${NANO_LAYOUT}
instead of the current /usr/obj/nanobsd.${NANO_NAME} to allow multiple layouts
to be built w/o errors due to the time-skew that creates.
PR: 269366
Suggested by: Eugene Grosbein
Sponsored by: Netflix
Rephrase double negated sentences to improve readability
OpenBSD has done the same in the past to their man 3 daemon
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/671
This option was added in commit 0a100a6f1e but was never completed.
In particular, there is no logic to map flowids to different listening
sockets, so it accomplishes basically the same thing as SO_REUSEPORT.
Meanwhile, we've since added SO_REUSEPORT_LB, which at least tries to
balance among listening sockets using a hash of the 4-tuple and some
optional NUMA policy.
The option was never documented or completed, and an exp-run revealed
nothing using it in the ports tree. Moreover, it complicates the
already very complicated in_pcbbind_setup(), and the checking in
in_pcbbind_check_bindmulti() is insufficient. So, let's remove it.
PR: 261398 (exp-run)
Reviewed by: glebius
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38574
In preparation for the removal of the IP(V6)_BINDMULTI option.
PR: 261398 (exp-run)
Reviewed by: glebius
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38574
This is a kernel-only file, so it's safe to include opt_kbd.h. However,
add #ifdef _KERNEL guards to emphasize that. And also move the include
of opt_kbd.h in atkbdcreg.h to inside the kernel guards. Nothing outside
the kernel in tree uses the rest of that file, but I'm less comfortable
moving the #ifdef _KERNEL to the top of that file.
Sponsored by: Netflix
Dumping large routng tables (>1M paths with multipath) require the socket
buffer which is larger than the currently defined limit.
Allow the limit to be set in runtime, similar to kern.ipc.maxsockbuf.
Reported by: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>
MFC after: 1 day
Summary:
This review ports mlx5 driver, kernel's OFED stack (userland is already enabled), KTLS and krping to powerpc64 and powerpc64le.
krping requires a small change since it uses assembly for amd64 / i386.
NOTE: On powerpc64le RDMA works fine in the userspace with libmlx5, but on powerpc64 it does not. The problem is that contrib/ofed/libmlx5/doorbell.h checks for SIZEOF_LONG but this macro exists on neither powerpc64* nor amd64. Thus, the file silently goes to the fallback function written for 32-bit architectures. It works fine on little-endian architectures, but causes a hard fail on big-endian. It's possible it may also cause some runtime issues on little-endian.
Thus, on powerpc64 I verified that RDMA works with krping.
Reviewers: #powerpc, hselasky
Subscribers: bdrewery, imp, emaste, jhibbits
Differential Revision: https://reviews.freebsd.org/D38786
When doing a fully incremental build (with WITHOUT_CLEAN enabled), from
a commit before llvm 15 was merged (3264f6b88f), to a commit after
that, a number of .inc files were not regenerated. This could lead to
unexpected compilation errors when these .inc files were included from
llvm-project sources, similar to:
In file included from /usr/src/contrib/llvm-project/clang/lib/CodeGen/CGBuiltin.cpp:8268:
/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/clang/Basic/arm_mve_builtin_cg.inc:279:18: error: no matching constructor for initialization of 'clang::CodeGen::Address'
Address Val2 = Address(Val1, CharUnits::fromQuantity(2));
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work around this by making the .inc files dependent on the tblgen binary
used for generating them. E.g., we can relatively safely assume that if
the binary gets updated, the .inc files must also be updated. (Although
this is not 100% optimal, the gain by complicating things even more is
probaby not worth the effort.)
MFC after: 3 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38770
According to the Linux sources the kernel exposes a proces virtual
memory size via proc filesystem into the three files - stat, status
and statm. This is the struct mm->total_vm value adjusted to the
corresponding units - bytes, kilobytes and pages.
The fix is based on a fernape@ analysis.
PR: 265937
Reported by: Ray Bellis
MFC after: 3 days
- skipping end of block that is not open: Oc
- no blank before trailing delimiter
- remove useless TN macros
- remove commented out reference for esis(4)
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D38783
Since the kernel options ROUTE_MPATH and FIB_ALGO are enabled
per default for a while, it's good to have some user facing
documetation about the general functionality of multipath
routing and fib lookup algorithms.
Reviewed by: pauamma, Jose Luis Duran <jlduran at gmail dot com>
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D38783
Summary:
This review ports mlx5 driver, kernel's OFED stack (userland is already enabled), KTLS and krping to powerpc64 and powerpc64le.
krping requires a small change since it uses assembly for amd64 / i386.
NOTE: On powerpc64le RDMA works fine in the userspace with libmlx5, but on powerpc64 it does not. The problem is that contrib/ofed/libmlx5/doorbell.h checks for SIZEOF_LONG but this macro exists on neither powerpc64* nor amd64. Thus, the file silently goes to the fallback function written for 32-bit architectures. It works fine on little-endian architectures, but causes a hard fail on big-endian. It's possible it may also cause some runtime issues on little-endian.
Thus, on powerpc64 I verified that RDMA works with krping.
Reviewers: #powerpc, hselasky
Subscribers: bdrewery, imp, emaste, jhibbits
Differential Revision: https://reviews.freebsd.org/D38786
Bruce added stripping of gcc2_compiled and other symbols when he made
the boot loader load the symbols for the kernel in 1995 (b5d89ca8ad)
before the FreeBSD 2.1 release. This was copied around a bit and
tweaked over the years, but these symbols aren't produced by clang, nor
gcc12. The were to support dbx for a.out stabs format. gcc removed them
with stabs support last year. gcc 2.95.4 in FreeBSD 4.x continued to
emit these symbols unconditionally (it was missing a test for aout vs
elf it would appaer). They disappeared entirely with gcc 3.2.4 in 5.x
for all non a.out builds, and entirely in FreeBSD 6.x which had gcc
3.2.6.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D38764
Previously strtol was used and the result was directly cast to an int
without checking for an overflow. Use strtonum instead since it is
safer and tells us what went wrong.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/643
If a CPU for some reason returns 0 as CPU frequency, we currently panic
on the resulting divide by zero when trying to initialize the CPU(s) via
APIC. When this happens, we'll fallback to measuring the frequency
instead.
PR: 269767
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/664
This is a variant of CK_*_FOREACH from FreeBSD queue.h which starts
iteration at the specified item. If the item pointer is NULL, iteration
starts from the beginning of the list.
Upstream commit 74366be35a6f4635f248a3c62d2d23245a4eb0f4.
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Most options in kernel config files use "options<space><tab>OPTION".
This allows the option to be commented out without shifting columns.
A few options had two tabs, and some had spaces. Make them consistent.
I missed this file on the last pass.
- Be consistent with RFC references, so add a space after 'RFC'
- Add a LIBRARY section
- Use standard integer types in the SYNOPSIS section
Obtained from: DragonflyBSD
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D27548
