Align the comment for if_t with the rest and remove the declaration of
t4_l2t_set_switching, which was removed in 061bbaf7e7.
No functional change.
MFC after: 3 days
Sponsored by: Chelsio Communications
This got missed as it's not built in a normal tinderbox build.
This fixes building arm.armv7 ARMADAXP (marked NO_UNIVERSE).
Fixes: 9dbf5b0e68 ("new-bus: Remove the 'rid' and 'type' arguments from BUS_RELEASE_RESOURCE")
Commit 9a7bf07ccd from 2016 introduced a workaround for some broken
BIOSes that specified active-lo instead of active-hi polarity for ISA
IRQs for UARTs. The workaround assumed that edge-sensitive ISA IRQs
on x86 should always be active-hi. However, some recent AMD systems
actually use active-lo edge-sensitive ISA IRQs (and not just for
UARTs, but also for the keyboard and PS/2 mouse devices) and the
override causes interrupts to be dropped resulting in boot time hangs,
non-working keyboards, etc.
Add a hw.acpi.override_isa_irq_polarity tunable (readable as a sysctl
post-boot) to control this quirk. It can be set to 1 to force enable
the override and 0 to disable it. The log of original message
mentions an Intel motherboard as the sample case, so default the
tunable to 1 on systems with an Intel CPU and 0 otherwise.
Special thanks to Matthias Lanter <freebsd@lanter-it.ch> for tracking
down boot time issues on recent AMD systems to mismatched interrupt
polarity.
PR: 270707
Reported by: aixdroix_OSS@protonmail.com, Michael Dexter
Reported by: mfw_burn@pm.me, Hannes Hfauswedell <h2+fbsdports@fsfe.org>
Reported by: Matthias Lanter <freebsd@lanter-it.ch>
Reported by: William Bulley <web@umich.edu>
Reviewed by: imp, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D45554
The way that net80211 and drivers are checking for the /type/ of key
is to check if it's in the vap WEP key array and if so, it's a group
key. If not, it's a unicast key.
That's not only kind of terrible, but it's also going to be
problematic with future 802.11 support (for multiple unicast keys
and IGTK keys for management frame protection.)
So as part of this, remove the places where this is done and
instead use a pair inline functions - ieee80211_is_key_global() and
ieee80211_is_key_unicast(). They currenly still use the same logic
but the drivers and net80211 stack isn't doing it itself.
There are still open questions about why keys are not being
correctly tagged as GROUP, GTK, PTK, etc. That will be investigated
and addressed in follow-up work as a pre-cursor to MFP, IGTK, etc.
as mentioned above.
Testing:
* iwn, rtwn - STA mode
Differential Revision: https://reviews.freebsd.org/D45516
Previously, when transmitting short runs of packets via cxgbe_nm_tx(),
we would wait until a large number of packets were buffered before
scheduling a task to clean transmit buffers.
Obtained from: np
If loader(8) gives use a splash screen to use using the MODINFOMD_SPLASH
type, use it if RB_MUTE is set to "YES".
By design only argb data will be displayed.
Differential Revision: https://reviews.freebsd.org/D45931
Reviewed by: imp, tsoome
Sponsored by: Beckhoff Automation GmbH & Co. KG
This blit an ARGB image on the dedicated vd.
This also adds vt_fb_bitblt_argb which will works for most of the vt backends
Differential Revision: https://reviews.freebsd.org/D45929
Reviewed by: tsoome
Sponsored by: Beckhoff Automation GmbH & Co. KG
This fixes a panic when multiple VIs are configured on an interface and
only the non-primary VI is up at the time of driver detach. The problem
was that the driver would queue a link state change notification for an
interface about to be freed.
To reproduce the panic, add "hw.cxgbe.num_vis=2" to loader.conf and
# kldload if_cxgbe
# ifconfig vcc0 up
# devctl detach t6nex0
trap 0x9, rip = 0xffffffff8107db70, rsp = 0xfffffe0055263d60, rbp = 0xfffffe0055263dd0
taskqueue_run_locked() at taskqueue_run_locked+0x2a0/frame 0xfffffe0055263dd0
taskqueue_run() at taskqueue_run+0x72/frame 0xfffffe0055263df0
taskqueue_swi_run() at taskqueue_swi_run+0x18/frame 0xfffffe0055263e10
intr_event_execute_handlers() at intr_event_execute_handlers+0x249/frame 0xfffffe0055263e50
ithread_execute_handlers() at ithread_execute_handlers+0x9e/frame 0xfffffe0055263e70
Reviewed by: jhb
MFC after: 1 week
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D45864
- Group the request header and I/O buffer in one structure, rather than
assuming that both request structures have the same size.
- Pass a pointer to the whole structure to urndis_ctrl_query() and
urndis_ctrl_set() rather than just the header. Otherwise, on CHERI
platforms, these functions violate subobject bounds since they modify
the buffer following the header.
While here, there is no apparent reason for the request structure used
in urndis_attach() to be allocated statically. Change it so that it's
allocated on the stack.
No functional change intended.
Reviewed by: jhb
MFC after: 2 weeks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D45866
This test here appears to be clamping the start and stop values to a
minimum and maximum. But it looks like one of these lines may have been
copied incorrectly.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1317
On read error, we would return -1, but not handle it, causing a zero
size malloc of value, and then we wouldd unconditionally write
value[-1 + 1] = '\0'. This should be harmless in terms of buffer
overflow because we should get a minimum non-zero size allocation from
malloc, but it also effectively swallowed the error.
Reported by: GCC -Wstringop-overflow
Reviewed by: kib, se
Differential Revision: https://reviews.freebsd.org/D45895
When the module is loaded on a system running on qemu/kvm the "modern"
virtio infrastructure is used and virtio_read_device_config() will end
up calling vtpci_modern_read_dev_config(). This function cannot read
values of arbitrary sizes and will panic if the p9fs mount tag size is
not supported by it.
Use virtio_read_device_config_array() instead. It was tested on both
bhyve and qemu/kvm.
PR: 280098
Co-authored-by: Mark Peek <mp@FreeBSD.org>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1320
In sndstat_build_sound4_nvlist(), if we have INVARIANTS or
SND_DIAGNOSTIC enabled, we will hit a lock assertion panic when we call
CHN_GETVOLUME(). Also lock the channel in the sndstat_prepare_pcm() loop
for good measure.
Fixes: bbca3a75bb ("sound: Include sound(4) channel information in sndstat nvlist")
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45898
If the channel list is empty, min_rate and min_channels will be INT_MAX.
Instead, assign them to 0, like we do in sndstat_get_caps().
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45876
The current implementation of sndstat_get_caps() does not work properly
when VCHANs are enabled, as it skips all information about physical
channels, and also assigns the min/max rates and channels to same
values, which is usually not the case. A device either supports any
sample rate within the [feeder_rate_min, feeder_rate_max] range, or
[hw_rate_min, hw_rate_max] range when the device is opened in exclusive
or bitperfect mode. The number of channels can also vary and is not
always the same for both min and max.
Refactor the whole function to resemble the way we handle fetching of
these values in dsp_oss_audioinfo() and dsp_oss_engineinfo().
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45872
Since we allow feeding of any rate within the [feeder_rate_min,
feeder_rate_max] range, report this as the min/max rate as well. Only
exceptions are when we the device is opened in exclusive or bitperfect
mode.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45862
midistat_lock is used outside midi/midi.c as well, so implement lock,
unlock and lockassert functions in order not to expose the lock in the
header file.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D45857
No reason to have this as a macro.
While here, change the second case to an "else if" as there is no reason
to check it if the open flags are invalid.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D45776
If we are in simplex mode, make sure we do not open in both directions
(read/write) and also that we do not open in a direction opposite of
what is already opened. For example, if the device is already doing
playback, we cannot open the device for recording at the same time, and
vice-versa.
While here, remove dsp_cdevpriv->simplex as it's no longer needed.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45835
Remove all special handling for SIMPLEX, since we can just fetch the
channel directly.
While here:
- Get rid of a no-op getchns() call in dsp_ioctl().
- Rename getchns() to dsp_lock_chans(), and relchns() to
dsp_unlock_chans().
- Simplify DSP_FIXUP_ERROR(), as we do not longer assign SD_F_PRIO*
flags to the softc.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45775
No good reason to have this. It only makes things harder to read.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D45773
This information is also printed to dmesg(8) on attach.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D45771
Opening /dev/sequencer after a clean reboot yields:
lock order reversal: (sleepable after non-sleepable)
1st 0xfffffe004a2c2c08 seqflq (seqflq, sleep mutex) @ /mnt/src/sys/dev/sound/midi/sequencer.c:754
2nd 0xffffffff84197ed8 midistat lock (midistat lock, sx) @ /mnt/src/sys/dev/sound/midi/midi.c:1478
lock order seqflq -> midistat lock attempted at:
0xffffffff811c9029 at witness_checkorder+0x12b9
0xffffffff810f18a7 at _sx_xlock+0xf7
0xffffffff8417f992 at midimapper_open+0x22
0xffffffff84182770 at mseq_open+0xf0
0xffffffff80e3380f at devfs_open+0x30f
0xffffffff81b8b4b7 at VOP_OPEN_APV+0x57
0xffffffff812da1e7 at vn_open_vnode+0x397
0xffffffff812d96b3 at vn_open_cred+0xb23
0xffffffff812c2c6b at openatfp+0x52b
0xffffffff812c2711 at sys_openat+0x81
0xffffffff84110579 at filemon_wrapper_openat+0x19
0xffffffff81a223ae at amd64_syscall+0x39e
0xffffffff819dd0eb at fast_syscall_common+0xf8
Expose midistat_lock to midi/midi.c so that we can acquire the lock from
mseq_open() before we lock seq_lock, and introduce _locked variants of
midimapper_open() and midimapper_fetch_synth().
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, emaste
Differential Revision: https://reviews.freebsd.org/D45770
The snd_sb16 driver was removed in 716924cb48 ("Retire snd_sbc ISA
sound card driver").
While here, simplify sample rate assignment a bit.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, markj, emaste
Differential Revision: https://reviews.freebsd.org/D45662
Currently, we are skipping physical channels when servicing
SNDCTL_AUDIOINFO, and VCHANs when servicing SNDCTL_AUDIOINFO_EX.
However, if we call SNDCTL_AUDIOINFO with VCHANs disabled, we'll
eventually skip all channels, resulting in some of oss_audioinfo's
fields containing wrong information (e.g min/max_channels).
Fix this by adding an exception to SNDCTL_AUDIOINFO not to skip physical
channels when VCHANs are disabled.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch, emaste
Differential Revision: https://reviews.freebsd.org/D45722
vtblk_poll_request() is used for kernel dumps and for fetching the block
device's identifier string during device probing. In the latter case,
it was not calling bus_dmamap_sync() after completing the I/O, but this
is required in general.
Thus:
- Factor out per-request code from vtblk_queue_completed().
- Use it in vtblk_poll_request() once virtqueue_poll() finishes.
- While here, assert that virtqueue_poll() returns the request that we
expect.
Reported by: KMSAN
Fixes: 782105f7c8 ("vtblk: Use busdma")
Reviewed by: cperciva, imp
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D45665
Most of these sysctls don't call sbuf_* while holding any locks. Of
the ones that do hold locks, all but one can be fixed to drop the lock
before calling sbuf_*.
Reviewed by: np
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D45186
Change 4787572d05 made if_alloc_domain() never fail, then also do the
wrappers if_alloc(), if_alloc_dev(), and if_gethandle().
No functional change intended.
Reviewed by: kp, imp, glebius, stevek
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D45740
Since that commit ahci(4), siis(4) and mvs(4) drivers ended up
using wrong command to fetch error information for NCQ commands.
Since ATA errors are not very informative to begin with, the only
noticeable effect is a lack of retries on those errors by CAM.
MFC after: 1 week
PR: 279978
rk_i2c_send_stop is modified so that it sends a stop condition, like it
always did, if there is no IIC_M_NOSTOP flag.
But if the flag is set then the function completely resets the control
register and sets the driver state to transfer completed.
Something like this was previously done for a write with IIC_M_NOSTOP.
Now it is done for a read with IIC_M_NOSTOP as well.
Linux code says that the hardware does not support the repeated start
condition and the documentation, indeed, does not mention it.
But according to the Linux driver clearing the control register and then
sending a start condition acts as if it were a repeated start.
While here, add braces around a single-line 'if' branch to balance it
with a multi-line 'else' branch.
Tested with max44009(4).
MFC after: 2 weeks
Most of these already treat it as a proper bool, i.e. using true/false.
Also fix-up callers of OF_install().
No functional change intended.
Reviewed by: andrew, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45733
Prevent kernel panic by not running ISPCTL_FCLINK_TEST after a
failed ISPCTL_ABORT_CMD.
Reviewed by: mav
Tested by: Arne Steinkamm <arne@steinkamm.com>
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D45718
When booting to VHE we need to handle using the PMU at either EL1 or
EL2. WE already support EL1 so add support for EL2.
Reviewed by: mhorne
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45527
The third arg of the DRIVER_MODULE arg is the driver to use. We want to
use the acpi bus version rather than the generic one. Otherwise, the
ACPI specific probe and attach functions aren't used and we don't see
the device.
Sponsored by: Netflix
device_attach routines are allowed to sleep, and this routine already
has other M_WAITOK allocations.
Reported by: markj
Reviewed by: markj
Fixes: 1efd69f933 ("p9fs: move NULL check immediately after alloc...")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45721
ispfw(4) recently gained firmware for Qlogic 27XX and 28XX
FC controllers, and isp(4) now selects the newer of firmware in
flash or in ispfw(4) to load for those controllers.
This differs from the previous behavior (which remains for older
controllers), which was to always load the ispfw(4) firmware if it
is available.
This adds a loader tunable, hint.isp.N.fwload_force to default to
loading the ispfw(4) firmware, whether or not it is newer than the
firmware in flash. This allows the user to always use the known
firmware version included with the kernel.
Note that there is an existing fwload_disable tunable that tells
the driver to always load the firmware from flash and ignore
ispfw(4). If fwload_disable is set, fwload_force will be ignored.
So users with existing fwload_disable tunables will have the same
behavior.
If a user specifies both fwload_force and fwload_disable for the
same controller, the isp(4) driver prints a warning message,
and fwload_disable will be honored.
The user can see which firmware is active through the
dev.isp.N.fw_version* sysctl variables.
share/man/man4/isp.4:
Document the new loader tunable.
sys/dev/isp/isp.c:
In isp_load_risc_flash(), changet the decision logic to
also consider ISP_CFG_FWLOAD_ONLY. Load the flash firmware
and get the version, so the user knows what it is, but if
the user set fwload_force, honor that. If the user didn't
set fwload_force, the behavior remains to select the newer
firmware version.
sys/dev/isp/isp_pci.c:
Add a new fwload_force tunable. Print out a warning if the
user sets both fwload_disable and fwload_force.
sys/dev/isp/ispvar.h:
Add a new ISP_CFG_FWLOAD_FORCE configuration bit.
Reviewed by: mav
MFC after: 1 week
Sponsored by: Spectra Logic
Differential Revision: <https://reviews.freebsd.org/D45688>
