Define CC_NEWRENO in all the appropriate DEFAULTS and std.* config
files. It's the default congestion control algorithm. Add code to cc.c
so that CC_DEFAULT is "newreno" if it's not overriden in the config
file.
Sponsored by: Netflix
Fixes: b8d60729de ("tcp: Congestion control cleanup.")
Revired by: manu, hselasky, jhb, glebius, tuexen
Differential Revision: https://reviews.freebsd.org/D32964
NOTE: HEADS UP read the note below if your kernel config is not including GENERIC!!
This patch does a bit of cleanup on TCP congestion control modules. There were some rather
interesting surprises that one could get i.e. where you use a socket option to change
from one CC (say cc_cubic) to another CC (say cc_vegas) and you could in theory get
a memory failure and end up on cc_newreno. This is not what one would expect. The
new code fixes this by requiring a cc_data_sz() function so we can malloc with M_WAITOK
and pass in to the init function preallocated memory. The CC init is expected in this
case *not* to fail but if it does and a module does break the
"no fail with memory given" contract we do fall back to the CC that was in place at the time.
This also fixes up a set of common newreno utilities that can be shared amongst other
CC modules instead of the other CC modules reaching into newreno and executing
what they think is a "common and understood" function. Lets put these functions in
cc.c and that way we have a common place that is easily findable by future developers or
bug fixers. This also allows newreno to evolve and grow support for its features i.e. ABE
and HYSTART++ without having to dance through hoops for other CC modules, instead
both newreno and the other modules just call into the common functions if they desire
that behavior or roll there own if that makes more sense.
Note: This commit changes the kernel configuration!! If you are not using GENERIC in
some form you must add a CC module option (one of CC_NEWRENO, CC_VEGAS, CC_CUBIC,
CC_CDG, CC_CHD, CC_DCTCP, CC_HTCP, CC_HD). You can have more than one defined
as well if you desire. Note that if you create a kernel configuration that does not
define a congestion control module and includes INET or INET6 the kernel compile will
break. Also you need to define a default, generic adds 'options CC_DEFAULT=\"newreno\"
but you can specify any string that represents the name of the CC module (same names
that show up in the CC module list under net.inet.tcp.cc). If you fail to add the
options CC_DEFAULT in your kernel configuration the kernel build will also break.
Reviewed by: Michael Tuexen
Sponsored by: Netflix Inc.
RELNOTES:YES
Differential Revision: https://reviews.freebsd.org/D32693
This was never made to work, and given that 32-bit ARM support
is quickly becoming irrelevant, there is no point in keeping it
in the tree.
Sponsored By: EPSRC
Reviewed By: emaste
Differential Revision: https://reviews.freebsd.org/D32918
sched_throw() can no longer take a NULL thread, APs enter through
sched_ap_entry() instead. This completely removes branching in the
common case and cleans up both paths. No functional change intended.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D32829
* add the extres stuff into the build, I'm going to end up leveraging
all of it
* include the qcom-gcc-ipq4018 driver which currently implements the hwreset
side of the API.
Reviewed by: andrew, manu, imp
Differential Revision: https://reviews.freebsd.org/D32723
This implements the "reset controller" side of the clock/reset controller.
It's a simple array of registers and bits to set.
The register table itself comes from Linux; the rest of the code is a
reimplementation.
It doesn't yet implement or expose the clock side - I have a lot of
reverse engineering to do before that!
Reviewed by: andrew, manu, imp
Differential Revision: https://reviews.freebsd.org/D32723
Obtained from: Linux (registers)
This code implements the "kpssv2" flavour of CPU regulator/clock gating
in Linux. It's used by at least the ipq4018/4019 to power on and off
CPU cores.
This is based on the Linux implementation - the register definitions
and values are from Linux and I've reverse engineered the sequencing
requirements.
The MP bring-up is:
* set cold boot address via an SCM call - this is the address used
by the bootloader/TZ firmware to jump to when the CPUs boot
* power down the LDO feeding the CPU core and wait for it to settle
* program in the right set of LDO and power tree configuration for
the CPU regulator to power up the core. Unfortunately these are
magic numbers that I've not found documented anywhere.
* (I think) power up the shared L2 cache connect if it isn't.
* Clamp the power into the core down; put the core into reset
* Unclamp the power rail; release reset; and then set the core to boot.
The MP core will then boot the bootloader/TZ firmware and then
will wait until an incoming interrupt kicks it to start @ mpentry.
Tested:
* IPQ4019, 4 CPUs
Release APs
CPU(3) applied BP hardening: not necessary
CPU(1) applied BP hardening: not necessary
CPU(2) applied BP hardening: not necessary
Reviewed by: andrew, manu, imp
Differential Revision: https://reviews.freebsd.org/D32723
This is a very simple implementation of Qualcomm's SCM API.
It is just the structure/field definitions and the atomic SCM
call which doesn't use the structs yet - it uses the field
definitions inside registers.
I've tested that setting the cold boot address via the atomic
API is fine - Linux does the same thing. But not all SCM calls
can be done via the legacy API.
This is a reimplementation based on the Linux qualcomm SCM legacy
code and definitions.
Tested:
* Qualcomm IPQ4018 AP, as part of other changes for doing SMP bring-up
Reviewed by: andrew, manu, imp
Differential Revision: https://reviews.freebsd.org/D32723
Summary:
This is enough to allow this ASUS router to reboot successfully.
I tried the watchdog path and although it fires, it isn't rebooting!
It's just hanging, likely somewhere in TZ.
This is the MVP required to initialise and consume random data from
the QCA PRNG hardware found on the IPQ401x.
Test Plan: * ASUS RT-AC58U router, IPQ4019
Subscribers: imp, andrew
Differential Revision: https://reviews.freebsd.org/D32723
This is enough to allow this ASUS router to reboot successfully.
I tried the watchdog path and although it fires, it isn't rebooting!
It's just hanging, likely somewhere in TZ.
Tested:
* ASUS RT-AC58U router, IPQ4019
Reviewed by: andrew, manu, imp
Differential Revision: https://reviews.freebsd.org/D32723
schedinit_ap() sets up an AP for a later call to sched_throw(NULL).
Currently, ULE sets up some pcpu bits and fixes the idlethread lock with
a call to sched_throw(NULL); this results in a window where curthread is
setup in platforms' init_secondary(), but it has the wrong td_lock.
Typical platform AP startup procedure looks something like:
- Setup curthread
- ... other stuff, including cpu_initclocks_ap()
- Signal smp_started
- sched_throw(NULL) to enter the scheduler
cpu_initclocks_ap() may have callouts to process (e.g., nvme) and
attempt to sched_add() for this AP, but this attempt fails because
of the noted violated assumption leading to locking heartburn in
sched_setpreempt().
Interrupts are still disabled until cpu_throw() so we're not really at
risk of being preempted -- just let the scheduler in on it a little
earlier as part of setting up curthread.
Reviewed by: alfredo, kib, markj
Triage help from: andrew, markj
Smoke-tested by: alfredo (ppc), kevans (arm64, x86), mhorne (arm)
Differential Revision: https://reviews.freebsd.org/D32797
This makes hwpmc(4) sampling work on ACPI-based AArch64 systems.
Tested on ARM Neoverse N1.
Submitted by: Greg V <greg@unrelenting.technology>
Reviewed by: jrtc27, mhorne
Differential Revision: https://reviews.freebsd.org/D24423
Correctly recognize NEON/SIMD and VFP instructions in THUMB2 mode and pass
these to the appropriate handler. Note that it is not necessary to filter
all undefined instruction variant or register combinations, this is a job
for given handler.
Reported by: Robert Clausecker <fuz@fuz.su>
PR: 259187
MFC after: 2 weks
Remove page zeroing code from consumers and stop specifying
VM_ALLOC_NOOBJ. In a few places, also convert an allocation loop to
simply use VM_ALLOC_WAITOK.
Similarly, convert vm_page_alloc_domain() callers.
Note that callers are now responsible for assigning the pindex.
Reviewed by: alc, hselasky, kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31986
Summary:
This adds required IPQ4018/IPQ4019 SoC support to boot.
It also includes support for disabling the ARMv7 hardware
breakpoint / debug stuff at compile time as this is
required for the IPQ SoCs, and printing out the undefined
instruction itself.
Test Plan: * compiled/booted on an IPQ4019 SoC AP
Reviewers: #core_team!
Subscribers: imp, andrew
Differential Revision: https://reviews.freebsd.org/D32538
This is for the Qualcomm Atheros quad-core ARMv7 SoC with built-in
2x2 2GHz and 5GHz ath10k devices.
It's enough (with an upcoming set of config files) to netboot
on an ASUS router I have here and get to a single core mountroot
prompt.
The upcoming QCA ipq401x support detects the CP14 debug features,
but any attempt to use it causes an undefined instruction error.
It apparently needs a specific TZ image loaded by the early bootloader
(SBL) in order to enable these kinds of features.
So add a new kernel option that explicitly disables this in the
arm code - the debugger works fine without it.
Remove the option from NOTES/LINT, and add to NOTES for powerpc and
riscv.
PR: 259036
Requested by: John Hay <john@sanren.ac.za>
Discussed with: ian, imp
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
These platforms don't manage resources for DMA request lines or I/O
ports, this is specific to x86. Remove the references from the comments.
Reviewed by: imp, jhb
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32358
The previous update to handle the gicv2m as a child of the gicv3 driver
assumed there was only a single gicv2m child. On some hardware there
are multiple children. Support this by removing the mbi ivars and
adding a new interface to handle MSI allocation in a given range.
Tested by: mw, trasz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32224
The implementation of the progress bar is simple, but duplicated for
most minidump implementations. Extract the common bits to kern_dump.c.
Ensure that the bar is reset with each subsequent dump; this was only
done on some platforms previously.
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D31885
The function is identical in each minidump implementation, so move it to
vm_phys.c. The only slight exception is powerpc where the function was
public, for use in moea64_scan_pmap().
Reviewed by: kib, markj, imp (earlier version)
MFC after: 2 weeks
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D31884
The mutex was changed to a spin lock when the MSI/MSI-X handling was
moved from the gicv2m to the gic driver. Update the calls to lock
and unlock the mutex to the spin variant.
Submitted by: jrtc27 ("Change all the mtx_(un)lock(&sc->mutex) to be the _spin versions.")
Reported by: mw, antranigv@freebsd.am
Sponsored by: The FreeBSD Foundation
In cpu_set_upcall(), if the thread startup routine is a thumb routine, make
sure to set PSR_T, so that the CPU will run in thumb mode.
MFC After: 1 week
According to https://github.com/NuxiNL/cloudlibc:
CloudABI is no longer being maintained. It was an awesome experiment,
but it never got enough traction to be sustainable.
There is no reason to keep it in FreeBSD.
Approved by: ed (private mail)
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D31923
When handling a data irq, the sdhci driver calls the
sdhci_platform_will_handle() method, to determine if it should allow the
platform driver to handle the transfer or fall back to programmed I/O.
While dumping, the data irq path may be invoked directly (not from an
interrupt context), which the bcm2835_sdhci DMA code is not prepared to
handle. Return early in this case, to force the fallback to PIO.
Otherwise, the KASSERT that follows will be triggered, and the dump will
fail. On non-INVARIANTS kernels, the system will hang, waiting for a DMA
interrupt that will never arrive.
Reviewed by: kevans
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31893
Add generic mmc_helper which uses newly introduced device_*_property
api. Thanks to this change the sd/mmc drivers will be capable
of parsing both DT and ACPI description.
Ensure backward compatibility for all mmc_fdt_helper users.
Reviewed by: manu, mw
Sponsored by: Semihalf
Differential revision: https://reviews.freebsd.org/D31598
When setting a message based interrupt range we set the base and count.
In an earlier the count was implemented as an end value, however the
asserts used to check this value was correct were incorrectly left in.
Reported by: emaste
Sponsored by: The FreeBSD Foundation
This is in preperation for adding support for the GICv2m driver as a
child of the GICv3 driver.
PR: 258136
Reported by: trasz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31767
This reverts commit b684d812fc.
It causes an issue on a pfsense routing workload where memory
fragmentation prevents the necessary consecutive pages from being
readily available.
Reported by: pfsense (mjg, scottl)
Approved by: ian
MFC after: 1 day
Differential Revision: https://reviews.freebsd.org/D31244
Move the common kernel function signatures from machine/reg.h to a new
sys/reg.h. This is in preperation for adding PT_GETREGSET to ptrace(2).
Reviewed by: imp, markj
Sponsored by: DARPA, AFRL (original work)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19830
Stat collection using counter(9) is quite expensive on this platform and
these counters are normally not needed.
In particular we see about 1.5% bump in packet rate using Cortex-A9
Reviewed by: ian
Sponsored by: Rubicon Communications, LLC ("Netgate")
Different Revision: https://reviews.freebsd.org/D31592
