Remap MSI-X messages over available slots rather than falling back to
legacy INTx when fewer MSI-X slots are available than were requested.
N.B. the Linux driver does *not* do this.
To aid in testing, a tunable 'hw.ntb.force_remap_mode' has been added.
It defaults to off (0). When the tunable is enabled and sufficient
slots were available, the driver restricts the number of slots by one
and remaps the MSI-X messages over the remaining slots.
In case this is actually not okay (as I don't yet have access to this
hardware to test), a tunable 'hw.ntb.prefer_intx_to_remap' has been
added. It defaults to off (0). When the tunable is enabled and fewer
slots are available than requested, fall back to legacy INTx mode rather
than attempting to remap MSI-X messages.
Suggested by: jhb
Reviewed by: jhb (earlier version)
Sponsored by: EMC / Isilon Storage Division
Consumers that registered on this bit would never see a callback and it
is likely a mistake.
This does not affect if_ntb, which limits itself to a single doorbell
callback.
The names don't line up 100% with Linux. Our routines are named
ntb_setup_interrupts, ntb_setup_xeon_msix, ntb_setup_soc_msix, and
ntb_setup_legacy_interrupt. Linux SNB = FreeBSD Xeon; Linux BWD =
FreeBSD SOC. Original Linux commit log:
This is an cleanup effort to make ntb_setup_msix() more readable - use
ntb_setup_bwd_msix() to init MSI-Xs on BWD hardware and
ntb_setup_snb_msix() - on SNB hardware.
Function ntb_setup_snb_msix() also initializes MSI-Xs the way it should
has been done - looping pci_enable_msix() until success or failure.
Authored by: Alexander Gordeev
Obtained from: Linux (Dual BSD/GPL driver)
Sponsored by: EMC / Isilon Storage Division
Provide a better event interface between the client and transport.
Authored by: Jon Mason
Obtained from: Linux (Dual BSD/GPL driver)
Sponsored by: EMC / Isilon Storage Division
according to the Cortex-A8 TRM r3p2 section 3.2.49.
The A8 list differs from the "ARM-v7 common" list, given the A8
was an earlier model.
There is still more work to be done for other Cortex-Ax version as
andrew points out, but I am just trying to fix A8 for now for teaching.
MFC after: 2 weeks
Sponsored by: DARPA/AFRL
Obtained from: Cambridge/L41
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D3876
Enable Snoop from Primary to Secondary side on BAR23 and BAR45 on all
TLPs. Previously, Snoop was only enabled from Secondary to Primary
side. This can have a performance improvement on some workloads.
Also, make the code more obvious about how the link is being enabled.
Authored by: Jon Mason
Obtained from: Linux (Dual BSD/GPL driver)
Sponsored by: EMC / Isilon Storage Division
Add a comment describing the necessary ordering of modifications to the
NTB Limit and Base registers.
Authored by: Jon Mason
Obtained from: Linux (Dual BSD/GPL driver)
Sponsored by: EMC / Isilon Storage Division
A WARN_ON is being hit in ntb_qp_link_work due to the NTB transport link
being down while the ntb qp link is still active. This is caused by the
transport link being brought down prior to the qp link worker thread
being terminated. To correct this, shutdown the qp's prior to bringing
the transport link down. Also, only call the qp worker thread if it is
in interrupt context, otherwise call the function directly.
Authored by: Jon Mason
Obtained from: Linux (Dual BSD/GPL driver)
Sponsored by: EMC / Isilon Storage Division
The Xeon NTB-RP setup, the transparent side does not get a link up/down
interrupt. Since the presence of a NTB device on the transparent side
means that we have a NTB link up, we can work around the lack of an
interrupt by simply calling the link up function to notify the upper
layers.
Authored by: Jon Mason
Obtained from: Linux (Dual BSD/GPL driver)
Sponsored by: EMC / Isilon Storage Division
Modifications to the 14th bit of the B2BDOORBELL register will not be
mirrored to the remote system due to a hardware issue. To get around
the issue, shrink the number of available doorbell bits by 1. The max
number of doorbells was being used as a way to referencing the Link
Doorbell bit. Since this would no longer work, the driver must now
explicitly reference that bit.
This does not affect the xeon_errata_workaround case, as it is not using
the b2bdoorbell register.
Authored by: Jon Mason
Obtained from: Linux (Dual BSD/GPL driver)
Sponsored by: EMC / Isilon Storage Division
NTB-RP is not a supported configuration on BWD hardware. Remove the
code attempting to set it up.
Authored by: Jon Mason
Obtained from: Linux (dual BSD/GPL driver)
Sponsored by: EMC / Isilon Storage Division
This commit does not actually add NTB-RP support. Mostly it serves to
shuffle code around to match the Linux driver. Original Linux commit
log follows:
Add support for Non-Transparent Bridge connected to a PCI-E Root Port on
the remote system (also known as NTB-RP mode). This allows for a NTB
enabled system to be connected to a non-NTB enabled system/slot.
Modifications to the registers and BARs/MWs on the Secondary side by the
remote system are reflected into registers on the Primary side for the
local system. Similarly, modifications of registers and BARs/MWs on
Primary side by the local system are reflected into registers on the
Secondary side for the Remote System. This allows communication between
the 2 sides via these registers and BARs/MWs.
Note: there is not a fix for the Xeon Errata (that was already worked
around in NTB-B2B mode) for NTB-RP mode. Due to this limitation, NTB-RP
will not work on the Secondary side with the Xeon Errata workaround
enabled. To get around this, disable the workaround via the
xeon_errata_workaround=0 modparm. However, this can cause the hang
described in the errata.
Authored by: Jon Mason
Obtained from: Linux
Sponsored by: EMC / Isilon Storage Division
Many variable names in the NTB driver refer to the primary or secondary
side. However, these variables will be used to access the reverse case
when in NTB-RP mode. Make these names more generic in anticipation of
NTB-RP support.
Authored by: Jon Mason
Obtained from: Linux
Sponsored by: EMC / Isilon Storage Division
The BWD NTB device will drop the link if an error is encountered on the
point-to-point PCI bridge. The link will stay down until all errors are
cleared and the link is re-established. On link down, check to see if
the error is detected, if so do the necessary housekeeping to try and
recover from the error and reestablish the link.
There is a potential race between the 2 NTB devices recovering at the
same time. If the times are synchronized, the link will not recover and
the driver will be stuck in this loop forever. Add a random interval to
the recovery time to prevent this race.
Authored by: Jon Mason
Obtained from: Linux
Sponsored by: EMC / Isilon Storage Division
There is a Xeon hardware errata related to writes to SDOORBELL or B2BDOORBELL
in conjunction with inbound access to NTB MMIO Space, which may hang the
system. To workaround this issue, use one of the memory windows to access the
interrupt and scratch pad registers on the remote system. This bypasses the
issue, but removes one of the memory windows from use by the transport. This
reduction of MWs necessitates adding some logic to determine the number of
available MWs.
Since some NTB usage methodologies may have unidirectional traffic, the ability
to disable the workaround via modparm has been added.
See BF113 in
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-c5500-c3500-spec-update.pdf
See BT119 in
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-family-spec-update.pdf
Authored by: Jon Mason
Obtained from: Linux
Sponsored by: EMC / Isilon Storage Division
Due to ambiguous documentation, the USD/DSD identification is backward
when compared to the setting in BIOS. Correct the bits to match the
BIOS setting.
Authored by: Jon Mason
Obtained from: Linux
Sponsored by: EMC / Isilon Storage Division
The NTB Xeon hardware has 16 scratch pad registers and 16 back-to-back
scratch pad registers. Correct the #define to represent this and update
the variable names to reflect their usage.
Authored by: Jon Mason
Obtained from: Linux
Sponsored by: EMC / Isilon Storage Division
This doesn't free the mbuf upon error; the driver ic_raw_xmit method is still
doing that.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3774
Move error handling into ieee80211_parent_xmitpkt() instead of spreading it
between functions.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3772
* Create ieee80211_free_mbuf() which frees a list of mbufs.
* Use it in the fragment transmit path and ath / uath transmit paths.
* Call it in xmit_pkt() if the transmission fails; otherwise fragments
may be leaked.
This should be a big no-op.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3769
The system will appear to lockup for long periods of time due to the NTB
driver spending too much time in memcpy. Avoid this by reducing the
number of packets that can be serviced on a given interrupt.
Authored by: Jon Mason
Obtained from: Linux
Sponsored by: EMC / Isilon Storage Division
The ring logic of the NTB receive buffer/transmit memory window requires
there to be at least 2 payload sized allotments. For the minimal size
case, split the buffer into two and set the transport_mtu to the
appropriate size.
Authored by: Jon Mason
Obtained from: Linux
Sponsored by: EMC / Isilon Storage Division
If the NTB link toggles, the driver could stop receiving due to the
tx_index not being set to 0 on the transmitting size on a link-up event.
This is due to the driver expecting the incoming data to start at the
beginning of the receive buffer and not at a random place.
Authored by: Jon Mason
Obtained from: Linux
Sponsored by: EMC / Isilon Storage Division
Each link-up will allocate a new NTB receive buffer when the NTB
properties are negotiated with the remote system. These allocations did
not check for existing buffers and thus did not free them. Now, the
driver will check for an existing buffer and free it if not of the
correct size, before trying to alloc a new one.
Authored by: Jon Mason
Obtained from: Linux
Sponsored by: EMC / Isilon Storage Division
64bit BAR sizes are permissible with an NTB device. To support them
various modifications and clean-ups were required, most significantly
using 2 32bit scratch pad registers for each BAR.
Also, modify the driver to allow more than 2 Memory Windows.
Authored by: Jon Mason
Obtained from: Linux
Sponsored by: EMC / Isilon Storage Division
->remote_rx_info and ->rx_info are struct ntb_rx_info pointers. If we
add sizeof(struct ntb_rx_info) then it goes too far.
Authored by: Dan Carpenter
Obtained from: Linux
Sponsored by: EMC / Isilon Storage Division
This change fixes some amount of -Wsign-conversion and -Wconversion warnings
and sets correct sizes for some variables (as a result, some loop counters
were touched too).
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3763
This is roughly the iw_cxgbe equivalent of
be13b2dff8
-----------------
RDMA/cxgb4: Connect_request_upcall fixes
When processing an MPA Start Request, if the listening endpoint is
DEAD, then abort the connection.
If the IWCM returns an error, then we must abort the connection and
release resources. Also abort_connection() should not post a CLOSE
event, so clean that up too.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
-----------------
Submitted by: Krishnamraju Eraparaju at chelsio dot com.
This was off because the net80211 aggregation code was using the same
state pointers for both fast frames and ampdu tx support which led to some
pretty unfortunate panic-y behaviour.
Now that net80211 doesn't panic, let's flip this back on.
It doesn't (yet) do the horrific sounding thing of A-MPDU aggregates
of fast frames; that'll come next. It's a pre-requisite to supporting
AMSDU + AMPDU anyway, which actually speeds things up quite considerably
(think packing lots of little ACK frames into a single AMSDU.)
Tested:
* QCA955x SoC, AP mode
* AR5416, STA mode
* AR9170, STA mode (with local fast frame patches)
these functions are thin wrappers around calling the hardware-layer driver,
but some of them do sanity checks and return an error. Since the hardware
layer can only return IIC_Exxxxx status values, the iicbus helper functions
must also adhere to that, so that drivers at higher layers can assume that
any non-zero status value is an IIC_Exxxx value that provides details about
what happened at the hardware layer (sometimes those details are important
for certain slave drivers).
errno values that are at least vaguely equivelent. Also add a new status
value, IIC_ERESOURCE, to indicate a failure to acquire memory or other
required resources to complete a transaction.
The IIC_Exxxxxx values are supposed to communicate low-level details of the
i2c transaction status between the lowest-layer hardware driver and
higher-layer bus protocol and device drivers for slave devices on the bus.
Most of those slave drivers just return all status values from the lower
layers directly to their callers, resulting in crazy error reporting from a
user's point of view (things like timeouts being reported as "no such
process"). Now there's a helper function to make it easier to start
cleaning up all those drivers.
Make it clearer what each one means in the comments that define them.
IIC_BUSBSY was used in many places to mean two different things, either
"someone else has reserved the bus so you have to wait until they're done"
or "the signal level on the bus was not in the state I expected before/after
issuing some command".
Now IIC_BUSERR is used consistantly to refer to protocol/signaling errors,
and IIC_BUSBSY refers to ownership/reservation of the bus.
perform a stop operation on the bus if there was an error, otherwise the
bus will remain hung forever. Consistantly use 'if (error != 0)' style in
the function.
The current Xen console driver is crashing very quickly when using it on
an ARM guest. This is because the console lock is recursive and it may
lead to recursion on the tty lock and/or corrupt the ring pointer.
Furthermore, the console lock is not always taken where it should be and has
to be released too early because of the way the console has been designed.
Over the years, code has been modified to support various new features but
the driver has not been reworked.
This new driver has been rewritten with the idea of only having a small set
of specific function to write either via the shared ring or the hypercall
interface.
Note that HVM support has been left aside for now because it requires
additional features which are not yet supported. A follow-up patch will be
sent with HVM guest support.
List of items that may be good to have but not mandatory:
- Avoid to flush for each character written when using the tty
- Support multiple consoles
Submitted by: Julien Grall <julien.grall@citrix.com>
Reviewed by: royger
Differential Revision: https://reviews.freebsd.org/D3698
Sponsored by: Citrix Systems R&D
Use direct dispatch into the destination hardware ring instead of using
a staging queue.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3757
Pull the latest headers for Xen which allow us to add support for ARM and
use new features in FreeBSD.
This is a verbatim copy of the xen/include/public so every headers which
don't exits anymore in the Xen repositories have been dropped.
Note the interface version hasn't been bumped, it will be done in a
follow-up. Although, it requires fix in the code to get it compiled:
- sys/xen/xen_intr.h: evtchn_port_t is already defined in the headers so
drop it.
- {amd64,i386}/include/intr_machdep.h: NR_EVENT_CHANNELS now depends on
xen/interface/event_channel.h, so include it.
- {amd64,i386}/{amd64,i386}/support.S: It's not neccessary to include
machine/intr_machdep.h. This is also fixing build compilation with the
new headers.
- dev/xen/blkfront/blkfront.c: The typedef for blkif_request_segmenthas
been dropped. So directly use struct blkif_request_segment
Finally, modify xen/interface/xen-compat.h to throw a preprocessing error if
__XEN_INTERFACE_VERSION__ is not set. This is allow us to catch any file
where xen/xen-os.h is not correctly included.
Submitted by: Julien Grall <julien.grall@citrix.com>
Reviewed by: royger
Differential Revision: https://reviews.freebsd.org/D3805
Sponsored by: Citrix Systems R&D
'rdrand' instruction may occasionally not return random numbers, in
spite of looping attempts to do so. The reusult is a KASSERT/panic.
Reluctantly accept this state-of-affairs, but make a noise about it.
if this 'noise' spams the console, it may be time to discontinue
using that source.
This is written in a general way to account for /any/ source that
might not supply random numbers when required.
Submitted by: jkh (report and slightly different fix)
Approved by: so (/dev/random blanket)
* Remove obsolete drm_agp_*_memory() prototypes.
* Fix comment in drm_fops.c (outisde -> outside).
* Fix some formatting issues in drm_stub.c (spaces -> tabs).
* Add missing case statement (gen == 3) in intel_gpu_reset().
* Restore pci_enable_busmaster() call in the init path (fixes gpu hang on i945GM).
* Replace M_WAITOK with M_NOWAIT when the return value of malloc is checked (may be incorrect).
Submitted by: <s3erios@gmail.com>
Reviewed by: dumbbell
Approved by: dumbbell
Differential Revision: https://reviews.freebsd.org/D3413
Now run(4) fetches parameters from ic->ic_wme.wme_params array, which is never initialized
(and can be safely removed). This patch replaces &ic->ic_wme.wme_params with
&ic->ic_wme.wme_chanParams.cap_wmeParams (contains parameters for local station;
used by other drivers with WME support).
Tested:
* me: STA: run0: MAC/BBP RT5390 (rev 0x0502), RF RT5370 (MIMO 1T1R), address 38:83:45:11:78:ae
Now device will use retry limit, which is set via 'ifconfig <interface>
maxretry <number>'.
Tested:
* Tested on WUSB54GC, STA mode.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3689
The MAC can be fetched from the key struct.
I added the ndis updates to make it compile.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3657
This diff includes:
* Transmitter Addresses, Keys and TKIP MIC addition to the Security Key Table.
* Proper SEC Control Registers initialization and maintenance.
* Additional flags and values in TX descriptor, which are required for encryption support.
* Error checking in RX path.
Tested:
* Tested on WUSB54GC, STA (WEP, TKIP, CCMP), HOSTAP (CCMP) and IBSS (CCMP, WPA-None) modes.
* rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528, STA mode (CCMP+TKIP)
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3640
Note: I manually had to merge this; I merged in the "put beacon_offsets
into vap" commit before this.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3628
