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.
This should allow to drop 'ieee80211_ff_[age/flush]' calls from drivers
(an additional call can be made from ieee80211_tx_complete()
for non-default ieee80211_ffagemax values to prevent stalls -
but it will require an additional counter for transmitted frames).
Tested with RTL8821AU, STA mode (A-MSDU part only).
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D9984
Simplify the logic for clipping the range returned by the pager to fit
within the map entry.
Use atop() rather than OFF_TO_IDX() on addresses.
Reviewed by: kib
MFC after: 1 week
For 24xx and above use 2 vectors (default and response queue).
For 26xx and above use 3 vectors (default, response and ATIO queues).
Due to global lock interrupt hardlers never run simultaneously now, but
at least this allows to save one regitster read per interrupt.
MFC after: 2 weeks
When re-calculating the last inclusive page index after the pager
call, -1 was erronously ommitted. If the pager extended the run
(unlikely), the result would be insertion of the valid page mapping
outside the current map entry range.
Found by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Since we support RQSTYPE_RPT_ID_ACQ, that functionality is only useful
in loop mode, which probably doesn't worth having this hack in 2017.
MFC after: 2 weeks
