For three years now CAM does not use SIM lock, but still enforces SIM to
use it. Remove this requirement, allowing SIMs to have any locking they
prefer, if they pass no mutex to cam_sim_alloc().
MFC after: 2 weeks
This is a painful change, but it is needed. On the one hand, we avoid
modifying them, and this slows down some ideas, on the other hand we still
eventually modify them and tools like netstat(1) never work on next version of
FreeBSD. We maintain a ton of spares in them, and we already got some ifdef
hell at the end of tcpcb.
Details:
- Hide struct inpcb, struct tcpcb under _KERNEL || _WANT_FOO.
- Make struct xinpcb, struct xtcpcb pure API structures, not including
kernel structures inpcb and tcpcb inside. Export into these structures
the fields from inpcb and tcpcb that are known to be used, and put there
a ton of spare space.
- Make kernel and userland utilities compilable after these changes.
- Bump __FreeBSD_version.
Reviewed by: rrs, gnn
Differential Revision: D10018
This test was failing if run twice because rtadvd takes too long to die.
The rtadvd process from the first run was still running when the
second run created its interfaces. The solution is to use SIGKILL during
the cleanup instead of SIGTERM so rtadvd will die faster.
While I'm here, randomize the addresses used for the test, which makes bugs
like this easier to spot, and fix the cleanup order to be the opposite of
the setup order
PR: 217871
MFC after: 18 days
X-MFC-With: 315458
Sponsored by: Spectra Logic Corp
- Check the return from a call to malloc() in skim_printcap(), and
return a NULL if that fails.
- Fix a small memory leak in main() that happens if skim_printcap()
returns an error, including the new error-return of NULL.
Submitted by: Tom Rix <trix@juniper.net>
Reviewed by: pfg, ngie
MFC after: 4 weeks
Sponsored by: Dell EMC Isilon, Juniper
Differential Revision: D9954, D9982
I meant for the line that conditionally added in /usr/bin/nc support to
be `+=', not `=`. This restores hardlinks for all programs in usr.bin
specified before nc(1), e.g., bunzip2 and tar.
Reported by: Andrzej Tobola <ato@iem.pw.edu.pl>
Submitted by: Scott Allendorf <scott-allendorf@uiowa.edu>
Pointyhat to: ngie
MFC after: 3 days
Sponsored by: Dell EMC Isilon
Since the uset can set dhcp.interface-mtu, we need to try to validate the
value. So we verify if the conversion to int is successful and we will not
allow to set value greater than max IPv4 packet size.
Also use snprintf for safety.
Reviewed by: allanjude, bapt
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D8492
Don't segfault in kvm_close(3) if provided a NULL pointer. Instead, return
-1 and set errno to EINVAL.
Document this new behavior explicitly.
MFC after: 1 week
Reviewed by: vangyzen
Sponsored by: Dell EMC Isilon
Differential Revision: D10065
In r315408, disk_cleanup was removed, which is called at
sys/boot/userboot/userboot/userboot_disk.c:113.
This causes bhyveload to fail.
PR: 217935
Reported by: Fabian Freyer
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10060
open_client_* returns -1 on failure; 0 on success. Ensure that the return value is
0 -- otherwise exit snmp_open(..).
MFC after: 1 week
Sponsored by: Dell EMC Isilon
This is being done to avoid potential double frees with the values.
Differential Revision: D9970
MFC after: 1 week
Reviewed by: imp
Sponsored by: Dell EMC Isilon
getaddrinfo fails
If the asprintf call fails, fall back to the old code (as a last ditch effort
to provide the end-user with helpful output).
Sponsored by: Dell EMC Isilon
vm_pindex_t's into a vm_ooffset_t.
The length given to shm_dotruncate() must never be negative. Assert this.
Tidy up a comment.
Reviewed by: kib
MFC after: 1 week
- Make the explanation more complete
- Correct a minor grammar nit with verb tense.
- Don't emit the message if `pe->pe_name` is NULL (it doesn't
have much value).
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Free `f` if an unknown priority or facility is parsed with the function.
MFC after: 1 week
Reported by: Coverity
CID: 1368068
Sponsored by: Dell EMC Isilon
This is no longer required as of r315616, as the test is no longer
built/installed.
This is being done to diff reduce with NetBSD.
Sponsored by: Dell EMC Isilon
The failing test requires the zh_TW.Big5 locale, which is no longer
installed as of r315568.
Add a note/pointer just in case someone considers re-adding it.
Reported by: Jenkins
Sponsored by: Dell EMC Isilon
`error` is the accumulated error from previous close(2) calls.
This bug has been present since the libcall's import from 4.4BSD
Lite (r1573).
MFC after: 1 week
Noticed by: vangyzen (D10022)
Relnotes: yes
Sponsored by: Dell EMC Isilon
As noted by vangyzen, with a similar issue in D10022, the pointer portion of
the .Fa macro call is unnecessary, so remove the '*'.
MFC after: 1 week
Sponsored by: Dell EMC Isilon
mmc(4). For the most part, this consists of support for:
- Switching the signal voltage (VCCQ) to 1.8 V or (if supported
by the host controller) to 1.2 V,
- setting the UHS mode as appropriate in the SDHCI_HOST_CONTROL2
register,
- setting the power class in the eMMC device according to the
core supply voltage (VCC),
- using different bits for enabling a bus width of 4 and 8 bits
in the the eMMC device at DDR or higher timings respectively,
- arbitrating timings faster than high speed if there actually
are additional devices on the same MMC bus.
Given that support for DDR52 is not denoted by SDHCI capability
registers, availability of that timing is indicated by a new
quirk SDHCI_QUIRK_MMC_DDR52 and only enabled for Intel SDHCI
controllers so far. Generally, what it takes for a sdhci(4)
front-end to enable support for DDR52 is to hook up the bridge
method mmcbr_switch_vccq (which especially for 1.2 V signaling
support is chip/board specific) and the sdhci_set_uhs_timing
sdhci(4) method.
As a side-effect, this change also fixes communication with
some eMMC devices at SDR high speed mode with 52 MHz due to
the signaling voltage and UHS bits in the SDHCI controller no
longer being left in an inappropriate state.
Compared to 52 MHz at SDR high speed which typically yields
~45 MB/s with the eMMC chips tested, throughput goes up to
~80 MB/s at DDR52.
Additionally, this change already adds infrastructure and quite
some code for modes up to HS400ES and SDR104 respectively (I did
not want to add to much stuff at a time, though). Essentially,
what is still missing in order to be able to activate support
for these latter is is support for and handling of (re-)tuning.
o In sdhci(4), add two tunables hw.sdhci.quirk_clear as well as
hw.sdhci.quirk_set, which (when hooked up in the front-end)
allow to set/clear sdhci(4) quirks for debugging and testing
purposes. However, especially for SDHCI controllers on the
PCI bus which have no specific support code so far and, thus,
are picked up as generic SDHCI controllers, hw.sdhci.quirk_set
allows for setting the necessary quirks (if required).
o In mmc(4), check and handle the return values of some more
function calls instead of assuming that everything went right.
In case failures actually are not problematic, indicate that
by casting the return value to void.
Reviewed by: jmcneill
The commented out return value for kvm_getprocs(3) was misleading -- the
uncommented line is correct.
No content change
MFC after: 1 week
Sponsored by: Dell EMC Isilon
This should reduce overhead for aggregates (since every second frame
clears the queue and reschedules the task there is no need to cancel
the callout here; let it just run once at the end - even if queue is
empty).
Reported by: adrian
calculated at runtime based on how long it takes to set up an event in
hardware. This fixes the intermittant 1-minute hang at boot on imx5
systems, and also the occasional oversleeping while running. It doesn't
affect imx6 systems, which use different hardware for eventtimers.
It turns out that it usually takes about 30 timer ticks to set up the timer
compare register, and the old hard-coded minimum period was 10 ticks. On
the rare occasions when a timeout event that short was set up, we'd miss
the event and have to wait about 64 seconds for counter rollover before
the compare interrupt would fire.
Instead of just hardcoding a new bigger value, the code now measures the
time it takes to do the register read/write sequence to set up the compare
register, scales it up by 1.5x to be safe, and calculates the minimum event
period from the result. In the real world, the minimum period works out to
about 750 nanoseconds on imx5 hardware.
It turns out to be surprisingly expensive to access the gpt hardware (on the
order of 150ns per read/write). To cut down on the overhead of setting up
each eventtimer event, eliminate read-modify-write sequences to manage the
compare interrupt enable, by keeping a shadow copy of the hardware register
and only writing to the hardware when the enable bits really change.
With the new expansion code (word splitting during instead of after other
expansion processing), tracing the result of command substitution is no
longer possible, so stop trying.
