Currently, when we suspend, we need to tear down all the qpairs. We call
nvme_admin_qpair_abort_aers with the admin qpair lock held, but the
tracker it will call for the pending AER also locks it (recursively)
hitting an assert. This routine is called without the qpair lock held
when we destroy the device entirely in a number of places. Add an assert
to this effect and drop the qpair lock before calling it.
nvme_admin_qpair_abort_aers then locks the qpair lock to traverse the
list, dropping it around calls to nvme_qpair_complete_tracker, and
restarting the list scan after picking it back up.
Note: If interrupts are still running, there's a tiny window for these
AERs: If one fires just an instant after we manually complete it, then
we'll be fine: we set the state of the queue to 'waiting' and we ignore
interrupts while 'waiting'. We know we'll destroy all the queue state
with these pending interrupts before looking at them again and we know
all the TRs will have been completed or rescheduled. So either way we're
covered.
Also, tidy up the failure case as well: failing a queue is a superset of
disabling it, so no need to call disable first. This solves solves some
locking issues with recursion since we don't need to recurse.. Set the
qpair state of failed queues to RECOVERY_FAILED and stop scheduling the
watchdog. Assert we're not failed when we're enabling a qpair, since
failure currently is one-way. Make failure a little less verbose.
Next, kill the pre/post reset stuff. It's completely bogus since we
disable the qparis, we don't need to also hold the lock through the
reset: disabling will cause the ISR to return early. This keeps us from
recursing on the recovery lock when resuming. We only need the recovery
lock to avoid a specific race between the timer and the ISR.
Finally, kill NVME_RESET_2X. It'S been a major release since we put it
in and nobody has used it as far as I can tell. And it was a motivator
for the pre/post uglification.
These are all interrelated, so need to be done at the same time.
Sponsored by: Netflix
Reviewed by: jhb
Tested by: jhb (made sure suspend / resume worked)
MFC After: 3 days
Differential Revision: https://reviews.freebsd.org/D41866
Until a better arrangment is worked out, guard the setting of
CROSS_TARGET_FLAGS in local.sys.mk with check for DIRDEPS_BUILD.
Using a separate flag for CROSS_TARGET that can be reset by
bsd.compat.mk is probably the right thing.
\D{format} yields the result of calling strftime(3) with the provided
format and the current time.
When PS4 can use this, it will enable us to easily generate timestamps
when tracing script execution.
Differential Revision: https://reviews.freebsd.org/D35840
It is not the first time I see it panicking while trying to modify
const memory. Lets make it safer and easier to use. While there,
mark few functions using it also const.
MFC after: 10 days
A ng_eiface instance may be on lease to a different vnet while
remaining tied to its parent vnet. In such circumstances, before
injecting mbufs into netgraph, curvnet must be set to that of the
ng_eiface's netgraph node. Mark the vnet transition as QUIET,
since otherwise it would be recorded as a curvnet recursion when
ng_eiface's ifnet resides in the same (parent) vnet as its
netgraph node.
PR: 274028
Reported by: Dancho Penev <dpslavov@hotmail.com>
MFC after: 1 week
Allow building 32bit libs for host.
Move CFLAGS additions from local.sys.dirdeps.mk (which is too early
and impacts CFLAGS defaults) to local.sys.mk
Reviewed by: stevek
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D41946
'ncnegminpct' is to be passed always, so just drop the unneeded parameter.
Sponsored by: The FreeBSD Foundation
Reviewed by: mjg
Differential Revision: https://reviews.freebsd.org/D41763
Factoring out this code unfortunately introduced reference and lock leaks in
case of failure in the lock upgrade path under VV_CROSSLOCK. In terms of
practical use, this impacts unionfs (and nullfs in a corner case).
Fixes: 80bd5ef070 ("vfs: factor out mount point traversal to a dedicated routine")
MFC after: 3 days
MFC to: stable/14 releng/14.0
Sponsored by: The FreeBSD Foundation
Reviewed by: mjg
[mjg: massaged the commit message a little bit]
Differential Revision: https://reviews.freebsd.org/D41731
We could hit these when executing code marked as using BTI but jumps
to a non-branch target instruction.
Sponsored by: Arm Ltd
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39450
We have export the CPUID registers since 2018 but never set the
HWCAP_CPUID flag to tell userspace it could use them. Fix this by
setting it.
Sponsored by: Arm Ltd
It may be needed when it's updated so is best to keep in sync with the
assembly files.
Reviewed by: emaste
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41938
Adjust the lastcomm command to output timestamps with a precision of
seconds.
Reported by: Dr. Andreas Longwitz
Reviewed by: emaste
Relnotes: Yes
Sponsored by: DSS Gmbh
Pull Request: https://github.com/freebsd/freebsd-src/pull/802
For protocols that use netlink (generic and route for now), the unint
handler seems to have forgotten to call unregister, which will cause
the assertion the next time the module is loaded.
This patch adds unregister call to netlink_unregister_proto() for those
handlers to avoid bad things happen.
Reviewed-by: melifaro
Fixes: 7e5bf68495 ("netlink: add netlink support")
Pull-request: https://github.com/freebsd/freebsd-src/pull/781
Signed-off-by: Lin Ma <linma@zju.edu.cn>
7f7ef494f1 introduced a compile time option PF_DEFAULT_TO_DROP to make
the pf(4) default rule to drop. While this change exposes a vnet loader
tunable 'net.pf.default_to_drop' so that users can change the default
rule without re-compiling the pf(4) module.
This change is similiar to that for IPFW [1].
1. 5f17ebf94d Convert IPFW_DEFAULT_TO_ACCEPT into a loader tunable 'net.inet.ip.fw.default_to_accept'
Reviewed by: #network, kp
MFC after: 2 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D39866
For a service that sets an rcvar, there is a check whether it has been
enabled before the actual command is executed. If the check fails, one
gets a message to enable it and the returned exit status is 0.
However, this is usually undesirable for the status command, which is
a) supposed to check whether the service is running anyway and
b) returns a non-zero exit code if that is not the case.
Thus, skip the check for the status command.
PR: 272282
Reviewed by: emaste
MFC after: 3 days
In order for the FreeBSD-specific sysctl (which gives us a full list of
PCI device IDs/names/and firmware prefixes) to be in the proper namespace
add a LINUXKPI_PARAM_PREFIX definition to the file as well.
The sysctl can now be used as:
sysctl -n compat.linuxkpi.iwlwifi_pci_ids_name
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Update the man pages for iwlwifi.4 and iwlwififw.4 to list the
current state of devices supported and which firmware they need.
The list is automatically generated based on a sysctl added to the
iwlwifi driver (so this is the driver's view). The reader should
not be surprised by the larger number of any/any/any/any entries
for PCI vendor and devices in the firmware table for which other
matching logic happens. The reader should also not be confused
about "TBD" (to be done) entries for chipsets which the driver
already supports but have no (public) product yet.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Some of these entries are due to commits with author email copied from
Phabricator's mangled userid and some are just from changes to email
addresses over time.
Reviewed by: Mina Galić
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41931
We have multiple problems with scanning currently, one being that
an initial scan restarts itself and we are unable to start another
scan. wpa_supplicant in that case never shows scan results.
Starting wpa_cli you may see: <3>CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
messages.
Add two extra calls to ieee80211_notify_scan_done() at the end of scans
(before possible restarts). That will get wpa_supplicant to get
scan results and possibly start associating to a BSSID and get us out
of scan. This is kind-of a bandaid but on short notice may help to
improve the situation for some.
Based on analysis by: enweiwu
Submitted by: enweiwu (initial version)
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Tested by: cy, (others I cannot find email/PR for anymore)
Reviewed by: cy
Differential Revision: https://reviews.freebsd.org/D38661
While the build-breaking changes were only in the window of
the two commits, 3e1f5cc9a81a..9af1bba44e1c, further updates
restored some functionality as well. Now that we are done,
add iwlwifi back to the build.
This reverts commit b75d1ce6c1.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Setup more link_conf/deflink fields for vif/sta as are needed to allow
us to work with the KPI bits in a non-MLO configuration.
In lkpi_sta_scan_to_auth() set the bss_conf values before calling into
the driver for chanctx setup/updates as certain values (e.g., beacon_int)
need to be set before; we still call the MO function for the updates
after to keep the expected workflow.
Deal with the (to be dealt with otherwise later) net80211 ni swaps and
update the addresses on the deflink as well as otherwise firmware will
hit asserts or things will not work (e.g. indicating the peer is us).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
When adding a VAP (vif) initialize its tx queue parameters calling
mo_conf_tx().
I could not spot net80211 providing some of the values needed before
having a node so currrently we use hard-coded values with a comment
with a reference on how to properly calculate the values in the future
(e.g., in case of 11b or other cases).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Driven by net80211 we may call mac80211 ops stop() and start() mostly
when toggling a first VAP. While this is FreeBSD behaviour the firmware
based LinuxKPI drivers seem to possibly clear state in the case of stop()
triggering further errors down the line.
We call mo_start() when starting the VAP and mo_stop() when destroying
it now only. In the future (e.g., in multi-VAP setups) we may need to
re-address some of this so keep the code under #ifdef.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
With past commits new structures were added. Now switch over some
bss_conf fields into vif->cfg where they got moved to and remove the
old fields. This allows drivers to find the expected values in the
now expected places and work better.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
With MLO and multi-link setups if avail we want to call link_info_changed
whereas for legacy drivers we still need to call bss_info_changed.
While we currently do not (yet) support multi-link configurations
we still need to drive the correct commands to satisfy firmware
requirements.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
In [1] we updated the KPI for various mac80211 ops functions to deal
with MLD code. Newer iwlwifi driver and firmware supports these
functions so we need to pass non-dummy (0, NULL) arguments to them.
Start extending the internel MO functions by these arguments and
pass down values from LinuxKPI 802.11 code.
It is assumed that further work will be needed to have all the
right fields available to at least work in the lgeacy way of a
single link.
Sponsored by: The FreeBSD Foundation
Improves: 549198b1ab (update mac80211 KPI) [1]
MFC after: 3 days
This is a combined versions of updates of the iwlwifi driver based
on wireless-testing
(wt-2023-05-11) 711dca0ca3d77414f8f346e564e9c8640147f40d (after v6.4-rc1).
(wt-2023-06-09) 7bd20e011626ccc3ad53e57873452b1716fcfaaa (after v6.4-rc5).
(wt-2023-07-24) 62e409149b62a285e89018e49b2e115757fb9022 (after v6.5-rc3).
Sponsored by: The FreeBSD Foundation
MFC after: 20 days
Unconditionally enable the changes for newer drivers, as needed by
iwlwifi (and others).
Sposnored by: The FreeBSD Foundation
MFC after: 3 days
X-Note: breaks build until iwlwifi update (next hash)
Disconnect iwlwifi from the build for a few commits which, due to
incompatible LinuxKPI 802.11 changes would break the build for a
revision. It will be re-enabled "instantly".
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
It's possible for misuse of cdev KPIs or for bugs in devfs itself to
result in e.g. a cdev object's container being freed while still on the
global list used to populate each devfs mount; see PR 273418 for a
recent example.
Since a node may be marked inactive well before it is reaped from the
list, add a new flag solely to track list membership, and employ it in
some basic list integrity assertions to catch bad actors.
Discussed with: kib, mjg
MFC after: 1 week
Warner Losh