WITNESS_ALL is defined. The lock name is based on the filename and
line number where the initialisation happens.
MFC after: 1 week
Sponsored by: Mellanox Technologies
This patch fixes my recent patch
"loader.efi: reduce the size of the staging area if necessary", which
causes EFI-boot failure on physical machines since Mar 2:
on the host there is a 1MB LoaderData memory range, which splits
the big Conventional Memory range into a small one (15MB) and a
big one: the small one is too small to hold the staging area.
We can actually use the LoaderData range safely, because when
amd64_tramp -> efi_copy_finish() starts to run, we're almost at
the very end of the efi loader code and we're going to "return"
to the kernel entry, so we're pretty sure we won't access any loader
data any more.
For people who are interested in the details: please see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c22
PS, some people also reported the regression happened to FreeBSD VM
running on Bhyve in EFI mode. This patch should resolve it too,
though I don't have such a setup to test.
Reviewed by: sephe
Approved by: sephe (mentor)
MFC after: 2 weeks
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9904
Unfortunately they will have different integer value due to Linux value being already assigned in FreeBSD.
The patch is similar to IP_RECVDSTADDR but also provides the destination port value to the application.
This allows/improves implementation of transparent proxies on UDP sockets due to having the whole information on forwarded packets.
Reviewed by: adrian, aw
Approved by: ae (mentor)
Sponsored by: rsync.net
Differential Revision: D9235
Bring back the i486 option in GENERIC by default.
The code related to i386 CPU variants configuration has received many
changes in the last years: most of the features are detected automatically,
so there are no performance penalties from keeping the 486 support enabled.
Re-instate the 486 support: while the general configuration could still be
cleaned a bit, there is no advantage in removing it.
Differential Revision: https://reviews.freebsd.org/D9879
o check the size of O_IP_SRC_LOOKUP opcode, it can not exceed the size of
ipfw_insn_u32;
o rename ipfw_lookup_table_extended() function into ipfw_lookup_table() and
remove old ipfw_lookup_table();
o use args->f_id.flow_id6 that is in host byte order to get DSCP value;
o add SCTP ports support to 'lookup src/dst-port' opcode;
o add IPv6 support to 'lookup src/dst-ip' opcode.
PR: 217292
Reviewed by: melifaro
MFC after: 2 weeks
Sponsored by: Yandex LLC
Differential Revision: https://reviews.freebsd.org/D9873
When we doing reference counting of named objects in the new rule,
for existing objects check that opcode references to correct object,
otherwise return EINVAL.
PR: 217391
MFC after: 1 week
Sponsored by: Yandex LLC
Store the result in a proper long and then compare to the proper pid_t
for overflow, so that no MD assumptions are made.
Reviewed by: jilles
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D9887
r313404 made libnetbsd require sha384.h from libmd. Libmd added it in
r292782. Update BOOTSTRAPPING to account for this.
Reported by: bde
Reviewed by: ngie
[SCEV] limit recursion depth of CompareSCEVComplexity
Summary:
CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled
loop) and runs almost infinite time.
Added cache of "equal" SCEV pairs to earlier cutoff of further
estimation. Recursion depth limit was also introduced as a parameter.
Reviewers: sanjoy
Subscribers: mzolotukhin, tstellarAMD, llvm-commits
Differential Revision: https://reviews.llvm.org/D26389
This commit is the cause of excessive compile times on skein_block.c
(and possibly other files) during kernel builds on amd64.
We never saw the problematic behavior described in this upstream commit,
so for now it is better to revert it. An upstream bug has been filed
here: https://bugs.llvm.org/show_bug.cgi?id=32142
Reported by: mjg
reallocarray(3) is a non portable extension from OpenBSD. Given that it is
already in FreeBSD, make easier future merges by adopting in some cases
where the code has some shared heritage with OpenBSD.
Obtained from: OpenBSD
already complete.
Since 416 is an error code, any Content-Range header in the response
would refer to the error message, not the requested document, so
relying on the value of size when we know we got a 416 is wrong.
Instead, just verify that offset == 0 and assume that we've reached
the end of the document (if offset > 0, we did not request a range,
and the server is screwing with us). Note that we cannot distinguish
between reaching the end and going past it, but that is a flaw in the
protocol, not in the code, so we just have to assume that the caller
knows what it's doing. A smart caller would request an offset
slightly before what it believes is the end and compare the result to
what is already in the file.
PR: 212065
Reported by: mandree
MFC after: 3 weeks
1. There a was a typo in one place where the processor family is
checked (16 vs 0x16). Now the checks are consolidated in a single
function.
2. Instead of an array of struct amd_et_state objects the code allocated
an array of pointers. That was no problem on amd64 where the sizes
are the same, but could be a problem on i386.
Reported by: tuexen and others
Tested by: tuexen (earlier version of the fix)
Pointyhat to: avg
MFC after: 5 days
X-MFC with: r314636
all the clocks that they provide.
Each clocks are exported under the node 'clock.<clkname>' and have the following
children nodes :
- frequency
- parent (The selected parent, if any)
- parents (The list of parents, if any)
- childrens (The list of childrens, if any)
- enable_cnt (The enabled counter)
This give us the possibility to examine clocks at runtime and make graph of
the clock flow.
Reviewed by: mmel
MFC after: 2 month
Differential Revision: https://reviews.freebsd.org/D9833
Promote Peter Grehan to a brother of day1 by
adding Peter Grehan (grehan) as my mentor.
Reviewed by: gjb
Approved by: grehan
Verified by: dot to make sure it produces output and no cycles occur
This interface has no in-tree consumers and has been more or less
non-functional for several releases.
Remove manpage note that the procfs special file 'mem' is grouped to
kmem. This hasn't been true since r81107.
Remove procfs' README file. It is an out of date duplication of the manpage
(quoth the README: "since the bsd kernel is single-processor...").
Reviewed by: vangyzen, bcr (manpage)
Approved by: des (procfs maintainer), vangyzen (mentor)
Differential Revision: https://reviews.freebsd.org/D9802
For 4965 just extract 'is_chan_5ghz' flag from the RXON structure
(like it was done in r281287); for others it was never used.
Tested with Intel 6205, STA mode.
Code like t=$(stat -f %m "$file") segfaulted if -T was active and a trap
was taken while the shell was waiting for the child process to finish.
What happened was that the dotrap() call in waitforjob() was hit. This
re-entered command execution (including expand.c) at a point not expected by
expbackq(), and global state (unallocated stack string and argbackq) was
corrupted.
To fix this, change expbackq() to prepare for command execution to be
re-entered.
Reported by: bdrewery
MFC after: 1 week
If stdout isn't a tty, use unlimited width output rather than truncating to
79 characters. This is helpful for shell scripts or e.g., 'ps | grep foo'.
This hardcoded width has some history: In The Beginning of History[0], the
width of ps was hardcoded as 80 bytes. In 1985, Bloom@ added detection
using TIOCGWINSZ on stdin.[1] In 1986, Kirk merged a change to check
stdout's window size instead. In 1990, the fallback checks to stderr and
stdin's TIOCGWINSZ were added by Marc@, with the commit message "new
version."[2]
OS X Darwin has a very similar modification to ps(1), which simply sets
UNLIMITED for all non-tty outputs.[3] I've chosen to respect COLUMNS
instead of behaving identically to Darwin here, but I don't feel strongly
about that. We could match OS X for parity if that is desired.
[0]: https://svnweb.freebsd.org/csrg/bin/ps/ps.c?annotate=1065
[1]: https://svnweb.freebsd.org/csrg/bin/ps/ps.c?r1=18105&r2=18106
[2]:
https://svnweb.freebsd.org/csrg/bin/ps/ps.c?r1=40675&r2=40674&pathrev=40675
[3]:
https://opensource.apple.com/source/adv_cmds/adv_cmds-168/ps/ps.c.auto.html
PR: 217159
Reported by: Deepak Nagaraj <n.deepak at gmail.com>
have been in the code all along, but were masked by having a fifo depth of
one byte at the hardware level, so everything kinda worked by accident.
The hardware interrupts when the TX fifo is half empty, so set
sc->sc_txfifosz to 8 bytes (half the hardware fifo size) to match. This
eliminates dropped characters on output.
Restructure the read loop to consume all the bytes in the fifo by using
the "rx fifo empty" bit of the flags register rather than the "rx ready"
bit of the interrupt status register. The rx-ready interrupt is cleared
when the number of bytes in the fifo fall below the interrupt trigger
level, leaving the fifo half full every time receive routine was called.
Now it loops until the fifo is completely empty every time (including
when the function is called due to a receive timeout as well as for
fifo-full).
Dan Krejsa reports a potential memory leak in an fts_build error case,
detected by Coverity. (It doesn't seem to show up in Coverity Scan, so I
don't have a CID to point to.)
I don't know whether it is actually possible to arrive in this case with a
non-empty 'head' list. The cost is low, though. One additional branch in a
terminal error case isn't the end of the world.
PR: 217125
Submitted by: Dan Krejsa <dan.krejsa at gmail.com>
Some of the changes I introduced to use .ALLSRC were correct in spirit,
but incorrect in reality -- in particular, ../Makefile.inc hadn't been
pulled in via bsd.init.mk (via bsd.lib.mk, bsd.prog.mk), so the value
of .ALLSRC (evaluated immediately) was empty. .include bsd.init.mk
explicitly so we can be certain that the values used as dependencies in
the targets are defined when the target recipe has been evaluated.
Reminder: thou shalt separate out separate functional changes before
committing them.
(YUGE) Pointyhat to: ngie
In collaboration with: bdrewery
MFC after: 1 month
Reported by: Jenkins, cy, ler, O. Hartmann, Michael Butler
Sponsored by: Dell EMC Isilon
RPi3 cpufreq is more like that on RPi2. Setting arm frequency
above min (say, "sysctl hw.cpufreq.arm_freq=600000001") turns on
turbo mode, and the firmware automatically raises voltage, sets
frequency to max 1200MHz, and throttle when overheat, etc.
Swap if/else parts and use SOC_BCM2835 def so RPi3 can share the
same cpufreq logic as RPi2, instead of falling to that for RPi.
Submitted by: Jia-Shiun Li <jiashiun@gmail.com>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D9640
80486 production was stopped by Intel on September 2007. Dropping the 486
configuration option from the GENERIC kernel improves performance
slightly.
Removing I486_CPU is consistent at this time: we don't support any
processor without a FPU and the PC-98 arch, which frequently involved i486
CPUs, is also gone so we don't test such platforms anymore.
Relnotes: yes
MFC after: 2 weeks
https://reviews.freebsd.org/D9879
Modern GCC and Clang simply ignore the qualifier, while the old base GCC
produces a warning (treated as an error in the kernel build).
Approved by: cem
MFC after: 5 days
This simplifies make logic/output
While here, remove bogus CFLAGS which look for headers in cddl/lib/libumem.
There aren't any source files there (just Makefiles)
MFC after: 1 month
Sponsored by: Dell EMC Isilon
