#
d5fe384b |
| 14-Dec-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Enable ROUTE_MPATH support in GENERIC kernels.
Ability to load-balance traffic over multiple path is a must-have thing for routers. It may be used by the servers to balance outgoing traffic over mul
Enable ROUTE_MPATH support in GENERIC kernels.
Ability to load-balance traffic over multiple path is a must-have thing for routers. It may be used by the servers to balance outgoing traffic over multiple default gateways.
The previous implementation, RADIX_MPATH stayed in the shadow for too long. It was not well maintained, which lead us to a vicious circle - people were using non-contiguous mask or firewalls to achieve similar goals. As a result, some routing daemons implementation still don't have multipath support enabled for FreeBSD.
Turning on ROUTE_MPATH by default would fix it. It will allow to reduce networking feature gap to other operating systems. Linux and OpenBSD enabled similar support at least 5 years ago.
ROUTE_MPATH does not consume memory unless actually used. It enables around ~1k LOC.
It does not bring any behaviour changes for userland. Additionally, feature is (temporarily) turned off by the net.route.multipath sysctl defaulting to 0.
Differential Revision: https://reviews.freebsd.org/D27428
show more ...
|
#
9ee99cec |
| 11-Dec-2020 |
Brooks Davis <brooks@FreeBSD.org> |
hme(4): Remove as previous announced
The hme (Happy Meal Ethernet) driver was the onboard NIC in most supported sparc64 platforms. A few PCI NICs do exist, but we have seen no evidence of use on non
hme(4): Remove as previous announced
The hme (Happy Meal Ethernet) driver was the onboard NIC in most supported sparc64 platforms. A few PCI NICs do exist, but we have seen no evidence of use on non-sparc systems.
Reviewed by: imp, emaste, bcr Sponsored by: DARPA
show more ...
|
#
a4a10b37 |
| 30-Nov-2020 |
Toomas Soome <tsoome@FreeBSD.org> |
Add VT driver for VBE framebuffer device
Implement vt_vbefb to support Vesa Bios Extensions (VBE) framebuffer with VT. vt_vbefb is built based on vt_efifb and is assuming similar data for initializa
Add VT driver for VBE framebuffer device
Implement vt_vbefb to support Vesa Bios Extensions (VBE) framebuffer with VT. vt_vbefb is built based on vt_efifb and is assuming similar data for initialization, use MODINFOMD_VBE_FB to identify the structure vbe_fb in kernel metadata.
struct vbe_fb, is populated by boot loader, and is passed to kernel via metadata payload.
Differential Revision: https://reviews.freebsd.org/D27373
show more ...
|
#
f120ad6b |
| 27-Nov-2020 |
Ruslan Bukin <br@FreeBSD.org> |
o Move options IOMMU from Debugging section back to the Bus section where it originally was. The bug introduced in r366267. o Remove options IOMMU from i386/MINIMAL as we don't have it in i386/GE
o Move options IOMMU from Debugging section back to the Bus section where it originally was. The bug introduced in r366267. o Remove options IOMMU from i386/MINIMAL as we don't have it in i386/GENERIC.
Reported by: Harry Schmalzbauer <freebsd@omnilan.de> Reviewed by: kib Sponsored by: Innovate DSbD Differential Revision: https://reviews.freebsd.org/D27399
show more ...
|
#
926ce35a |
| 24-Nov-2020 |
Jung-uk Kim <jkim@FreeBSD.org> |
Port rtsx(4) driver for Realtek SD card reader from OpenBSD.
This driver provides support for Realtek PCI SD card readers. It attaches mmc(4) bus on card insertion and detaches it on card removal.
Port rtsx(4) driver for Realtek SD card reader from OpenBSD.
This driver provides support for Realtek PCI SD card readers. It attaches mmc(4) bus on card insertion and detaches it on card removal. It has been tested with RTS5209, RTS5227, RTS5229, RTS522A, RTS525A and RTL8411B. It should also work with RTS5249, RTL8402 and RTL8411.
PR: 204521 Submitted by: Henri Hennebert (hlh at restart dot be) Reviewed by: imp, jkim Differential Revision: https://reviews.freebsd.org/D26435
show more ...
|
#
7113afc8 |
| 11-Oct-2020 |
Emmanuel Vadot <manu@FreeBSD.org> |
10Gigabit Ethernet driver for AMD SoC
This patch has the driver for 10Gigabit Ethernet controller in AMD SoC. This driver is written compatible to the Iflib framework. The existing driver is for the
10Gigabit Ethernet driver for AMD SoC
This patch has the driver for 10Gigabit Ethernet controller in AMD SoC. This driver is written compatible to the Iflib framework. The existing driver is for the old version of hardware. The submitted driver here is for the recent versions of the hardware where the Ethernet controller is PCI-E based.
Submitted by: Rajesh Kumar <rajesh1.kumar@amd.com> MFC after: 1 month Relnotes: yes Differential Revision: https://reviews.freebsd.org/D25793
show more ...
|
#
6186bfbd |
| 29-Sep-2020 |
Ruslan Bukin <br@FreeBSD.org> |
Rename kernel option ACPI_DMAR to IOMMU. This is mostly needed for a common arm64/amd64 iommu code.
Reviewed by: kib Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D265
Rename kernel option ACPI_DMAR to IOMMU. This is mostly needed for a common arm64/amd64 iommu code.
Reviewed by: kib Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D26587
show more ...
|
#
b798ef64 |
| 24-Jul-2020 |
Alex Richardson <arichardson@FreeBSD.org> |
Include TMPFS in all the GENERIC kernel configs
Being able to use tmpfs without kernel modules is very useful when building small MFS_ROOT kernels without a real file system. Including TMPFS also ma
Include TMPFS in all the GENERIC kernel configs
Being able to use tmpfs without kernel modules is very useful when building small MFS_ROOT kernels without a real file system. Including TMPFS also matches arm/GENERIC and the MIPS std.MALTA configs.
Compiling TMPFS only adds 4 .c files so this should not make much of a difference to NO_MODULES build times (as we do for our minimal RISC-V images).
Reviewed By: br (earlier version for riscv), brooks, emaste Differential Revision: https://reviews.freebsd.org/D25317
show more ...
|
#
e64080e7 |
| 16-Jul-2020 |
Mark Johnston <markj@FreeBSD.org> |
Switch from SCTP to SCTP_SUPPORT in GENERIC configs.
This removes SCTP from in-tree kernel configuration files. Now, SCTP can be enabled by simply loading the module, as discussed on freebsd-net@.
Switch from SCTP to SCTP_SUPPORT in GENERIC configs.
This removes SCTP from in-tree kernel configuration files. Now, SCTP can be enabled by simply loading the module, as discussed on freebsd-net@.
Reviewed by: tuexen Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D25611
show more ...
|
#
71d10453 |
| 26-May-2020 |
Eric Joyner <erj@FreeBSD.org> |
ice(4): Introduce new driver for Intel E800 Ethernet controllers
The ice(4) driver is the driver for the Intel E8xx series Ethernet controllers; currently with codenames Columbiaville and Columbia P
ice(4): Introduce new driver for Intel E800 Ethernet controllers
The ice(4) driver is the driver for the Intel E8xx series Ethernet controllers; currently with codenames Columbiaville and Columbia Park.
These new controllers support 100G speeds, as well as introducing more queues, better virtualization support, and more offload capabilities. Future work will enable virtual functions (like in ixl(4)) and the other functionality outlined above.
For full functionality, the kernel should be compiled with "device ice_ddp" like in the amd64 NOTES file, and/or ice_ddp_load="YES" should be added to /boot/loader.conf so that the DDP package file included in this commit can be downloaded to the adapter. Otherwise, the adapter will fall back to a single queue mode with limited functionality.
A man page for this driver will be forthcoming.
MFC after: 1 month Relnotes: yes Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D21959
show more ...
|
#
37bd4ba9 |
| 12-Apr-2020 |
Conrad Meyer <cem@FreeBSD.org> |
Add queue(2) debug macros as build options
Add QUEUE_MACRO_DEBUG_TRACE and QUEUE_MACRO_DEBUG_TRASH as proper kernel options. While here, alpha-sort the debug section of sys/conf/options.
Enable QU
Add queue(2) debug macros as build options
Add QUEUE_MACRO_DEBUG_TRACE and QUEUE_MACRO_DEBUG_TRASH as proper kernel options. While here, alpha-sort the debug section of sys/conf/options.
Enable QUEUE_MACRO_DEBUG_TRASH in amd64 GENERIC (but not GENERIC-NODEBUG) kernels. It is similar in nature and cost to other use-after-free pointer trashing we do in GENERIC. It is probably reasonable to enable in any arch GENERIC kernel that defines INVARIANTS.
show more ...
|
#
33ce28d1 |
| 28-Nov-2019 |
Scott Long <scottl@FreeBSD.org> |
Remove the trm(4) driver
Differential Revision: https://reviews.freebsd.org/D22575
|
#
849aef49 |
| 21-Nov-2019 |
Andrew Turner <andrew@FreeBSD.org> |
Port the NetBSD KCSAN runtime to FreeBSD.
Update the NetBSD Kernel Concurrency Sanitizer (KCSAN) runtime to work in the FreeBSD kernel. It is a useful tool for finding data races between threads exe
Port the NetBSD KCSAN runtime to FreeBSD.
Update the NetBSD Kernel Concurrency Sanitizer (KCSAN) runtime to work in the FreeBSD kernel. It is a useful tool for finding data races between threads executing on different CPUs.
This can be enabled by enabling KCSAN in the kernel config, or by using the GENERIC-KCSAN amd64 kernel. It works on amd64 and arm64, however the later needs a compiler change to allow -fsanitize=thread that KCSAN uses.
Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D22315
show more ...
|
#
052e12a5 |
| 14-Nov-2019 |
Josh Paetzel <jpaetzel@FreeBSD.org> |
Add the pvscsi driver to the tree.
This driver allows to usage of the paravirt SCSI controller in VMware products like ESXi. The pvscsi driver provides a substantial performance improvement in bloc
Add the pvscsi driver to the tree.
This driver allows to usage of the paravirt SCSI controller in VMware products like ESXi. The pvscsi driver provides a substantial performance improvement in block devices versus the emulated mpt and mps SCSI/SAS controllers.
Error handling in this driver has not been extensively tested yet.
Submitted by: vbhakta@vmware.com Relnotes: yes Sponsored by: VMware, Panzura Differential Revision: D18613
show more ...
|
#
dda17b36 |
| 17-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Implement NetGDB(4)
NetGDB(4) is a component of a system using a panic-time network stack to remotely debug crashed FreeBSD kernels over the network, instead of traditional serial interfaces.
There
Implement NetGDB(4)
NetGDB(4) is a component of a system using a panic-time network stack to remotely debug crashed FreeBSD kernels over the network, instead of traditional serial interfaces.
There are three pieces in the complete NetGDB system.
First, a dedicated proxy server must be running to accept connections from both NetGDB and gdb(1), and pass bidirectional traffic between the two protocols.
Second, the NetGDB client is activated much like ordinary 'gdb' and similarly to 'netdump' in ddb(4) after a panic. Like other debugnet(4) clients (netdump(4)), the network interface on the route to the proxy server must be online and support debugnet(4).
Finally, the remote (k)gdb(1) uses 'target remote <proxy>:<port>' (like any other TCP remote) to connect to the proxy server.
The NetGDB v1 protocol speaks the literal GDB remote serial protocol, and uses a 1:1 relationship between GDB packets and sequences of debugnet packets (fragmented by MTU). There is no encryption utilized to keep debugging sessions private, so this is only appropriate for local segments or trusted networks.
Submitted by: John Reimer <john.reimer AT emc.com> (earlier version) Discussed some with: emaste, markj Relnotes: sure Differential Revision: https://reviews.freebsd.org/D21568
show more ...
|
#
7790c8c1 |
| 17-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Split out a more generic debugnet(4) from netdump(4)
Debugnet is a simplistic and specialized panic- or debug-time reliable datagram transport. It can drive a single connection at a time and is cur
Split out a more generic debugnet(4) from netdump(4)
Debugnet is a simplistic and specialized panic- or debug-time reliable datagram transport. It can drive a single connection at a time and is currently unidirectional (debug/panic machine transmit to remote server only).
It is mostly a verbatim code lift from netdump(4). Netdump(4) remains the only consumer (until the rest of this patch series lands).
The INET-specific logic has been extracted somewhat more thoroughly than previously in netdump(4), into debugnet_inet.c. UDP-layer logic and up, as much as possible as is protocol-independent, remains in debugnet.c. The separation is not perfect and future improvement is welcome. Supporting INET6 is a long-term goal.
Much of the diff is "gratuitous" renaming from 'netdump_' or 'nd_' to 'debugnet_' or 'dn_' -- sorry. I thought keeping the netdump name on the generic module would be more confusing than the refactoring.
The only functional change here is the mbuf allocation / tracking. Instead of initiating solely on netdump-configured interface(s) at dumpon(8) configuration time, we watch for any debugnet-enabled NIC for link activation and query it for mbuf parameters at that time. If they exceed the existing high-water mark allocation, we re-allocate and track the new high-water mark. Otherwise, we leave the pre-panic mbuf allocation alone. In a future patch in this series, this will allow initiating netdump from panic ddb(4) without pre-panic configuration.
No other functional change intended.
Reviewed by: markj (earlier version) Some discussion with: emaste, jhb Objection from: marius Differential Revision: https://reviews.freebsd.org/D21421
show more ...
|
#
f2521a76 |
| 10-Oct-2019 |
Doug Ambrisko <ambrisko@FreeBSD.org> |
This driver attaches to the Intel VMD drive and connects a new PCI domain starting at the max. domain, and then work down. Then existing FreeBSD drivers will attach. Interrupt routing from the VMD
This driver attaches to the Intel VMD drive and connects a new PCI domain starting at the max. domain, and then work down. Then existing FreeBSD drivers will attach. Interrupt routing from the VMD MSI-X to the NVME drive is not well known, so any interrupt is sent to all children that register.
VROC used Intel meta data so graid(8) works with it. However, graid(8) supports RAID 0,1,10 for read and write. I have some early code to support writes with RAID 5. Note that RAID 5 can have life issues with SSDs since it can cause write amplification from updating the parity data.
Hot plug support needs a change to skip the following check to work: if (pcib_request_feature(dev, PCI_FEATURE_HP) != 0) { in sys/dev/pci/pci_pci.c.
Looked at by: imp, rpokala, bcr Differential Revision: https://reviews.freebsd.org/D21383
show more ...
|
#
9923b641 |
| 03-Oct-2019 |
Ed Maste <emaste@FreeBSD.org> |
Remove host binary object drivers from GENERIC
Four drivers (hpt27xx, hptmv, hptnr, hptrr, hpt27xx) include precompiled binary objects; have users load them as modules if they are needed.
Additiona
Remove host binary object drivers from GENERIC
Four drivers (hpt27xx, hptmv, hptnr, hptrr, hpt27xx) include precompiled binary objects; have users load them as modules if they are needed.
Additional work (i.e., integrating devmatch) required before MFC.
Reviewed by: markj Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21865
show more ...
|
#
c363b16c |
| 21-Jun-2019 |
Conrad Meyer <cem@FreeBSD.org> |
sys: Remove DEV_RANDOM device option
Remove 'device random' from kernel configurations that reference it (most). Replace perhaps mistaken 'nodevice random' in two MIPS configs with 'options RANDOM_L
sys: Remove DEV_RANDOM device option
Remove 'device random' from kernel configurations that reference it (most). Replace perhaps mistaken 'nodevice random' in two MIPS configs with 'options RANDOM_LOADABLE' instead. Document removal in UPDATING; update NOTES and random.4.
Reviewed by: delphij, markm (previous version) Approved by: secteam(delphij) Differential Revision: https://reviews.freebsd.org/D19918
show more ...
|
#
02fae06a |
| 17-May-2019 |
Brooks Davis <brooks@FreeBSD.org> |
FCP-101: Remove wb(4)
Relnotes: yes FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md Reviewed by: jhb, imp Differential Revision: https://reviews.freebsd.org/D20230
|
#
e8504bf9 |
| 17-May-2019 |
Brooks Davis <brooks@FreeBSD.org> |
FCP-101: Remove vx(4).
Relnotes: yes FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md Reviewed by: jhb, imp Differential Revision: https://reviews.freebsd.org/D20230
|
#
be345ff0 |
| 17-May-2019 |
Brooks Davis <brooks@FreeBSD.org> |
FCP-101: Remove txp(4).
Relnotes: yes FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md Reviewed by: jhb, imp Differential Revision: https://reviews.freebsd.org/D20230
|
#
b1b1c2fe |
| 17-May-2019 |
Brooks Davis <brooks@FreeBSD.org> |
FCP-101: Remove tx(4).
Relnotes: yes FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md Reviewed by: jhb, imp Differential Revision: https://reviews.freebsd.org/D20230
|
#
7c897ca9 |
| 17-May-2019 |
Brooks Davis <brooks@FreeBSD.org> |
FCP-101: Remove tl(4).
Relnotes: yes FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md Reviewed by: jhb, imp Differential Revision: https://reviews.freebsd.org/D20230
|
#
3b70dd81 |
| 17-May-2019 |
Brooks Davis <brooks@FreeBSD.org> |
FCP-101: Remove sf(4).
Relnotes: yes FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md Reviewed by: jhb, imp Differential Revision: https://reviews.freebsd.org/D20230
|