While sending request using ixgbe_hic_unlocked() the data field in
buffer struct is not used. It is set when the struct is overwritten by
FW to deliver the response. To not pass random data to FW the whole
structure should be zeroed before use.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Signed-off-by: Piotr Pietruszewski <piotr.pietruszewski@intel.com>
Signed-off-by: Guinan Sun <guinanx.sun@intel.com>
Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Approved by: imp
Obtained from: DPDK (40543be5376ca415b2a7e196315d0555725b8bdf)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31621
(cherry picked from commit b3ebe337ff)
With the NVM image for x550em XFI will not report
the auto-negotiation feature correctly. The auto-negotiation
should be "No" for supports and advertised items.
At the same time update speed makes it support 1G and 10G.
Signed-off-by: Piotr Skajewski <piotrx.skajewski@intel.com>
Signed-off-by: Guinan Sun <guinanx.sun@intel.com>
Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Approved by: imp
Obtained from: DPDK (fb03b51da940f1d56d701776fd85a0dfc1ace098)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31621
(cherry picked from commit 8e9f1b239d)
As the code has changed the max wait time to 1000ms, the comment should
be changed accordingly.
Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Approved by: imp
Obtained from: DPDK (73247f1ced303c16987bb366d38a2d8a0fc40db4)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31621
(cherry picked from commit 96ef6eb3ae)
After setting up the link on a fiber port, the maximum wait time for
the link to come up is 500 ms in ixgbe_setup_mac_link_multispeed_fiber().
On an x550 SFP+ port, this is often not sufficiently long for the link
to come up. This can result in never being able to retrieve accurate
link status for the port using rte_eth_link_get_nowait().
Increase the maximum wait time in ixgbe_setup_mac_link_multispeed_fiber()
to 1 s.
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Approved by: imp
Obtained from: DPDK (64f1c8539c8ce99214b9eb1fb728a2c6745f3300)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31621
(cherry picked from commit aaa3af802f)
For the "Apply Update" command the firmware does not
given an response. For this command, success should
be return.
Signed-off-by: Mateusz Kowalski <mateusz.kowalski@intel.com>
Signed-off-by: Guinan Sun <guinanx.sun@intel.com>
Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Approved by: imp
Obtained from: DPDK (03b09c71c0c6c516ce05cad8e8aa75e8b9e14fba)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31621
(cherry picked from commit c966c431c7)
On ESXi OS, when user disables auto negotiation, the following log
appears: "(unsupported) Flow control autoneg is disabled".
It is true that auto negotiation is disabled but it is
not necessarily true that it is not supported.
Signed-off-by: Jakub Chylkowski <jakubx.chylkowski@intel.com>
Signed-off-by: Guinan Sun <guinanx.sun@intel.com>
Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Approved by: imp
Obtained from: DPDK (ab6ac48d483ef7f906b90f45182f2ddf3254d876)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31621
(cherry picked from commit f511cd2258)
In some corner cases the functions ixgbe_clear_rar_generic and
ixgbe_clear_vmdq_generic may call one another leading to infinite
recursion.
When ixgbe_clear_vmdq_generic is called with IXGBE_CLEAR_VMDQ_ALL
flag, it's going to clear MPSAR registers, and proceed to call
ixgbe_clear_rar_generic, which in turn will clear the RAR registers,
and recursively call back ixgbe_clear_vmdq_generic. Normally, the
latter would detect that MPSAR registers have already been cleared
and terminate the recursion.
However, when PCIe link is down, and before the driver has had the
opportunity to shut itself down, all register reads return 0xFFFFFFFF,
and all register writes fail silently. In such case, because
ixgbe_clear_vmdq_generic blindly assumes that clearing MPSAR registers
succeeded, it's going to always call ixgbe_clear_rar_generic, which
in turn will always call back ixgbe_clear_vmdq_generic, creating
infinite recursion.
This patch re-reads MPSAR register values after they had been cleared.
In case of PCIe link failure, the values read will be non-zero, which
will terminate the recursion. On the other hand, under normal
circumstances the value read from MPSAR registers is going to be equal
to the value previously written, so this patch is expected not to cause
any regressions.
Signed-off-by: Robert Konklewski <robertx.konklewski@intel.com>
Signed-off-by: Guinan Sun <guinanx.sun@intel.com>
Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Approved by: imp
Obtained from: DPDK (2d04b9e856125197ec8e967471426d56ab7efcf0)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31621
(cherry picked from commit 8270b7174c)
ixgbe devices support up to 8 Rx and Tx queues per virtual function.
Currently, the registers of only seven queues are set to default when
resetting a VF.
Signed-off-by: Simon Ellmann <simon.ellmann@tum.de>
Acked-by: Haiyue Wang <haiyue.wang@intel.com>
Approved by: imp
Obtained from: DPDK (d2565b347915def3a0f3c68bde6824acf096a0e6)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31621
(cherry picked from commit 7165504a17)
- Re-implement pcib interface to use standard pci bus driver on top of
vmd(4) instead of custom one.
- Re-implement memory/bus resource allocation to properly handle even
complicated configurations.
- Re-implement interrupt handling to evenly distribute children's MSI/
MSI-X interrupts between available vmd(4) MSI-X vectors and setup them
to be handled by standard OS mechanisms with minimal overhead, except
sharing when unavoidable.
Successfully tested on Dell XPS 13 laptop with Core i7-1185G7 CPU (VMD
device ID 0x9a0b) and single NVMe SSD, dual-booting with Windows 10.
Successfully tested on Supermicro X11DPI-NT motherboard with Xeon(R)
Gold 6242R CPUs (VMD device ID 0x201d), simultaneously handling NVMe
SSD on one PCIe port and PLX bridge with 3 NVMe and 1 AHCI SSDs on
another. Handles SSD hot-plug (except Optane 905p for some reason,
which are not detected until manual bus rescan) and enabled IOMMU
(directly connected SSDs work, but ones connected to the PLX fail
without errors from IOMMU).
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
Differential revision: https://reviews.freebsd.org/D31762
(cherry picked from commit 7af4475a6e)
This fixes a kernel panic when probing for vmd_bus on Intel TigerLake on
14-CURRENT. Apparently, vmd_bus is a type of PCI bus, but was registered
as a separate device class.
PR: 256915
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D31071
(cherry picked from commit ad1f608fb2)
rtsx copied code from sdhci, and has the same wakeup race bug that was
fixed in 35547df5c7, so apply a similar fix here.
Sponsored by: Netflix
(cherry picked from commit 9339e7c0bd)
In implicit mode assignment of slot number and tracking id is performed
automatically on each synchronization requested by device driver.
This is done with creation of intermediate buffer for multitouch events.
This buffer holds untracked events until synchronization is requested by
device driver. It is needed as touch assigment requires
knowledges of all touch positions pushed in current and previous reports.
(cherry picked from commit f76051c7da)
Touch tracking is a process of assignment of unique trackingID to each
initiated contact on the surface. Keeping the trackingIDs persistent
across multitouch reports requires solving of so called Euclidian
Bipartite Matching problem.
This commit imports EBM-solver implementation based on Dinitz-Kronrod
algorithm to find minimum cost matching between contacts listed in two
consecutive reports.
Obtained from: OpenBSD
(cherry picked from commit 4c0a134e32)
with using of unioned anonymous structure.
Access to the same data by using different members of union generally
works despite it is not supported by C specs.
Also add helper function to report entire slot state.
(cherry picked from commit 059360287e)
As fuzz has already been applied on multitouch event processing.
This allows to remove existing workaround for double fuzz procesing.
(cherry picked from commit 314913ed7c)
1. Move touch count reporting helpers to utils. They are not multitouch.
2. Use evdev_mt prefix for private multitouch support routines.
3. Use int instead of int32_t where fixed size is not required.
4. Export some internal functions.
This change should be no-op.
(cherry picked from commit 98a7606b85)
Implement kernel support for RFC 5549/8950.
* Relax control plane restrictions and allow specifying IPv6 gateways
for IPv4 routes. This behavior is controlled by the
net.route.rib_route_ipv6_nexthop sysctl (on by default).
* Always pass final destination in ro->ro_dst in ip_forward().
* Use ro->ro_dst to exract packet family inside if_output() routines.
Consistently use RO_GET_FAMILY() macro to handle ro=NULL case.
* Pass extracted family to nd6_resolve() to get the LLE with proper encap.
It leverages recent lltable changes committed in c541bd368f.
Presence of the functionality can be checked using ipv4_rfc5549_support feature(3).
Example usage:
route add -net 192.0.0.0/24 -inet6 fe80::5054:ff:fe14:e319%vtnet0
Differential Revision: https://reviews.freebsd.org/D30398
(cherry picked from commit 62e1a437f3)
We do this when creating md(4) devices, in kern_mdattach_locked(), but
not when resizing the provider. Apply the same policy when resizing, as
many GEOM classes do not expect to deal with providers for which
pp->mediasize % pp->sectorsize != 0.
Reported by: syzkaller
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 47619b6044)
This is used for the on-board flash on the HiFive Unmatched board.
Reviewed by: #riscv, jrtc27
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31562
(cherry picked from commit 416ac155bb)
This has been present since the first revision of the file. The debugf
macros have always been unused so it doesn't actually do anything
useful, and besides, debugging should not be unconditionally turned on
for a production driver. Moreover, this breaks the riscv LINT kernel
build as sys/conf/NOTES includes options DEBUG, resulting in a macro
redefinition error. This does not show up in the arm64 LINT kernel build
since that has an explicit nooptions DEBUG, which is dubious and should
be revisited. Rather than copy such a hack to riscv's NOTES, fix this
specific instance of DEBUG breaking.
Fixes: 896e217a0e ("fu740_pci_dw: Add SiFive FU740 PCIe controller driver")
MFC after: 1 week
(cherry picked from commit 22997b7550)
Currently we use the num-viewports property to decide how many outbound
regions there are we can use, defaulting to 2. However, Linux has
stopped using that and so it no longer appears in new device trees, such
as for the SiFive FU740. Instead, it's possible to just probe the
hardware directly.
Reviewed by: mmel
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31030
(cherry picked from commit 4707bb0430)
This supersedes the old legacy mode where a viewport register was used
to mux multiple regions behind a single set of registers, and is used on
the SiFive FU740.
Reviewed by: mmel
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31029
(cherry picked from commit f240dfff22)
Currently we assume there is only one memory and one prefetch memory
window, and ignore the latter. However, the SiFive FU740 has two normal
memory windows.
As part of this, the viewports are rearranged. Previously the viewports
were memory, config then optionally I/O. Both to simplify the config
index calculation and to ensure it can always be mapped even if we have
too many memory windows for the number of viewports, config is moved to
being the first viewport.
This generalisation now also naturally supports mapping prefetch memory
windows.
Reviewed by: mmel
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31028
(cherry picked from commit f8c1701f23)
The size of the ATU MEM/IO windows is implicitly casted to uint32_t.
Because of that some window sizes were silently demoted to 0 and ignored.
Check the size if its too large, trim it to 4GB and print a warning message.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: mw
Obtained from: Semihalf
Sponsored by: Marvell
Differential revision: https://reviews.freebsd.org/D29625
(cherry picked from commit 243000b19f)
Use viewport "2" instead of "0" and change window type from MEM to IO.
Without these changes the MEM ATU window can be overwritten with the IO one.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Obtained from: Semihalf
Sponsored by: Marvell
Differential revision: https://reviews.freebsd.org/D29516
(cherry picked from commit 57dbb3c259)
Note that currently Linux's device tree uses the FU540's compatible
string, as does upstream U-Boot, but the U-Boot shipped with the board
based on an older patch series has the correct FU740 name. Thankfully
they are the same, at least as far as software is concerned.
Whilst here, fix a style(9) nit.
Reviewed by: philip, kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31034
(cherry picked from commit 4c4a6884ad)
If we can't allocate more MSI-X vectors, accept using single shared.
If we can't allocate any MSI-X, try to allocate 2 MSI vectors, but
accept single shared. If still no luck, fall back to shared INTx.
This provides maximal flexibility in some limited scenarios. For
example, vmd(4) does not support INTx and can handle only limited
number of MSI/MSI-X vectors without sharing.
MFC after: 1 week
(cherry picked from commit e3bdf3da76)
Before this change devq was frozen only if some command was sent to
the target after reset started, but release was called always. This
change freezes the devq immediately, leaving mprsas_action_scsiio()
check only to cover race condition due to different lock devq use.
This should also avoid unnecessary requeue of the commands, creating
additional log noise and confusing some broken apps.
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
(cherry picked from commit 9781c28c6d)
SAS9305-16e with firmware 16.00.01.00 report HighPriorityCredit of
only 8, while for comparison some other combinations I have report
100 or even 128. In case of large JBOD detach requirement to send
target reset command to each target same time overflows the limit,
and without adequate handling makes devices stuck in half-detached
state, preventing later re-attach.
To handle that in case of allocation error mark the target with new
MPRSAS_TARGET_TOREMOVE flag, and retry the removal attempt next time
something else free high priority command. With this patch I can
successfully detach/attach 102 disk JBOD from/to the SAS9305-16e.
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
(cherry picked from commit e3c5965c25)
When a DMA chain can't be loaded, set the state to STATE_INQUEUE so that
the mp[rs]_complete_command can properly fail the command.
Sponsored by: Netflix
(cherry picked from commit 33755dbb20)
When the mpr(4) and mps(4) drivers probe a SATA device, they issue an
ATA Identify command (via mp{s,r}sas_get_sata_identify()) before the
target is fully setup in the driver. The drivers wait for completion of
the identify command, and have a 5 second timeout. If the timeout
fires, the command is marked with the SATA_ID_TIMEOUT flag so it can be
freed later.
That is where the use-after-free problem comes in. Once the ATA
Identify times out, the driver sends a target reset, and then frees any
identify commands that have timed out. But, once the target reset
completes, commands that were queued to the drive are returned to the
driver by the controller.
At that point, the driver (in mp{s,r}_intr_locked()) looks up the
command descriptor for that particular SMID, marks it CM_STATE_BUSY and
sends it on for completion handling.
The problem at this stage is that the command has already been freed,
and put on the free queue, so its state is CM_STATE_FREE. If INVARIANTS
are turned on, we get a panic as soon as this command is allocated,
because its state is no longer CM_STATE_FREE, but rather CM_STATE_BUSY.
So, the solution is to not free ATA Identify commands that get stuck
until they actually return from the controller. Hopefully this works
correctly on older firmware versions. If not, it could result in
commands hanging around indefinitely. But, the alternative is a
use-after-free panic or assertion (in the INVARIANTS case).
This also tightens up the state transitions between CM_STATE_FREE,
CM_STATE_BUSY and CM_STATE_INQUEUE, so that the state transitions happen
once, and we have assertions to make sure that commands are in the
correct state before transitioning to the next state. Also, for each
state assertion, we print out the current state of the command if it is
incorrect.
mp{s,r}.c: Add a new sysctl variable, dump_reqs_alltypes,
that controls the behavior of the dump_reqs sysctl.
If dump_reqs_alltypes is non-zero, it will dump
all commands, not just the commands that are in the
CM_STATE_INQUEUE state. (You can see the commands
that are in the queue by using mp{s,r}util debug
dumpreqs.)
Make sure that the INQUEUE -> BUSY state transition
happens in one place, the mp{s,r}_complete_command
routine.
mp{s,r}_sas.c: Make sure we print the current command type in
command state assertions.
mp{s,r}_sas_lsi.c:
Add a new completion handler,
mp{s,r}sas_ata_id_complete. This completion
handler will free data allocated for an ATA
Identify command and free the command structure.
In mp{s,r}_ata_id_timeout, do not set the command
state to CM_STATE_BUSY. The command is still in
queue in the controller. Since we were blocking
waiting for this command to complete, there was
no completion handler previously. Set the
completion handler, so that whenever the command
does come back, it will get freed properly.
Do not free ATA Identify commands that have timed
out in mp{s,r}sas_add_device(). Wait for them
to actually come back from the controller.
mp{s,r}var.h: Add a dump_reqs_alltypes variable for the new
dump_reqs_alltypes sysctl.
Make sure we print the current state for state
transition asserts.
This was tested in the Spectra Logic test bed (as described in the
review), as well Netflix's Open Connect fleet (where panics dropped from
a dozen or two a month to zero).
Reviewed by: imp@ (who is handling the commit with ken's OK)
Sponsored by: Spectra Logic
Differential Revision: https://reviews.freebsd.org/D25476
(cherry picked from commit 175ad3d003)
When adjusting resources we should write updated window base/limit into
the registers. Without this newly added address range won't be routed
through the bridge properly.
Use MIN()/MAX() against current window base/limit to not shrink it on
the other side if the window is shared by several resources.
Align passed resource start/end to the set window granularity to keep
it properly aligned. Currently this is mostly called by other bridges
having the same window alignment, but it may be change one day.
Reviewed by: jrtc27, jhb
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D31693
If we allocate a new window for a bridge rather than reusing an existing
one set up by firmware to cover all the devices then the new window only
includes the range needed for the first device to allocate the resource.
If a request comes in to adjust this resource in order to extend a
downstream window for another device then this will fail as the rman
doesn't have any space, so we must first grow the bridge's own window.
This is needed to support successfully attaching more than one PCI
device on SiFive's HiFive Unmatched, which has the following topology:
Root Port <---> Bridge <---> Bridge <-+-> Bridge <---> (Unused)
(pcib0) (pcib1) (pcib2) | (pcib3)
+-> Bridge <---> xHCI
| (pcib4)
+-> Bridge <---> M.2 E-key
| (pcib5)
+-> Bridge <---> M.2 M-key
| (pcib6)
+-> Bridge <---> x16 slot
(pcib7)
Without this, the xHCI endpoint successfully attaches but NVMe M.2 M-key
endpoint fails to attach as, when its adjacent bridge (pcib6) attempts
to allocate a window from its parent (pcib2) on the other side of the
switch, its parent attempts to grow its own window by calling
bus_adjust_resource on its own parent (pcib1) which fails to call the
root port device (pcib0) to request more memory to grow its own window.
Had the root port been directly connected to the switch without the
bridge in the middle then the existing code would have worked, but the
extra hop broke it.
Reviewed by: jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31035
