This was broken in c63d67e137f3, the early returns prevent building the
media lists as expected.
The BASE-T parts of the patch were suggested by "cyric@mm.st", while I
am adding the additional 40G AOC, 1CX, autoneg and unknown PHY fixes
based on code inspection. There may be additional work left here for
Broadcom but this is certainly better than the returns.
PR: 287395
Reported by: mickael.maillot@gmail.com, cyric@mm.st
Tested by: Einar Bjarni Halldórsson <einar@isnic.is>
(cherry picked from commit 5e6e4f752833acc96f1efc893318d3f6b74b9689)
The header file might be included after linux/stddef.h or others are
included and the macros would be re-defined.
Sponsored by: The FreeBSD Foundation
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D50156
(cherry picked from commit 152e6197615570e7a2f5f1c6c2ed00ecee9dd10c)
In order to be able to use MODULE_DEVICE_TABLE() with multiple bus
attachments, factor out the bus-specfic MODULE_PNP_INFO() and place
it next to the structure defining the table.
As it turns out bnxt(4) has been using the MODULE_DEVICE_TABLE() with
PCI attachments for the "auxillary" bus so far. That makes little sense.
Define the MODULE_PNP_INFO() to nothing for that. We may consider
pulling these LinucKPI bits in semi-native drivers into LinuxKPI
one day as that route is not really sustainabke.
Sponsored by: The FreeBSD Foundation
Reviewed by: imp, dumbbell
Differential Revision: https://reviews.freebsd.org/D51049
(cherry picked from commit 2f5666c1727c949491f73e6c3277b7b542131714)
Otherwise we can end up with a lost interrupt, causing lost request
completion wakeups and hangs in the filesystem layer.
Continue processing until we enable interrupts and then observe an empty
queue, like other virtio drivers do.
Sponsored by: Klara, Inc.
In (unknown) situations it seems the i2c bus can have trouble,
while nothing about the current link state has changed, the driver
would react by going into a link down state, and start busylooping
on up to 4 cores. Even if there was a valid link, such spinning
on a cpu by a kernel thread would wreak havoc to existing and
new connections.
This patch does the following:
1. If such a bus failure occurs, we keep the last known link state.
2. Prevent busy looping by implementing the lockmgr() facility to
be able to sleep while the i2c code waits on the i2c ISR. We cap
this with a timeout.
3. Pin the admin queues to the last CPU in the system, to prevent
other scenarios where busy looping might occur from landing on CPU
0, which especially seems to cause a lot of issues.
Given the design constraints both in hardware and in software,
the lockmgr() seems to be the only viable option, even though
FreeBSD explicitly forbids sleeping in callout context, but
fails to explain why this is or offer alternatives.
axgbe: revert allocating admin queues to last CPU
The issue was resolved in 52454a1e5b.
Scheduled threads such as CARP are now no longer pinned to CPU 0, making sure
they always get their time slice even if CPUs are blocked.
Since the I/O expander chip does not do a reset when soft power
cycling, the driver will first turn off all LEDs when initializing,
although no specific routine seems to be called when powering down.
This means that the LEDs will stay on until the driver has booted up,
after which the driver will be in a consistent state.
Initially, RSF (Receive Queue Store and Forward) was disabled for
unknown reasons, but the cut-through mode that's enabled as a result
seems to send 0 length packets up to the DMA when the RX queue is
full.
Since the iflib interface needs axgbe_pci_init() and its phy starting capabilities, no data was passed in its absence.
With the NULL check of the axgbe_miibus we also resort back to an MDIO read as a module might be capable of both
clause 22 and clause 45 methods of communication.
with the move of phy_stop() to if_detach() in d50d4e8cd4, it's better to prevent reconfiguring the phy should the pci_init() callout trigger more than once.
Within the code path of autonegotiation for gigabit SFP modules was a bug, causing
a report of LINK_ERR for cases where an external SFP PHY was present. Fixing this issue
did not resolve to a link however, as it turned out that while autonegotiation interrupts
were happening, it's resulting status cannot be correctly determined in all cases. In these
specific cases we have no other option than to assume a module has negotiated to 1Gbit/s.
PHY-specific configuration has been delegated to the miibus driver, if an external PHY is present.
It's possible that the i2c bus does not recognize a PHY on the first pass, so in all cases we
retry up to a maximum of 5 times during each link poll pass to ensure we didn't miss the presence
of an external PHY.
This commit also addresses link issues on both 100 mbit and 1Gb fiber modules. Not all of these modules
have the correct data set according to SFF-8472, as such we first check for gigabit compliance and
the associated baudrate, otherwise we resort back to determining what type of fiber module is plugged
in by checking the baudrate, cable length and wavelength and setting the MAC speed accordingly.
It is possible for a machine to boot into a state in which the configuration register,
responsible for controlling wether an I/O signal is considered an input or output,
contains randomized values. It was assumed this was programmed by the BIOS.
If I/O is reversed, it's possible for the driver to think an SFPP module has been inserted
when there is none, leading to unrecoverable I2C errors.
The configuration register should contain a state which is determined and provided by the BIOS,
hence no hard-coded values are programmed here.
The current addition to the interrupt nesting level in
xen_arch_intr_handle_upcall() needs to be compensated in
xen_intr_handle_upcall(), otherwise interrupts dispatched by the upcall handler
end up seeing a td_intr_nesting_level of 2 or more, which makes them assume
there's been an interrupt nesting.
Such extra interrupt nesting count lead to statclock() reporting idle time as
interrupt, as the call from interrupt context will always be seen as a nested
one (td->td_intr_nesting_level >= 2) due to the nesting count increase done by
both xen_arch_intr_handle_upcall() and intr_execute_handlers().
Fix this by adjusting the nested interrupt count before dispatching interrupts
from xen_intr_handle_upcall().
PR: 277231
Reported by: Matthew Grooms <mgrooms@shrew.net>
Fixes: af610cabf1 ('xen/intr: adjust xen_intr_handle_upcall() to match driver filter')
Sponsored by: Cloud Software Group
Reviewed by: Elliott Mitchell <ehem+freebsd@m5p.com>
When executing `ifconfig -v` this will lead to stalls for a second per
interface due to the timeout being set to a static 10 without a module
placed, this patch makes sure this is only allowed once per insertion.
Build and sysctl configuration modes are introduced for QAT SPR
devices to disable safe dc mode. A new QAT driver build option
‘QAT_DISABLE_SAFE_DC_MODE’ is required to build the QAT driver
with code that allows a request to be sent to FW to override the
‘History Buffer’ mitigation. Default QAT driver builds do not
include this ‘QAT_DISABLE_SAFE_DC_MODE’ build option. Even if the
QAT driver was built with code that allows a request to be sent to
FW to override the ‘History Buffer’ mitigation, the QAT driver must
still be configured using sysctl to request an override of the
‘History Buffer’ mitigation if desired. The default QAT driver
configuration option sysctl dev.qat.X.disable_safe_dc_mode does not
allow override of the mitigation. The new sysctl attribute
disable_safe_dc_mode is to be set to 1 for overriding the history
buffer mitigation. Firmware for qat_4xxx is updated for this change.
If this mode is enabled, decompression throughput increases but may
result in a data leak if num_user_processes is more than 1.
This option is to be enabled only if your system is not prone to
user data leaks.
Reviewed by: markj, ziaee
MFC after: 2 weeks
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D50379
(cherry picked from commit 5a8e5215cef0dac1115853889e925099f61bb5fa)
The justification is the same as in commit
fb876eef219e ("e1000: Fix some issues in em_newitr()").
Reviewed by: kbowling
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D50548
(cherry picked from commit ef062029ceffacb6bde3a5639a2bd8c4d59ca1df)
The justification is the same as in commit
a5b5220b1807 ("e1000: Initialize helper variables in em_newitr()").
Reviewed by: kbowling
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D50547
(cherry picked from commit d6a9f49185797c6b67e517a3d83ef63436c8d4f3)
- Load packet and byte counters exactly once, as they can be
concurrently mutated.
- Rename bytes_packets to bytes_per_packet, which seems clearer.
- Use local variables that have the same types as the counter values,
rather than truncating unsigned long to u32.
Reviewed by: kbowling
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D50416
(cherry picked from commit 731c145612dd6ffe457a562959a5c027acf13334)
Due to races with the threaded transmit and receive paths, it's possible
to have r/tx_bytes != 0 && r/tx_packets == 0, in which case the maximum
byte count could be left uninitialized. Initialize them to zero to
handle this case.
PR: 286819
Reviewed by: kbowling
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D50416
(cherry picked from commit e0267657f3965a56d877075fe3d4d41b8afb2faf)
Device ID for E830-XXV adapters was changed from 12D3
to 12DE. Update driver accordingly and bump version
number.
Also remove subdevice id for E830-XXV-4 for OCP 3.0,
which was cancelled.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Approved by: kbowling (mentor), erj (mentor)
Tested by: Gowthamkumar K S <gowtham.kumar.ks@intel.com>
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D50327
(cherry picked from commit 0fed8828c95a9d2cbcb43147ff851ca6f2c21d0f)
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)
