Some implementations of the virtio 9p transport are implemented on
virtio_mmio, e.g. the Arm FVP. Use the correct macro so the driver
attaches when this is the case.
Reviewed by: markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49600
If, when submitting a request, the virtqueue is full, we sleep until an
interrupt has fired, then restart the request. However, while sleeping
the channel lock is dropped, and in the meantime another thread may have
reset the per-channel SG list, so upon retrying we'd (re)submit whatever
happened to be left over in the previous request.
Fix the problem by rebuilding the SG list after sleeping.
Sponsored by: Klara, Inc.
- Remove superfluous newlines.
- Use bool literals.
- Replace an unneeded SYSINIT with static initialization.
No functional change intended.
Sponsored by: Klara, Inc.
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
device_attach routines are allowed to sleep, and this routine already
has other M_WAITOK allocations.
Reported by: markj
Reviewed by: markj
Fixes: 1efd69f933b6 ("p9fs: move NULL check immediately after alloc...")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45721
This is derived from swills@ fork of the Juniper virtfs with many
changes by me including bug fixes, style improvements, clearer layering
and more consistent logging. The filesystem is renamed to p9fs to better
reflect its function and to prevent possible future confusion with
virtio-fs.
Several updates and fixes from Juniper have been integrated into this
version by Val Packett and these contributions along with the original
Juniper authors are credited below.
To use this with bhyve, add 'virtio_p9fs_load=YES' to loader.conf. The
bhyve virtio-9p device allows access from the guest to files on the host
by mapping a 'sharename' to a host path. It is possible to use p9fs as a
root filesystem by adding this to /boot/loader.conf:
vfs.root.mountfrom="p9fs:sharename"
for non-root filesystems add something like this to /etc/fstab:
sharename /mnt p9fs rw 0 0
In both examples, substitute the share name used on the bhyve command
line.
The 9P filesystem protocol relies on stateful file opens which map
protocol-level FIDs to host file descriptors. The FreeBSD vnode
interface doesn't really support this and we use heuristics to guess the
right FID to use for file operations. This can be confused by privilege
lowering and does not guarantee that the FID created for a given file
open is always used for file operations, even if the calling process is
using the file descriptor from the original open call. Improving this
would involve changes to the vnode interface which is out-of-scope for
this import.
Differential Revision: https://reviews.freebsd.org/D41844
Reviewed by: kib, emaste, dch
MFC after: 3 months
Co-authored-by: Val Packett <val@packett.cool>
Co-authored-by: Ka Ho Ng <kahon@juniper.net>
Co-authored-by: joyu <joyul@juniper.net>
Co-authored-by: Kumara Babu Narayanaswamy <bkumara@juniper.net>
When a channel is closed, dsp_close() either calls vchan_destroy() on vchans,
or chn_abort()/chn_flush() on primary channels. However, the problem with this
is that, when closing a vchan, we end up not terminating the stream properly.
The call sequence we are interested in is the following:
vchan_destroy(vchan) -> chn_kill(vchan) -> chn_trigger(vchan) ->
vchan_trigger(vchan) -> chn_notify(parent)
Even though chn_notify() contains codepaths which call chn_abort(parent),
apparently we do not execute any of those codepaths in this case, so the
DMA remains unterminated, hence why we keep seeing the primary
channel(s) being interrupted even once the application has exited:
root@freebsd:~ # sndctl interrupts
dsp0.play.0.interrupts=1139
dsp0.record.0.interrupts=0
root@freebsd:~ # sndctl interrupts
dsp0.play.0.interrupts=1277
dsp0.record.0.interrupts=0
root@freebsd:~ # sndctl interrupts
dsp0.play.0.interrupts=1394
dsp0.record.0.interrupts=0
The only applications that do not have this issue are those (e.g., mpv) that
manually call ioctls which end up calling chn_abort(), like SNDCTL_DSP_HALT, to
abort the channel(s) during shutdown. For all other applications that do not
manually abort the channel(s), we can confirm that chn_abort()/chn_flush(), or
even chn_trigger(PCMTRIG_ABORT) on the parent, doesn't happen during shutdown.
root@freebsd:~ # dtrace -n 'fbt::chn_abort:entry,fbt::chn_flush:entry { printf("%s", args[0]->name); stack(); }'
dtrace: description 'fbt::chn_abort:entry,fbt::chn_flush:entry ' matched 2 probes
dtrace: buffer size lowered to 1m
^C
[...]
root@freebsd:~ # dtrace -n 'fbt::chn_trigger:entry /args[1] == -1/ { printf("%s", args[0]->name); stack(); }'
dtrace: description 'fbt::chn_trigger:entry ' matched 1 probe
dtrace: buffer size lowered to 1m
CPU ID FUNCTION:NAME
0 68037 chn_trigger:entry dsp0.virtual_play.0
sound.ko`chn_kill+0x134
sound.ko`vchan_destroy+0x94
sound.ko`dsp_close+0x39b
kernel`devfs_destroy_cdevpriv+0xab
kernel`devfs_close_f+0x63
kernel`_fdrop+0x1a
kernel`closef+0x1e3
kernel`closefp_impl+0x76
kernel`amd64_syscall+0x151
kernel`0xffffffff8103841b1
To fix this, modify dsp_close() to execute the primary channel case on both
primary and virtual channels. While what we really care about are the
chn_abort()/chn_flush() calls, it shouldn't hurt to call the rest of the
functions on the vchans as well, to avoid complicating things; they get deleted
right below, anyway.
With the patch applied:
root@freebsd:~ # dtrace -n 'fbt::chn_trigger:entry /args[1] == -1/ { printf("%s", args[0]->name); stack(); }'
dtrace: description 'fbt::chn_trigger:entry ' matched 1 probe
dtrace: buffer size lowered to 1m
CPU ID FUNCTION:NAME
1 68037 chn_trigger:entry dsp0.virtual_play.0
sound.ko`chn_flush+0x2a
sound.ko`dsp_close+0x330
kernel`devfs_destroy_cdevpriv+0xab
kernel`devfs_close_f+0x63
kernel`_fdrop+0x1a
kernel`closef+0x1e3
kernel`closefp_impl+0x76
kernel`amd64_syscall+0x151
kernel`0xffffffff8103841b
0 68037 chn_trigger:entry dsp0.play.0
sound.ko`chn_notify+0x4ce
sound.ko`vchan_trigger+0x105
sound.ko`chn_trigger+0xb4
sound.ko`chn_flush+0x2a
sound.ko`dsp_close+0x330
kernel`devfs_destroy_cdevpriv+0xab
kernel`devfs_close_f+0x63
kernel`_fdrop+0x1a
kernel`closef+0x1e3
kernel`closefp_impl+0x76
kernel`amd64_syscall+0x151
kernel`0xffffffff8103841b
Above we can see a chn_trigger(PCMTRIG_ABORT) on the parent (dsp0.play.0),
which is coming from the chn_abort() (inlined) in chn_notify():
root@freebsd:~ # dtrace -n 'kinst::chn_abort:entry { stack(); }'
dtrace: description 'kinst::chn_abort:entry ' matched 5 probes
dtrace: buffer size lowered to 1m
CPU ID FUNCTION:NAME
1 72580 chn_notify:1192
sound.ko`0xffffffff8296cab4
sound.ko`vchan_trigger+0x105
sound.ko`chn_trigger+0xb4
sound.ko`chn_flush+0x2a
sound.ko`dsp_close+0x330
kernel`devfs_destroy_cdevpriv+0xab
kernel`devfs_close_f+0x63
kernel`_fdrop+0x1a
kernel`closef+0x1e3
kernel`closefp_impl+0x76
kernel`amd64_syscall+0x151
kernel`0xffffffff8103841b
We can also confirm the primary channel(s) are not interrupted anymore:
root@freebsd:/mnt/src # sndctl interrupts
dsp0.play.0.interrupts=0
dsp0.record.0.interrupts=0
In collaboration with: adrian
Tested by: adrian, christos, thj
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: thj, adrian, emaste
Differential Revision: https://reviews.freebsd.org/D50488
(cherry picked from commit f6430bc61df78be070209d52b4452ae9cf4cd015)
(cherry picked from commit 0c6aa445ec0c85e7c9653d20562907742569de6f)
Approved by: re (cperciva)
Power down the device on shutdown similar to what is done in the case
of suspend. The device may fail to attach on next boot without this.
PR: 286385
Reviewed by: christos, adrian
Differential Revision: https://reviews.freebsd.org/D50306
(cherry picked from commit d9900b9ea2b27f7a0c2eda97841b9499e02e3ea7)
(cherry picked from commit 77521692f4c71213c5419268657e696532c28325)
Approved by: re (cperciva)
Changes since 2.8.0:
Bug Fixes:
* Fix LLQ normal width misconfiguration
* Check for errors when detaching children first, not last
Minor Changes:
* Remove \n from sysctl description
Approved by: cperciva (mentor)
Sponsored by: Amazon, Inc.
Differential Revision: https://reviews.freebsd.org/D50041
(cherry picked from commit 59b30c1a864ee8a22c2e9912301cb88674f714c9)
Patch 0a33c047a443 introduced new values to
hw.ena.force_large_llq_header. The default value of 2 means no
preference, while 0 and 1 act as the previous false and true
respectively, which allowed forcefully setting regular or large LLQ.
There are 2 ways to force the driver to select regular LLQ:
1. Setting hw.ena.force_large_llq_header = 0 via sysctl.
2. Turning on ena express, which makes the recommendation by the FW to
be regular LLQ.
When the device supports large LLQ but the driver is forced to
regular LLQ, llq_config->llq_ring_entry_size_value is never initialized
and since it is a variable allocated on the stack, it stays garbage.
Since this variable is involved in calculating max_entries_in_tx_burst,
it could cause the maximum burst size to be zero. This causes the driver
to ignore the real maximum burst size of the device, leading to driver
resets in devices that have a maximum burst size (Nitro v4 and on. see
[1] for more information).
In case the garbage value is 0, the calculation of
max_entries_in_tx_burst divides by 0 and causes kernel panic.
The patch modifies the logic to take into account all use-cases and
ensure that the relevant fields are properly initialized.
[1]: https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html
Fixes: 0a33c047a443 ("ena: Support LLQ entry size recommendation from device")
Approved by: cperciva (mentor)
Sponsored by: Amazon, Inc.
Differential Revision: https://reviews.freebsd.org/D50040
(cherry picked from commit 56c45700f2ae15755358f2da8266247613c564df)
qThis change was made after feedback from upstream, aiming to align with
the style guide for consistent log formatting. No functional changes
were made to the driver, only the formatting of the log messages.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49799
(cherry picked from commit 4494ea5406f79a6cb2d3631a723eb286ca96a9b9)
The driver version has been updated to 8.14.0.2.0 to reflect the
latest release. This is a version-only update with no functional
code changes.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49753
(cherry picked from commit f4d51d3e1a90dabbed26aacf1b58e20e23a19342)
All driver source files have been updated to reflect the year 2025.
This change is cosmetic and does not affect functionality.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49752
(cherry picked from commit 69be9a247b845b35146fed4575dacb565c9c18ba)
The driver now processes LOG Data events in the interrupt top
half instead of the bottom half. This allows LOG events to be
handled immediately upon receipt, reducing latency and enabling
early notification to the Library or applications.
This change ensures LOG event handling occurs closer to the
firmware's generation point, improving alignment with event-driven
diagnostic and monitoring mechanisms.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49751
(cherry picked from commit df8a74fca036a0ba8026f3ae3da830dffb922faa)
This patch ensures the driver sets the Diag Save bit for all
diagnostic fault conditions before issuing a Diagnostic Fault Reset.
The firmware now incorporates logic to manage snapdump saving
and requires the driver to always set the Diag Save bit to enable
this feature. This change supports improved diagnostic data
collection and fault handling.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49750
(cherry picked from commit b854677d970a11e87929fa95d0e4067f911faa62)
The driver previously blocked I/Os only for OS-initiated task
management commands. This patch extends the behavior to also
block I/Os during application-initiated task management
operations (excluding Task Abort).
Before submitting such commands to the firmware, I/O
submissions are paused for the respective device. Once the
command completes, I/O operations are resumed.
This ensures safe and consistent task management handling.
[[ Note: Warner landed this with the pending suggestion
since this change is good enough for 14.3, but chs' suggestion
for better atomics needs to be implemented soon ]]
Discussed with: imp, chs
Differential Revision: https://reviews.freebsd.org/D49749
(cherry picked from commit 49445b54638f7b2d45942edd61c70fe0baa28f37)
The driver now retrieves the Time Stamp value from Driver Page 1
during load and after controller reset. If the value is valid, it
is used to enable periodic host timestamp synchronization.
This adds a tunable NVData parameter to control the behavior of
host time sync, enhancing flexibility and platform-specific control.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49748
(cherry picked from commit e80317babdb9044962dcbf16c69633579cd90b00)
The driver now checks for insufficient power faults during the load
phase and immediately fails initialization instead of retrying.
Additionally, if an insufficient power fault is detected by the watchdog
after the controller is up, the controller is marked as unrecoverable
instead of triggering a reset.
This improves fault handling and avoids unnecessary recovery attempts
in low-power conditions.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49747
(cherry picked from commit 116c8b18a2b5278df0d1982a683193c3dba6f30c)
This patch improves the retry logic during the IOC enable process.
If a controller faults or if the reset history bit is detected during
the ready status check, the driver will retry initialization up to three
times or until 510 seconds have passed.
A soft reset will also be issued if the controller is detected while
waiting for the ready status.
This enhances reliability during controller initialization.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49746
(cherry picked from commit e977ed50bb2b9fce5e285756673286c5fcfb1f31)
This patch updates the driver to set the OSExposure field in DriverCapability
during IOCInit to MPI3_IOCINIT_DRIVERCAP_OSEXPOSURE_NO_SPECIAL(0x1), aligning
with the latest MPI specification version 36.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49745
(cherry picked from commit d14c4ea0caebb9d0ddb613e348cb8c1a19e8d8fc)
Updated the MPI header files to version 36 to align with the latest
MPI specification. This includes updated structures, field definitions,
and constants required for compatibility with updated firmware.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49743
(cherry picked from commit 92f340d137ba5d6db7610ba1dae35842e2c9c8ea)
The max I/O size that an mpi3mr HBA supports is reported in the IOCFacts
structure (with 0 representing the legacy max I/O size of 1 MB).
By default, set the max I/O size of devices attached to mpi3mr controllers
to the smaller of the HBA's max I/O size and the kernel's maxphys.
Allow this default to be overriden by a global tunable
"hw.mpi3mr.max_sgl_entries" or by a per-controller tunable
"dev.mpi3mr.N.max_sgl_entries".
Sponsored by: Netflix
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D49090
(cherry picked from commit f2605f67a13eb1f1427ee58a097791ca25359a5e)
Firmware advertises the transfer lenght for writesame commands to driver during init.
So for any writesame IOs with ndob and unmap bit set and transfer lengh is greater
than the max write same length specified by the firmware, then direct those commands
to firmware instead of hardware otherwise hardware will break.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D44452
(cherry picked from commit 3f3a15543a6721100dda0e4219eb48ecbe35731a)
The driver is modified to add FreeBSD OS type in the upper nibble of the
fault/reset reason code for appropriate qualification of the reason code.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D44427
(cherry picked from commit 3012fa8faef262c615672fc90319c777b4e3dffc)
Accept any fault as successful for diagnostic fault reset, not just the 0xF000
code. print fault information and return.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D44426
(cherry picked from commit 4034d7061a112b78d60cdb581c2d71f7cfa9f74e)
Instead of updating the ConsumerIndex of the Admin and Operational ReplyQueues
after processing all replies in the queue, it will now be periodically updated
after processing every 100 replies.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D44425
(cherry picked from commit eb7a4b35de89a0e22f1fb373df33d79135b68dd8)
Post controller reset, If any device removal events arrive, and if
there are any outstanding IOs then the driver will unnecessarily wait
in the loop for 30 seconds before removing the device from the OS.
reset target outstanding IO counter and controller outstanding IO counter
and remove the redundant wait loop.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D44424
(cherry picked from commit 571f1d0638fa6b3a08f84118a33e53f941f0820c)
An outstanding IO counter per target check has been added before deleting
the target from the OS which will poll the reply queue if there are any
outstanding IOs are found.
A new flag, named "MPI3MR_DEV_REMOVE_HS_COMPLETED," is added. If a remove event
for a target occurs and before the deletion of the target resource if the add event
for another target arrives reusing the same target ID then this flag will prevent
the removal of the target reference. This flag ensures synchronization between the interrupt
top and bottom half during target removal and addition events.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D44423
(cherry picked from commit 701d776c98e015160c2d0e3f4fdaf980d1d5dc83)
The driver removes the drive from the OS if firmware sends 'device added'
event with hidden bit or inaccessible status.
Reviewed by: imp
Approved by: imp
Differential revision: https://reviews.freebsd.org/D44421
(cherry picked from commit 0d7056458db5b5dd7fdc5ccd8abab73e3ee76a20)
Use sc->mpi3mr_debug & MPI3MR_IOT over the | version to test if a bit is
set.
CID: 1529718
Sponsored by: Netflix
(cherry picked from commit 34f0a01b6bd4ff0e61a7066729515148400e0982)
To match documentation.
Reported by: Ihor Dutchak <ihor.youw@gmail.com>
PR: 286155
MFC after: 3 days
(cherry picked from commit fe4bdd889b5d722faa3a66e2c7d9a248e527cdb2)
to Linux hidraw compatibility API.
Respective Linux commit f43d3870cafa made by Dean Camera message is:
Currently the hidraw module can only read and write feature HID reports on
demand, via dedicated ioctls. Input reports are read from the device through
the read() interface, while output reports are written through the write
interface().
This is insufficient; it is desirable in many situations to be able to read and
write input and output reports through the control interface to cover
additional scenarios:
- Reading an input report by its report ID, to get initial state
- Writing an input report, to set initial input state in the device
- Reading an output report by its report ID, to obtain current state
- Writing an output report by its report ID, out of band
This patch adds these missing ioctl requests to read and write the remaining
HID report types. Note that not all HID backends will neccesarily support this
(e.g. while the USB link layer supports setting Input reports, others may not).
FreeBSD native uhid(4) compatible API already has similar ioctls.
MFC after: 3 days
(cherry picked from commit fd6690e2d5cd5b15fce2c74ab0cac77a83514f6a)
Event codes are expected to be retrieved from a queue on at least some
models. Specifically, very likely the ACPI WMI devices with _UID ATK are
queued whereas those with ASUSWMI are not.
Sponsored by: Future Crew LLC
MFC after: 1 month
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D48984
(cherry picked from commit d5bf6a7245cc7825d17ebb00d1e7f07ae6dc32e6)
- Fix maximal keyboard backlight level, Although Linux source code
comment says that backlight level is encoded in 3 bits of data,
actual code limits maximum level to 3.
- Add backlight(9) support for keyboard
- Turn off/on keyboard backlight on suspend/resume
Sponsored by: Future Crew LLC
MFC after: 1 month
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D48983
(cherry picked from commit f134662a1a5726d78880385002a03b8fe68805f6)
Any events left over from boot firmware, etc. are not meaningful so
clear pending events during attach. If they are still pending they
should remain asserted when the slot status register is re-read.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D49950
(cherry picked from commit ff45e4759a38f44a0199b2948b7b1e987e7c71da)
At least some PCI-express bridges exposed by Intel Volume Management
Devices report bogus power faults in their slot status register. As a
workaround, ignore the power fault detected flag if the slot
capability register does not indicate support for a power controller.
While the PCI-e spec does not explicitly state that the PFD flag
should always be zero if a power controller is not present, parts of
the spec do seem to assume this. For example, the flag is included in
the "Power Controller Registers" register group in 6.7.2.4, and the
definition of the value for this flag seems to presume the presence of
a power controller:
If a Power Controller that supports power fault detection is
implemented, this bit is Set when the Power Controller detects a
power fault at this slot. Note that, depending on hardware
capability, it is possible that a power fault can be detected at
any time, independent of the Power Controller Control setting or
the occupancy of the slot. If power fault detection is not
supported, this bit must not be Set.
PR: 285993
Reported by: Jim Long <freebsd-bugzilla@umpquanet.com>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D49949
(cherry picked from commit 4c8b9f40cda7dd6b2de547b288d712c85998ce11)
