After two years, add the initial man page and hook Realteks rtw89
driver up to the build for more people to test given successful
reports.
devd.conf is already providing support based on the rtw<n+> regex.
The driver uses the LinuxKPI compat layer.
Firmware is provided by ports: net/wifi-firmware-rtw89-kmod or
one of the flavours. People are advised to used fwget(8) to
automatically install the correct firmware for their chipset.
Please note that for the moment the driver requires a tunable to
be set in loader.conf: compat.linuxkpi.skb.mem_limit=1
Many thanks to everyone who in the last two years helped testing,
debugged, submitted patches to get the driver to this stage where
initial functionality seems working.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 310c31d3f04ef9d3ebe598fd076d017a48d0ca0d)
On FreeBSDs we locally set bsddriver.name in struct pci_driver to have
the same name for all chipsets. This helps with, e.g., device
enumeration. For two chipsets the manual entry was missing.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit ce15215befa1022d9a20ec15bdb0739dbe55f10f)
rtw89 TX path was faulting in linuxkpi_ieee80211_next_txq() due to a
"double scheduling" check in linuxkpI_ieee80211_schedule_txq() being
incorrect:
the next pointer may be NULL there if the element is the last in the
tailq, so correctly check tqe_prev. Without the fix we may have queued
the same element to the tailq twice, and because it was the last element
and had a NULL tqe_next, that NULL value would get propogated into
another node's tqe_prev on removal, and other such nastiness.
With this rtw89 no longer panics.
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D47006
(cherry picked from commit 41b746e05231b44c87f3a3087a7fe29966af6d0f)
Use proper format specifiers (with casts) and don't redefine flags.
Fixes: c7b1e980ae16
Sponsored by: Netflix
(cherry picked from commit 3a3afbec3860b0eb4178b63713ca12bd223b585a)
Files loaded "-t firmware" (or module_type="firmware"). They are
registered with the firmware system using the full path to the file.
There's only one firmware per file, and it is the entire file. We do an
extra firmware_get() on any firmware we find here to prevent them from
ever being unloaded (we can't handle that case sanely).
Sponsored by: Netflix
Reviewed by: tsoome, jhb
Differential Revision: https://reviews.freebsd.org/D43522
(cherry picked from commit 479905a1ed26c54ef29cdff65cf25f7feade654b)
When we can't find a .ko module to satisfy the firmware request, try
harder by looking for a file to read in directly. We compose this file's
name by appending the imagename parameter to the firmware path
(currently hard-wired to be /boot/firmware, future plans are for a
path). Allow this file to be unloaded when firmware_put() releases the
last reference, but we don't need to do the indirection and dance we
need to do when unloading the .ko that will unregister the firmware.
Sponsored by: Netflix
Reviewed by: manu, jhb
Differential Revision: https://reviews.freebsd.org/D43555
(cherry picked from commit c7b1e980ae16c094e64f318ad2feb98e17bd8f2f)
Sometimes, especially with older firmware, mps(4) would have trouble
initializing the card in one of these two steps. Add in a retry after a
short delay. Sean Bruno and Stephen McConnell thought this was OK in the
bug discussions, but never committed it. Steve indicated the delay
might not be necessary, but the OP clearly needed to make it longer to
make things work. I've kept the delay, and added the suggested comment.
Ported the iocfacts part to mpr as well, since we see similar errors
about once every month or two over a few thousand controllers at
work. We've not seen it with IOC_INIT as far back as I can query the
error log database, so I didn't port that forward. We'll see if this
helps, but won't know for sure until next year (so I'm committing it now
since it won't hurt and might help). We usually see this failure in
connection with complicated recovery operations with a drive that's
failing, though, at least in the last year's worth of failures. It's
not clear this is the same as OP or not.
PR: 212841
Sponsored by: Netflix
Co-authored-by: imp
(cherry picked from commit c0e0e530ced057502f51d7a6086857305e08fae0)
Take advantage of a nearby 2-byte hole to avoid growing the struct.
This way, only the offsets of "flags" and "pg_color" change. Bump
__FreeBSD_version since some out-of-tree kernel modules may access these
fields, though I haven't found any examples so far.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D35905
(cherry picked from commit 9d52823bf1dfac237e58b5208299aaa5e2df42e9)
Make sure that the compiler loads the initial value value only once.
Because atomic_fcmpset is used to load the value for subsequent
iterations, this is probably not needed, but we should not rely on that.
I verified that code generated for an amd64 GENERIC kernel does not
change.
Reviewed by: dougm, alc, kib
Tested by: pho
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D46943
(cherry picked from commit d8b32da2354d2fd72ae017fd63affa3684786e1f)
The units of the size reported in the 'sectors' xenbus node is always 512b,
regardless of the value of the 'sector-size' node. The sector offsets in
the ring requests are also always based on 512b sectors, regardless of the
'sector-size' reported in xenbus.
Fix both blkfront and blkback to assume 512b sectors in the required fields.
The blkif.h public header has been recently updated in upstream Xen repository
to fix the regressions in the specification introduced by later modifications,
and clarify the base units of xenstore and shared ring fields.
PR: 280884
Reported by: Christian Kujau
MFC after: 1 week
Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D46756
(cherry picked from commit e7fe85643735ffdcf18ebef81343eaac9b8d2584)
It is declared as static. Make the definition consistent with the
declaration.
This follows 7ff9ae90f0 and partially reverts 09f6ff4f1a.
Reviewed by: erj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D46185
(cherry picked from commit 8161000892830ee52bc8048be91b40cdad25fea8)
This reverts commit 9792c7d3eb.
The email thread "panic: nfsv4root ref cnt cpuid=1"
on freebsd-fs@freebsd.org descibes
crashes that occurred for a NFSv4.1 client mount
using "oneopenown" where the same file is re-opened
many times by different processes.
The crashes appear to have been caused by the use
of the Lookup+Open RPC (which only happens for
mounts using the "oneopenown" option).
There appears to be a race between closure of the
open and the open acquired by the Lookup+Open RPC.
Since Lookup+Open RPCs are only an optimization
and can only be done for "oneopenown" at this time,
this patch reverts enabling of them.
It may be possible to fix the code so that
Lookup+Open works reliably, so the code is left
in place (although it will never be executed) for now.
Reported by: J David <j.david.lists@gmail.com>
(cherry picked from commit 6df05714da160a8ac3e27ee34ff903bd0e760002)
nfsrv_freeopen() was being called after the mutex
lock was released, making it possible for other
kernel threads to change the lists while nfsrv_freeopen()
took the nfsstateid out of the lists.
This patch moves the code around
"if (nfsrv_freeopen(stp, vp, 1 p) == 0) {"
into nfsrv_freeopen(), so that it can remove the nfsstateid
structure from all lists before unlocking the mutex.
This should avoid any race between CLOSE and other nfsd threads
updating the NFSv4 state.
The patch does not affect semantics when vfs.nfsd.enable_locallocks=0.
PR: 280978
Tested by: Matthew L. Dailey <matthew.l.dailey@dartmouth.edu>
(cherry picked from commit eb345e05ac6602eeef0c33fce9025bbc8ec44d0f)
The virtio_scsi device allows a VM guest to directly send SCSI commands
(ctsio->cdb array) to the kernel driver exposed on /dev/cam/ctl
(ctl.ko).
All kernel commands accessible from the guest are defined by
ctl_cmd_table.
The command ctl_persistent_reserve_out (cdb[0]=0x5F and cbd[1]=0) allows
the caller to call malloc() with an arbitrary size (uint32_t). This can
be used by the guest to overload the kernel memory (DOS attack).
Reported by: Synacktiv
Reviewed by: asomers
Security: HYP-08
Sponsored by: The Alpha-Omega Project
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46044
(cherry picked from commit 64b0f52be2c9d7bcecebfeef393f8ec56cb85f47)
If we fail to change the vlan id we have to undo the removal (and vlan id
change) in the error path. Otherwise we'll have removed the vlan object from the
hash table, and have the wrong vlan id as well. Subsequent modification attempts
will then try to remove an entry which doesn't exist, and panic.
Undo the vlan id modification if the insertion in the hash table fails, and
re-insert it under the original vlan id.
PR: 279195
Reviewed by: zlei
MFC atfer: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D45285
(cherry picked from commit bdd12889eaa64032b3d09ef47e9a6f7081863378)
Current cleanup code assumes that all the fields are allocated and/or setup by
the time cleanup is called, but this is not always true: a failure in mid-setup
of the device will cause the functions to be called with possibly uninitialized
fields.
Fix the functions to cope with such sate, while also attempting to make the
cleanup idempotent.
Finally fix an error path during setup that would not mark the device as
closed, and hence prevents the kernel from finishing booting.
Fixes: 96375eac94 ("xen-netfront: add multiqueue support")
Sponsored by: Citrix Systems R&D
(cherry picked from commit 318bbb6d5a1eae77eb5dc687bcc63c0f99558e21)
The current sizing of the array used to store grant table frames is broken, as
the calculation:
max_nr_glist_frames = (boot_max_nr_grant_frames *
GREFS_PER_GRANT_FRAME /
(PAGE_SIZE / sizeof(grant_ref_t)));
Is plain bogus, for once grant_ref_t is the type of the grant reference, but
not the entry used to store such references in the grant frames. But even if
the above calculation is switched to use grant_entry_v1_t, it would end up as:
max_nr_glist_frames = (boot_max_nr_grant_frames *
(PAGE_SIZE / sizeof(grant_entry_v1_t)) /
(PAGE_SIZE / sizeof(grant_entry_v1_t)));
Which is pointless (note GREFS_PER_GRANT_FRAME has been expanded to (PAGE_SIZE
/ sizeof(grant_entry_v1_t))).
Just use boot_max_nr_grant_frames directly to size the grant table frames
array.
Fixes: 30d1eefe39 ("Import OS interfaces to Xen services.")
Sponsored by: Citrix Systems R&D
(cherry picked from commit 1a12f0aea81b57d0dd2374047b8f4c97a037a8df)
Do not clear knotes from the TTY until it gets dealloc'ed, unless the
TTY is being revoked, in that case delete the knotes when closed is
called on the TTY.
When knotes are cleared from a knlist, those knotes become detached from
the knlist. And when an event is triggered on a detached knote there
isn't an associated knlist and therefore no lock will be taken when the
event is triggered.
This becomes a problem when a detached knote is triggered on a TTY since
the mutex for a TTY is also used as the lock for its knlists. This
scenario ends up calling the TTY event handlers without the TTY lock
being held and tripping on asserts in the event handlers.
PR: 272151
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D41605
(cherry picked from commit acd5638e268a6706f6b7ad84947a8425e8d51ef7)
When processing an RPC response that did not include any Owner
attribute, nfsv4_loadattr would return na_uid and na_gid uninitialized.
The uninitialized values could then make their way into the NFS
attribute cache via nfscl_loadattrcache.
PR: 281279
Reported by: KMSAN
Reviewed by: rmacklem
Sponsored by: Axcient
(cherry picked from commit 44328abfb7aca8150b07b83ff502c9185677e3fb)
If the FUSE_GETATTR issued to query a file's size during
fuse_vnop_deallocate failed for any reason, then fuse_vnop_deallocate
would attempt to destroy an uninitialized fuse_dispatcher struct, with a
crash the likely result. This bug only affects FUSE file systems that
implement FUSE_FALLOCATE, and is unlikely to be seen on those that don't
disable attribute caching.
Reported by: Coverity Scan
CID: 1505308
(cherry picked from commit f93a50d69df2e996ff1d4f793d0dcb9de655ebdc)
Native Linux implementation sets this as a maximum between 1 and
ht/vht/eht rx SS'es, FreeBSD does the same, but uses 0 as a minimum,
which leads setting it to 0 if we're not in ht/vht case.
This 0 was breaking rtw89 driver, when it was trying to determine
SS number by subtracting 1 from rx_nss and passing the value to the
hardware.
After this patch rtw89 association and simple ping work reliably,
but more work is needed to make the driver robust with heavy traffic
(iperf3) and being long idle.
Reviewed by: bz
Sponsored by: Future Crew LLC
Differential Revision: https://reviews.freebsd.org/D46528
(cherry picked from commit f5a58c2da23930ee4870f2eb54788f4669b9aa33)
Move some ieee8022_{is,has,get}_... functions working on header fields
from mac80211.h to ieee80211.h to avoid problems with #includes.
No functional changes.
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 0b325167f60def621536632460caf68e2fab4fb8)
Ignoring page_pools with the few needed adjustments and ignoring 7622
mt7615 seems to build as well. Add it so once we can connect it to
the build people can start testing and debugging.
(The actual work was done on a newer version of the mt76 drivers but
it seems the to-build-changes equally apply here already).
Requested by: Radu-Cristian Fotescu (freebsd-wireless, 2024-07-31)
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 7728586800bd5bb4655cff6d661133ed10cc2ff7)
Add IDs for Realtek, Atheros (QCA), and Mediatek.
While I am not sure we'll ever support the ath10k and possibly mt76
SDIO devices, rtw88 ones can be found with SoCs (e.g. r2s-plus) and
are actively being worked on.
Update Broadcom/Cypress entries.
Sponsored by: The FreeBSD Foundation
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D46460
(cherry picked from commit a800b5bcd1b6638530d3a0759b17cd8d93b7e7ca)
Some of the defined names are not the direct 1:1 mapping with vendor
and device names used by Linux device drivers.
Introduce a p(roduct)alias so we can map the one device entry I came
across without much extra hassle and generate a name device drivers
know about:
palias BROADCOM_CYPRESS_43439 CYPRESS_43439
Sponsored by: The FreeBSD Foundation
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D46455
(cherry picked from commit b4ef1b1be753952a4aafa505817164624f712c37)
Generate defined names which match the ones in the Linux drivers (a lot more);
given we are likely to have drivers only based on those one way or another
there is absolutely no reason to fight over differently generated names
for device and vendor IDs.
Sponsored by: The FreeBSD Foundation
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D46300
(cherry picked from commit 51cb6f5244575e1abc008598e90eb35452ffbcac)
The input file used to have a $FreeBSD$ tag on the first line and we
recorded that in the generated files to know which versions they were
based on. With the removal of $FreeBSD$ the logic was not quite
correct anymore; fix that to generate proper header files again.
Sponsored by: The FreeBSD Foundation
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D46300
(cherry picked from commit 499c337781bf8df7f97f612b93427b3f53dfd8bb)
The new sys/conf/std.debug contains the list of debugging options
enabled by default in -CURRENT, so they don't need to be listed
individually in every kernel config.
Introduce *-DEBUG variants of the major kernel configs.
(cherry picked and modified from commit 4f8f9d708e6a4143f3b178bfab10d0a9b75ba2fe)
Reviewed by: markj, imp, olce (previous version)
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D46871
