This is a relatively well known trick for the X520 (82599), can be
useful for testing and lab settings. It's not an official standard or
particularly common but ubiquitous Broadcom switch ASICs deal with it.
We'll call it 1000Base-KX because it's SerDes on the passive cable and
I don't think it's worth adding another media type for this.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D47352
Only ever set the capabilities bits if kernel options are enabled.
Check for hardware capabilities before setting software bits.
Sponsored by: NVidia networking
MFC after: 1 week
Correct leading whitespace for a few lines.
Consistently use more canonical #ifdef to test for COMPAT_FREEBSD32.
Obtained from: CheriBSD
Sponsored by: AFRL, DARPA
This isn't really needed since the host driver never submits more
commands to a queue than it can hold, but I noticed that the
recently-added SQ head and tail sysctl nodes were not updating. This
fixes that and also uses these values to assert that there we never
submit a command while a queue pair is full.
Sponsored by: Chelsio Communications
Similar to nvme(4), use the current CPU to select which I/O queue to
use. The assignment in nvmf_attach() had to be moved down since
sc->num_io_queues is initialized in nvmf_establish_connection().
Note that nvmecontrol(8) still defaults to using a single I/O queue
for an association.
Sponsored by: Chelsio Communications
By inspection, index increment was missing.
PR: 281843
Reported by: Matt Jacobson
Reviewed by: bz, markj
Fixes: e4611d2626 ("usb(4): Call optional endpoint_uninit() when changing configuration or alternate setting.")
Sponsored by: The FreeBSD Foundation
There are some contexts where it is safe to sleep, so we should pass
M_WAITOK to ensure that a null pointer dereference can't happen.
A few places allocate with M_NOWAIT but have no way to signal an error.
Flag those with an XXX comment.
PR: 276770
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D47307
Some iichid(4) child devices, currently hkbd(4) only, opens parent
device in their attach handlers. That breaks internal iichid(4) state
leading to rejecting any incoming data on software and hardware levels.
Fix it with adding of extra state check in iichid(4) attach handler.
Reported by: many
Submitted by: trasz (initial version)
PR: 280290
MFC after: 3 days
We have been incorrectly choosing the "hlt" idle method on modern AMD
EPYC servers for C1 idle. This is because AMD also uses the Functional
Fixed Hardware interface. Due to not parsing the table properly for
AMD, and due to a weird quirk where the mwait latency for C1 is
mis-interpreted as the latency for hlt, we wind up choosing hlt for
c1, which has a far higher wake up latency (similar to IO) of roughly
400us on my test system (AMD 7502P).
This patch fixes this by:
- Looking for AMD in addition to Intel in the FFH
(Note the vendor id of "2" for AMD is not publically documented, but
AMD has confirmed they are using "2" and has promised to document it.)
- Using mwait on AMD when specified in the table, and when CPUid says
its supported
- Fixing a weird issue where we copy the contents of cx_ptr for C1 and
when moving to C2, we do not reinitialize cx_ptr. This leads to
mwait being selected, and ignoring the specified i/o halt method
unless we clear mwait before looking at the table for C2.
Differential Revision: https://reviews.freebsd.org/D47444
Reviewed by: dab, kib, vangyzen
Sponsored by: Netflix
Don't schedule work during reset / abort. For USB NICs, work
must not be scheduled during a call to rtwn_usb_abort_xfers(),
as then it'll cause the call to usbd_transfer_drain() to hang.
This fixes a hang I've been seeing where the NIC hits a TX timeout
and then the reset/re-init path is called. If data is scheduled
to be transmitted in that window, the call to usbd_transfer_drain()
would hang and require a hard reboot to recover.
Differential Revision: https://reviews.freebsd.org/D47479
Key code swapping between [<>] and [^°] key is enabled for all Apple ISO
type keyboards. Before, swapping was enabled when the Eject key was
detected in HID usage. This did not correlate well with the swapped
keys presence.
usbdevs file is extended by several Apple keyboard models to support ISO
model identification.
Reviewed by: markj
MFC after: 2 weeks
Pull Request: https://github.com/freebsd/freebsd-src/pull/1506
* Adds support for SFPs that are not correctly coded as an SFP
transceiver. i.e. Coherent-Finisar FCLF8522P2BTL.
* Configures multi-rate SFPs i.e. Coherent-Finisar FCLF8522P2BTL as
SGMII so they can do 10/100/1000 auto-negotiation.
* Adds support for 100BaseLX SGMII transceivers.
* Some code cleanup and additional debugging.
Reviewed by: emaste, markj, Franco Fichtner <franco@opnsense.org>
Tested by: Natalino Picone <natalino.picone@nozominetworks.com>
MFC after: 2 weeks
Sponsored by: Nozomi Networks
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D47337
Before this change the transmit taskqueue would enqueue itself when it
cannot find space on the NIC ring with the hope that eventually space
would be made. This results in the following livelock that only occurs
after passing ~200Gbps of TCP traffic for many hours:
100% CPU
┌───────────┐wait on ┌──────────┐ ┌───────────┐
│user thread│ cpu │gve xmit │wait on │gve cleanup│
│with mbuf ├────────►│taskqueue ├────────►│taskqueue │
│uma lock │ │ │ NIC ring│ │
└───────────┘ └──────────┘ space └─────┬─────┘
▲ │
│ wait on mbuf uma lock │
└───────────────────────────────────────────┘
Further details about the livelock are available on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560.
After this change, the transmit taskqueue no longer spins till there is
room on the NIC ring. It instead stops itself and lets the
completion-processing taskqueue wake it up.
Since I'm touching the trasnmit taskqueue I've also corrected the name
of a counter and also fixed a bug where EINVAL mbufs were not being
freed and were instead living forever on the bufring.
Signed-off-by: Shailend Chand <shailend@google.com>
Reviewed-by: markj
MFC-after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D47138
DQO is the descriptor format for our next generation virtual NIC.
It is necessary to make full use of the hardware bandwidth on many
newer GCP VM shapes.
This patch extends the previously introduced DQO descriptor format
with a "QPL" mode. QPL stands for Queue Page List and refers to
the fact that the hardware cannot access arbitrary regions of the
host memory and instead expects a fixed bounce buffer comprising
of a list of pages.
The QPL aspects are similar to the already existing GQI queue
queue format: in that the mbufs being input in the Rx path have
external storage in the form of vm pages attached to them; and
in the Tx path we always copy the mbuf payload into QPL pages.
Signed-off-by: Shailend Chand <shailend@google.com>
Reviewed-by: markj
MFC-after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D46691
DQO is the descriptor format for our next generation virtual NIC.
It is necessary to make full use of the hardware bandwidth on many
newer GCP VM shapes.
One major change with DQO from its predecessor GQI is that it uses
dual descriptor rings for both TX and RX queues.
The TX path uses a descriptor ring to send descriptors to HW, and
receives packet completion events on a TX completion ring.
The RX path posts buffers to HW using an RX descriptor ring and
receives incoming packets on an RX completion ring.
In GQI-QPL, the hardware could not access arbitrary regions of
guest memory, which is why there was a pre-negotitated bounce buffer
(QPL: Queue Page List). DQO-RDA has no such limitation.
"RDA" is in contrast to QPL and stands for "Raw DMA Addressing" which
just means that HW does not need a fixed bounce buffer and can DMA
arbitrary regions of guest memory.
A subsequent patch will introduce the DQO-QPL datapath that uses the
same descriptor format as in this patch, but will have a fixed
bounce buffer.
Signed-off-by: Shailend Chand <shailend@google.com>
Reviewed-by: markj
MFC-after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D46690
This supersedes the sysctl interface, which has the limitations of being
root-only and not supporting automatic resource destruction, i.e., we
cannot easily destroy VMs automatically when bhyve terminates.
For now, two ioctls are implemented VMMCTL_VM_CREATE and
VMMCTL_VM_DESTROY. Eventually I would like to support tying a VM's
lifetime to that of the descriptor, so that it is automatically
destroyed when the descriptor is closed. However, this will require
some work in bhyve: when the guest wants to reboot, bhyve exits with a
status that indicates that it is to be restarted. This is incompatible
with the idea of tying a VM's lifetime to that of a descriptor, since we
want to avoid creating and destroying a VM across each reboot (as this
involves freeing all of the guest memory, among other things). One
possible design would be to decompose bhyve into two processes, a parent
which handles reboots, and a child which runs in capability mode and
handles guest execution.
In any case, this gets us closer to addressing the shortcomings
mentioned above.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D47028
These drivers do not add child devices, so there's no need to try to
detach children.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47390
These drivers are not bus drivers, and would need proper detach
routines that tore down state stored in the softc. Better to just
fail detach outright instead of an incorrect success.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47389
These detach routines in these drivers all ended with 'return
(bus_generic_detach())' meaning that if any child device failed to
detach, the parent driver was left in a mostly destroyed state, but
still marked attached. Instead, bus drivers should detach child
drivers first and return errors before destroying driver state in the
parent.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47387
The active namespace list query fetches namespaces greater than the
passed in namespace ID, not greater than or equal to the passed in
namespace ID. Thus, a multi-page request should start with the last
namespace ID from the previous page, not that ID plus 1.
While here, make use of NVME_GLOBAL_NAMESPACE_TAG instead of a magic
number to handle the edge case that the last namespace ID in a page is
the largest valid namespace ID.
Reviewed by: chuck
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D47393
When running FreeBSD on an arm64/aarch64 QEMU virtual machine, using the
Intel HD Audio Controller (ich6) (intel-hda), for example, and by
following the procedure in the handbook ("Setting Up the Sound Card"):
kldload snd_driver
The following error is shown:
KLD snd_driver.ko: depends on snd_cmi - not available or version mismatch
This is because the CMedia sound driver (snd_cmi) is only built for i386
and amd64.
Add the same guards to the snd_driver metadriver.
Reviewed by: christos, emaste
Approved by: emaste (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47399
Header ice_rss.h uses the kernel RSS interface if option RSS is defined.
However when ice_rss.h is included by ice_lib.h there is no prior
inclusion of ice_opts.h to set RSS causing ifdef RSS to always fail. Add
ice_opts.h to the top of ice_lib.h (like ice_iflib.h) so RSS can be
defined when ice_rss.h is parsed.
With that in place, compilation fails due to a missing defintion of
ICE_DEFAULT_RSS_HASH_CONFIG. It is defined in ice_rss.h only when RSS is
not defined. Since this define is not part of the kernel RSS interface
but ice-specific, it should always be defined. Move its definition
outside of ifdef RSS.
PR: 255309
Reviewed by: mhorne, erj (earlier version)
MFC after: 3 days
Pull Request: https://github.com/freebsd/freebsd-src/pull/1460
The way a sound driver currently registers to sound(4) is using the
following sequence of function calls:
1. pcm_register() to initialize snddev_info.
2. pcm_addchan() calls to create the device's primary channels.
3. pcm_setstatus() to do the final setup.
While using 3 different functions in a specific order might not be very
elegant, this pattern cannot be easily avoided. However, pcm_register()
and pcm_setstatus() are especially confusing, since one would
intuitively expect:
1. pcm_register() to actually do the registration, as opposed to a basic
initialization.
2. pcm_setstatus() to, as the name suggests, set some kind of status, as
opposed to finalizing the registration.
This patch renames pcm_register() to pcm_init(), and pcm_setstatus() to
pcm_register(). Drivers are modified accordingly.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D47325
These flags are properly set in pcm_setstatus(), once the primary
channels have been created. The existing comment already states that
this is wrong.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D47324
The d->status string is populated in pcm_setstatus() anyway, so call
sndstat_register() after we populate it, and are closer to finalizing
the device creation.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D47323
Create the sysctl and /dev/dsp* nodes in pcm_setstatus(), which is
responsible for finalizing the device initialization, instead of doing
this in the middle of the initialization.
For the sysctl creation specifically, move them into pcm_sysinit(),
since this is where we create the rest of the sysctl nodes anyway.
A side effect of this change is, that we avoid the possibility of racing
in between pcm_register() and pcm_setstatus() by accessing /dev/dspX or
the sysctls within that window.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D47322
pcm_veto_load is used to prevent pcm_register() from running if the root
feeder has not been registered yet. However, feeder_register_root() is a
SYSINIT.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D47280
The KDMKTONE ioctl, introduced in commit 916347f77e, is used to beep
the PC speaker. For historical reasons the frequency is specified as an
8254 PIT divisor for a 1.19MHz clock. Linux provides this same ioctl.
Add a comment to vtterm_beep to avoid someone wanting to "fix" this in
the future.
Also add an XXX comment that the period unit is supposed to be "timer
ticks." Note that nothing in the base system uses this ioctl.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47395
Expand the comment a little to make it clearer: Once we've restarted,
we're out of the resetting phase in our state machine. The controller
has actually been out of reset since we started issuing commands to it
earlier in the resetting phase.
Sponsored by: Netflix
Previously the handler was removed from the wrong eventhandler list.
Fixes: f46d4971b5 nvmf: Handle shutdowns more gracefully
Sponsored by: Chelsio Communications
PDU data alignment (PDA) isn't necessarily a power of 2, just a
multiple of 4, so use roundup() instead of roundup2() to compute the
PDU data offset (PDO).
Sponsored by: Chelsio Communications
386BSD provided a MD function sysbeep. This took two arguments (pitch
and period). Pitch was jammed into the PIT's divisor directly (which
means the argument was expected to sound a tone at '1193182 / pitch'
Hz). FreeBSD inherited this interface.
In commit e465985885 (svn 177642, Mar 26 2008), phk changed this
function to take a tone to sound in hz. He converted all in-tree
instances of 1193182 / hz to just hz (and kept the few misguided folks
that passed hz directly unchanged -- this was part of what motivated the
change). He converted the places where we pre-computed the 8254 divisor
from being pitch to 1193182 / pitch (since that converts the divisor to
the frequency and the interfaces that were exposed to userland exposed
it in these units in places, continuing the tradition inherited from SCO
System V/386 Unix in spots).
In 2009, Ed Shouten was contracted by the FreeBSD Foundation to write /
finish newcons. This work was done in perforce and was imported into
subversion in user/ed/newcons in revision 199072
(https://svnweb.freebsd.org/base?view=revision&revision=199072) which
was later imported into FreeBSD by ray@ (Aleksandr Rybalko).
From that earliest import into svn import to this date, we ring the bell
with:
sysbeep(1193182 / VT_BELLPITCH, VT_BELLDURATION);
where VT_BELLPITCH was defined to be 800. This results in a bell
frequency of 1491Hz, more or less today. This is similar to the
frequency that syscons and pcvt used (1493Hz and 1500Hz respectively).
This in turn was inherited from 386BSD, it seems, which used the hard
coded value 0x31b which is 795 -> 1500Hz.
This '800' was intended to be the bell tone (eg 800Hz) and this
interface was one that wasn't converted. The most common terminal prior
to the rise of PCs was the VT100, which had an approximately 800Hz
bell. Ed Shouten has confirmed that the original intent was 800Hz and
changing this was overlooked after the change to -current was made.
This restors that original intent and makes the bell less obnoxious in
the process.
Reviewed by: des, adrian
Differential Revision: https://reviews.freebsd.org/D32594
Sponsored by: Netflix
(cherry picked from commit ba48d52ca6)
This change was accidentally reverted in 80f21bb039.
If a device was detached (e.g. via devctl) and then re-attached, the
ivars would be freed by the previous bus_child_detached method during
detach, but device_get_ivars during the subsequent attach would return
a stale pointer resulting in a use after free.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47371
