When multiple IRQs are specified in a single resource then we only
check the first. Change this to check all interrupts for the value
we expect to find.
Without this we may still enable the interrupt, but it can have the
wrong polatiry or trigger. This can cause an interrupt storm if the
interrupt was configured with a level trigger when it should have
been an edge.
PR: 282241
Reported by: trasz
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47487
The driver wasn't stable - it would start fine, but during scan
it would eventually hang and no further command endpoint transfers
would complete.
After adding some debugging and looking at the logs I noticed that
things went sideways once a /data/ frame was sent. The channel
change config happened between the data frame being sent and
being completed.
My guess is that the firmware doesn't like a channel change
and reset whilst there's pending data frames. Checking the Linux
driver I found that it was doing a flush before a channel change,
and we're doing it afterwards. This acts like a fence around
ensuring scheduled TX work has completed. In net80211 the
transmit path and the control path aren't serialised, so it's
very often the case that ioctls, state changes, etc occur
whilst in parallel there are frame transmits being scheduled.
This seems to happen more frequently on a more recent, high core
(8) machine with XHCI. I remember testing this driver years ago
on single and dual core CPU laptops with no problems.
So, add some flushes - before a channel change, and during
a transition to AUTH when the BSS config is being programmed into
the firmware. These two fences seem enough to reliably
associate as a 2GHz and 5GHz STA.
Note that this isn't entirely blocking all newly queued
transmit work from occuring until after the NIC has finished
configuration. That will need some further investigation.
Locally tested:
* Wistron NuWeb AR5523 dual-band NIC, STA mode, 2/5GHz
Differential Revision: https://reviews.freebsd.org/D47655
Use the correct ID, as I have one of these NICs.
Add the previous one back in case it's out there in the wild.
@emaste did a bit of a dig into the product numbers.
@sam did change the ID from 0x0828 -> 082a in a commit
a long while back. It's worth reading the code review for
further details.
However, I do have one of these NICs and I verified that
it indeed has the given ID, and with some follow-up work
to fix some race conditions, it works fine in 2GHz 11bg
and 5GHz 11a operation.
Differential Revision: https://reviews.freebsd.org/D47654
Obtained from: Linux, drivers/net/wireless/ath/ar5523/ar5523.c
This will be useful when fixing up the sequence number generation
and checks, as the rules around how sequence numbers are generated
have been clarified in 802.11-2016 and later. QoS-NULL frames are
explicitly marked as "any sequence number".
But for now, just create a macro and use it in the one place
it's currently being used as a check - ath(4).
* Add IEEE80211_IS_QOS_NULL().
* Change the "will this frame go into the TX block-ack window" check
in the ath(4) transmit path. Note this changes the check to be
more specific, but both paths already had previous checks to ensure
they're QoS data frames.
Locally tested:
* ath(4), AR9380, STA mode w/ AMPDU TX/RX enabled and negotiated
Differential Revision: https://reviews.freebsd.org/D47645
HIDRAW_GET_REPORT ioctl is documented to update hgd_actlen on return
with the number of bytes copied. It does not do this.
Reviewed by: wulf
PR: 282790
MFC after: 1 week
USB_GET_REPORT ioctl is documented to update ugd_actlen on return with
the number of bytes copied. It does not do this.
Reviewed by: wulf
PR: 282790
MFC after: 1 week
* Add macros for the management and control frame type checks that
I've come across in the drivers.
* Delete some now old code (eg ath's ieee80211_is_action()) as there's now
a macro for it.
Local testing:
* not yet, I have a lot of wifi devices to find and test against
Differential Revision: https://reviews.freebsd.org/D47500
Add the SOC_ALLWINNER_D1 config option, following other platforms.
Co-authored-by: mhorne
Reviewed by: manu (previous version)
Sponsored by: The FreeBSD Foundation (in part)
Differential Revision: https://reviews.freebsd.org/D47515
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
