New sysctl to disable NOMATCH until devmatch runs
Introduce hw.bus.devctl_nomatch_enabled and use it to suppress NOMATCH
until devmatch runs
There's a lot of NOMATCH events generated at boot. We also run devmatch
once during early boot to load unmatched devices. To avoid redundant
work, don't start generating NOMATCH events until after devmatch runs.
Set hw.bus.devctl_nomatch_enabled=1 just before we run devmatch. The
kernel will suppress NOMATCH events until this is set to true.
This saves about 170ms from the boot on aarch64 running atop Apple
M-series processors and the VMWare Fusion hypervisor.
Reviewed by: imp, cperciva
MFC after: 3 days
Sponsored by: Google Summer of Code
Pull Request: https://github.com/freebsd/freebsd-src/pull/1213
Address module reproducibility issues
Use .PATH & bare filename. This prevents the real source path from
being included in the built object, which improves reproducibility.
Signed-off-by: Dan McGregor <dan.mcgregor at usask.ca>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1211
arp.8: don't document a syntax that doesn't exist
The arp.8 manpage documents 'arp -d <addr> pub', but the 'pub' flag is
not accepted by the arp command. Remove this incorrect documentation.
Reviewed by: imp, gleb, mp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1215
intr/x86: replace use of vector in interface with intsrc
Several x86 interrupt core functions were already operating on intsrc
structures. Now switch the remaining 3 to intsrc for consistency.
Swap the order of intr_add_handler()'s first two arguments. This
matches INTRNG and is more consistent with other functions in this
interface.
Differential Revision: https://reviews.freebsd.org/D35386
Reviewed by: imp, markj (previous version)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1126
sys: declare bit sets unsigned
Substantially reduce the number of signed/unsigned issues (warnings if
enabled). While these are presently disabled for FreeBSD, being able to
enable another warning would be good.
Differential Revision: https://reviews.freebsd.org/D32793
Reviewed by: imp, jhibbits
Pull Request: https://github.com/freebsd/freebsd-src/pull/1126
intrng: switch flag arguments to unsigned
The flag variables behind these are all unsigned. As such adjust the
declarations to match reality and reduce the number of mismatches.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1126
kern/intr: redeclare intr_setaffinity()'s third arg constant
This matches reality and allows removal of a __DECONST().
Fixes: 4c72d075a57 ("LinuxKPI: const argument to irq_set_affinity_hint()")
Fixes: 9b33b154b53 ("Add support to cpuset for binding hardware interrupts")
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1126
kern/intr: change ->ie_irq to unsigned
All architecture implementations actually want this to be unsigned.
INTRNG the equivalent is overtly unsigned. x86 and PowerPC merely avoid
the need to explicitly convert at several points.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1126
arm/pmu: remove passing trap frame as argument
While otherwise a handy potential approach, getting the trap frame via
the argument isn't documented and isn't supposed to be used. Adjust
pmu_intr() to instead use curthread->td_intr_frame, which is the proper
way.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1126
geli: add a read-only kern.geom.eli.use_uma_bytes sysctl
It reports the value of the g_eli_alloc_sz variable. Allocations of
this size or less will use UMA. Larger allocations will use malloc.
Since malloc is slower, it is useful for users to know this variable so
they can avoid such allocations. For example, ZFS users can set
vfs.zfs.vdev.aggregation_limit to this value.
Sponsored by: Axcient
Reviewed by: markj, imp
Differential Revision: https://reviews.freebsd.org/D44904
(cherry picked from commit 3acf3feaa8c5b15e820e86c1526c9a97fc5ad247)
sound: Rename oss_audioinfo->real_device to oss_audioinfo->legacy_device
The OSS manual now documents this field as "legacy_device".
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45138
sound: Add missing oss_mixerinfo devnode and legacy_device fields
They are missing from soundcard.h and are in fact used by some
applications, such as OSS' ossinfo(1):
http://manuals.opensound.com/developer/ossinfo.c.html
The new size for filler is chosen according to the most recent official
version of soundcard.h, which includes those 2 fields.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45137
sound: Fix oss_sysinfo->numcards
According to the OSS manual, oss_sysinfo->numcards holds the number of
detected audio devices in the system, while the current ncards variable,
whose value is assigned to oss_sysinfo->numcards, holds the number of
currently registered devices only.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: dev_submerge.ch, emaste
Differential Revision: https://reviews.freebsd.org/D45136
sound: Remove nmix variable from mixer_oss_mixerinfo()
nmix is used to compare against oss_mixerinfo->dev, which is a
user-supplied value to select the mixer device (if not -1, in which case
we'll select the default one) we want to fetch the information of. It is
also used to set oss_mixerinfo->dev in case it is -1.
However, nmix is at best redundant, since we have the loop counter
already (i), and confusing at worst.
For example, suppose a system with 3 mixer devices. We call
SNDCTL_MIXERINFO with oss_mixerinfo->dev=1, meaning we want to get
information for /dev/mixer1. Suppose /dev/mixer0 detaches while inside
the loop, so we'll hit the loop's "continue" case, and nmix won't get
incremented (i.e will stay 0 for now). At this point nmix counts 1
device less, so when it reaches 1, we'll be fetching /dev/mixer2's
information instead of /dev/mixer1's.
This is also true in case the mixer device disappears prior to the call
[10 lines not shown]
snd_hdsp(4): RME HDSP 9632 and HDSP 9652 sound card driver.
Add a sound(4) bridge device driver for the RME HDSP 9632 and HDSP 9652
sound cards. These cards require a nowadays rare PCI 32bit (not PCIe)
slot, but still see use due to their value and wealth of features.
The HDSP 9632 is mostly comparable to the newer HDSPe AIO, while the
HDSP 9652 is similar to the HDSPe RayDAT. These HDSPe PCIe cards are
supported by the snd_hdspe(4) driver which was taken as a starting point
for development of snd_hdsp(4).
Implementation is kept separately due to substantial differences in
hardware configuration and to allow easy removal in case PCI 32bit
support would be phased out in the future.
The snd_hdsp(4) kernel module is not enabled by default, and can be
loaded at runtime with kldload(8) or during boot via loader.conf(5).
Basic operation was tested with both cards, not including all optional
cable connectors and expansion boards. Features should be roughly on par
with the snd_hdspe(4) supported cards.
[3 lines not shown]
zfsd: Use vdev prop values for fault/degrade thresholds
ZED uses vdev props for setting disk fault/degrade thresholds, this
patch enables zfsd to use the same vdev props for these same tasks.
OpenZFS on Linux is using vdev props for ZED disk fault/degrade
thresholds. Originally the thresholds supported were for io and checksum
events and recently this was updated to process slow io events as
well, see
https://github.com/openzfs/zfs/commit/cbe882298e4ddc3917dfaf239eca475fe06d62d4
This patch enables us to use the same vdev props in zfsd as ZED uses.
After this patch is merged both OSs will use the same vdev props to set
retirement thresholds.
It's probably important to note that the threshold defaults are
different between OS. I've kept the existing defaults inside zfsd and
DID NOT match them to what ZED does.
[16 lines not shown]
fusefs: make the tests more robust to changes to maxphys
Remove assumptions in two test cases that maxphys won't be huge.
Reported by: kib
MFC after: 2 weeks
Sponsored by: Axcient
adduser: Fix confusion between `uclass` and `_class`.
This caused adduser to produce an invalid `pw(8)` command line. Due to
bugs in `pw(8)`, the command line was silently accepted and led to the
user being created, but locked out and with no home directory.
Also fix the default value for the “Another user?” prompt.
Fixes: 170d0882903e
MFC after: 3 days
Reviewed by: karels, allanjude
Differential Revision: https://reviews.freebsd.org/D45098
(cherry picked from commit 46c4e86ebf1819fc09084c8aa79423d96fcaad4a)
(cherry picked from commit e121845426c8d587491370432de0657099a22843)
Approved by: re (cperciva)
Update example from gcc6 to gcc13
We only "support" gcc12 and gcc13 for cross building, for some value of
"support". Update the example from gcc6 to gcc13.
Sponsored by: Netflix
sched: Simplify sched_lend_user_prio_cond()
If 'td_lend_user_pri' has the expected value, there is no need to check
the fields that sched_lend_user_prio() modifies, they either are already
good or soon will be ('td->td_lend_user_pri' has just been changed by
a concurrent update).
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44050
(cherry picked from commit aeff15b392e68f5f193fff3bb01728b965cacc3a)
Approved by: emaste (mentor)
PP mutexes: lock: Reduce 'umtx_lock' holding before taking the user lock
There is no need to have it for the priority check (that the thread
doesn't have a higher priority than the mutex's ceiling), and there's
also no need to take it if the thread doesn't have privileges to set its
priority to the mutex's ceiling.
While here, turn 'su' into a 'bool' and compute the internal priority
corresponding to the mutex's ceiling once and for all, putting it in new
'new_pri'.
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44045
(cherry picked from commit 39e4665c9694b9f9b07d1cfa85befc288cabe906)
Approved by: emaste (mentor)
PP mutexes: lock: Check if priority is too high against base one
Doing this instead of using the current (user) priority, which includes
current lendings, prevents gratuitous failures for threads involved in
multiple locking groups, where each group is defined as the threads that
can lock a particular PP or PI mutex. No deadlock can occur in this
case. Indeed, if a thread holds such a lock A giving it a higher
priority than the ceiling of some other lock B that is PP, and B is
acquired by another thread, effectively the latter may not be able to
run but this situation can only last until the first thread releases A,
which it will do eventually.
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44044
(cherry picked from commit 9ac3ac9ece6269365ac314fa5fdb484e96d4a32e)
[2 lines not shown]
PP mutexes: unlock: Reset inherited prio regardless of privileges
'uq_inherited_pri' contains the current priority inherited from Priority
Protection mutexes. If -1 is passed through 'm_ceilings[1]', meaning
that there are no such mutexes held anymore, this must be reflected into
it by setting it to PRI_MAX, regardless of whether the thread has
privilege to set realtime priorities (PRI_MAX is also obviously not
a realtime priority level). By contrast, it shall not be updated and
the computed 'new_inherited_pri' shall stay unused if the thread doesn't
have the ability to set a realtime priority, possibly keeping an older
such priority acquired previously.
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43984
(cherry picked from commit 1df8700aa6cff7c759e90f7e507de4b8714435a4)
[2 lines not shown]
sched: Simplify sched_lend_user_prio_cond()
If 'td_lend_user_pri' has the expected value, there is no need to check
the fields that sched_lend_user_prio() modifies, they either are already
good or soon will be ('td->td_lend_user_pri' has just been changed by
a concurrent update).
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44050
(cherry picked from commit aeff15b392e68f5f193fff3bb01728b965cacc3a)
Approved by: emaste (mentor)
PP mutexes: lock: Check if priority is too high against base one
Doing this instead of using the current (user) priority, which includes
current lendings, prevents gratuitous failures for threads involved in
multiple locking groups, where each group is defined as the threads that
can lock a particular PP or PI mutex. No deadlock can occur in this
case. Indeed, if a thread holds such a lock A giving it a higher
priority than the ceiling of some other lock B that is PP, and B is
acquired by another thread, effectively the latter may not be able to
run but this situation can only last until the first thread releases A,
which it will do eventually.
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44044
(cherry picked from commit 9ac3ac9ece6269365ac314fa5fdb484e96d4a32e)
[2 lines not shown]
