The interface's queues are functional after VI_INIT_DONE (which is short
of interface-up) and that's all that's needed for t4_tom to communicate
with the chip.
Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications
pci_if.
This allows bhnd(4) to manage per-device state (such as per-core
pmu/clock refcounting) on behalf of subclass driver instances.
Approved by: re (gjb), adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6959
Replaces use of DEVICE_IDENTIFY with explicit enumeration of chipc
child devices using the chipc capability structure.
This is a precursor to PMU support, which requires more complex resource
assignment handling than achievable with the static device name-based
hints table.
Reviewed by: Michael Zhilin <mizkha@gmail.com> (Broadcom MIPS support)
Approved by: re (gjb), adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6896
Replace m_getcl() with m_get2(); this fixes 'frame too long'
messages for frames, which are longer than MCLBYTES
(can be easily triggered when A-MSDU is used).
Tested with RTL8188CUS (AP) and RTL8188EU (STA).
Approved by: re (marius)
Free data buffers every time when device is stopped, not when
it is detached; they are allocated at the initialization stage.
How-to-reproduce:
1) ifconfig wlan0 create wlandev urtwn0 up
2) vmstat -m | grep USBdev
3) service netif restart
4) vmstat -m | grep USBdev
Also, remove usbd_transfer_drain() call; it is already called by
usbd_transfer_unsetup().
Tested with RTL8188CUS, STA mode.
Approved by: re (marius)
vcxgbe/vcxl interfaces and retire the 'n' interfaces. The main
cxgbe/cxl interfaces and tunables related to them are not affected by
any of this and will continue to operate as usual.
The driver used to create an additional 'n' interface for every
cxgbe/cxl interface if "device netmap" was in the kernel. The 'n'
interface shared the wire with the main interface but was otherwise
autonomous (with its own MAC address, etc.). It did not have normal
tx/rx but had a specialized netmap-only data path. r291665 added
another set of virtual interfaces (the 'v' interfaces) to the driver.
These had normal tx/rx but no netmap support.
This revision consolidates the features of both the interfaces into the
'v' interface which now has a normal data path, TOE support, and native
netmap support. The 'v' interfaces need to be created explicitly with
the hw.cxgbe.num_vis tunable. This means "device netmap" will not
result in the automatic creation of any virtual interfaces.
The following tunables can be used to override the default number of
queues allocated for each 'v' interface. nofld* = 0 will disable TOE on
the virtual interface and nnm* = 0 to will disable native netmap
support.
# number of normal NIC queues
hw.cxgbe.ntxq_vi
hw.cxgbe.nrxq_vi
# number of TOE queues
hw.cxgbe.nofldtxq_vi
hw.cxgbe.nofldrxq_vi
# number of netmap queues
hw.cxgbe.nnmtxq_vi
hw.cxgbe.nnmrxq_vi
hw.cxgbe.nnm{t,r}xq{10,1}g tunables have been removed.
--- tl;dr version ---
The workflow for netmap on cxgbe starting with FreeBSD 11 is:
1) "device netmap" in the kernel config.
2) "hw.cxgbe.num_vis=2" in loader.conf. num_vis > 2 is ok too, you'll
end up with multiple autonomous netmap-capable interfaces for every
port.
3) "dmesg | grep vcxl | grep netmap" to verify that the interface has
netmap queues.
4) Use any of the 'v' interfaces for netmap. pkt-gen -i vcxl<n>... .
One major improvement is that the netmap interface has a normal data
path as expected.
5) Just ignore the cxl interfaces if you want to use netmap only. No
need to bring them up. The vcxl interfaces are completely independent
and everything should just work.
---------------------
Approved by: re@ (gjb@)
Relnotes: Yes
Sponsored by: Chelsio Communications
This patch addes missing implementation of BHND_BUS_RESET_CORE function for BCMA.
The reset procedure is very simple: enable reset mode, stop clocking,
enable clocking & force clock gating, disable reset mode, stop clock gating.
Tested:
* (michael) Tested on ASUS RT-N53 for enabling/reset USB core
Submitted by: Michael Zhilin <mizhka@gmail.com>
Approved by: re (gjb)
We also need to consider the size of large firmware commands in iwm_alloc_tx_ring(),
in the dma tag creation, when qid == IWM_MVM_CMD_QUEUE. The old code apparently
only allocated a 2KB (MCLBYTES) sized buffer when it actually expected 4KB.
Submitted by: Imre Vadasz <imre@vdsz.com>
Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D6824
(Together with other iwm(4) memory leak fixes) Memory leakage in M_DEVBUF
is now at ca. 2KB for each iwm(4) module load/unload cycle.
Submitted by: Imre Vadasz <imre@vdsz.com>
Approved by: re (gjb)
Obtained from: DragonflyBSD git eaf551a1d464c643e98ce5781971dd32124e9af1
Differential Revision: https://reviews.freebsd.org/D6819
* When bus_dmamem_alloc is used, the bus_dmamap_t is usually set to NULL, so
we were never actually freeing any dma memory allocations done via
iwm_dma_contig_alloc(). So we should check dma->vaddr instead of dma->map here.
* Also, the dmamap is actually supposed to be invalidated as part of
bus_dmamem_free(), so bus_dmamap_destroy() is never needed here.
Submitted by: Imre Vadasz <imre@vdsz.com>
Approved by: re (gjb)
Obtained from: DragonflyBSD git ef2b29a7ba6ca8a9d2c82ab591c0622227ff84cb
ic_macaddr is only used for the initial mac address provided by NVM. We should
rather use vap->iv_myaddr when vap != NULL, to allow the MAC address
to be changed later with ifconfig(8).
Submitted by: Imre Vadasz <imre@vdsz.com>
Reviewed by: avos
Approved by: re (gjb)
Obtained from: DragonflyBSD git 4aee7a78275676d22d14c04177bd0c9377d91478
Differential Revision: https://reviews.freebsd.org/D6743
I keep asking myself "what do these fields mean" and so now I've clarified
it for myself.
Tested:
* Reading the comments, going "a-ha!" a couple times.
Approved by: re (gjb)
version of the XHCI specification. Make sure the code can handle the
maximum number of allowed scratch pages.
Submitted by: Shichun_Ma@Dell.com
Approved by: re (hrs)
MFC after: 1 week
File and disk-backed I/O requests store counts of read/written disk
blocks in each AIO job so that they can be charged to the thread that
completes an AIO request via aio_return() or aio_waitcomplete(). This
change extends AIO jobs to store counts of received/sent messages and
updates socket backends to set these counts accordingly. Note that
the socket backends are careful to only charge a single messages for
each AIO request even though a single request on a blocking socket might
invoke sosend or soreceive multiple times. This is to mimic the
resource accounting of synchronous read/write.
Adjust the UNIX socketpair AIO test to verify that the message resource
usage counts update accordingly for aio_read and aio_write.
Approved by: re (hrs)
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D6911
It turns out that getting decent performance requires stacking the TX
FIFO a little more aggressively.
* Ensure that when we complete a frame, we attempt to push a new frame
into the FIFO so TX is kept as active as it needs to be
* Be more aggressive about batching non-aggregate frames into a single
TX FIFO slot. This "fixes" TDMA performance (since we only get one
TX FIFO slot ungated per DMA beacon alert) but it does this by pushing
a whole lot of work into the TX FIFO slot.
I'm not /entirely/ pleased by this solution, but it does fix a whole bunch
of corner case issues in the transmit side and fix TDMA whilst I'm at it.
I'll go revisit transmit packet scheduling in ath(4) post 11.
Tested:
* AR9380, STA mode
* AR9580, hostap mode
* AR9380, TDMA client mode
Approved by: re (hrs)
than removing the network interfaces first. This change is rather larger
and convoluted as the ordering requirements cannot be separated.
Move the pfil(9) framework to SI_SUB_PROTO_PFIL, move Firewalls and
related modules to their own SI_SUB_PROTO_FIREWALL.
Move initialization of "physical" interfaces to SI_SUB_DRIVERS,
move virtual (cloned) interfaces to SI_SUB_PSEUDO.
Move Multicast to SI_SUB_PROTO_MC.
Re-work parts of multicast initialisation and teardown, not taking the
huge amount of memory into account if used as a module yet.
For interface teardown we try to do as many of them as we can on
SI_SUB_INIT_IF, but for some this makes no sense, e.g., when tunnelling
over a higher layer protocol such as IP. In that case the interface
has to go along (or before) the higher layer protocol is shutdown.
Kernel hhooks need to go last on teardown as they may be used at various
higher layers and we cannot remove them before we cleaned up the higher
layers.
For interface teardown there are multiple paths:
(a) a cloned interface is destroyed (inside a VIMAGE or in the base system),
(b) any interface is moved from a virtual network stack to a different
network stack ("vmove"), or (c) a virtual network stack is being shut down.
All code paths go through if_detach_internal() where we, depending on the
vmove flag or the vnet state, make a decision on how much to shut down;
in case we are destroying a VNET the individual protocol layers will
cleanup their own parts thus we cannot do so again for each interface as
we end up with, e.g., double-frees, destroying locks twice or acquiring
already destroyed locks.
When calling into protocol cleanups we equally have to tell them
whether they need to detach upper layer protocols ("ulp") or not
(e.g., in6_ifdetach()).
Provide or enahnce helper functions to do proper cleanup at a protocol
rather than at an interface level.
Approved by: re (hrs)
Obtained from: projects/vnet
Reviewed by: gnn, jhb
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D6747
1) Unload mbuf instead of descriptor in rtwn_tx_done().
2) Add more synchronization for device visible mappings before
touching the memory.
3) Improve watchdog timer logic.
Reported and tested by: mva
Approved by: re (gjb)
Remove frames from active/pending Tx queues and free related node
references when vap is destroyed to prevent various use-after-free
scenarios.
Reported and tested by: Aleksander Alekseev <afiskon@devzen.ru>
PR: 208632
Approved by: re (gjb)
Use MPI2_IOCSTATUS_MASK when checking IOCStatus to mask off the log bit, and
make a few more things endian-safe.
- Fix possible use of invalid pointer.
It was possible to use an invalid pointer to get the target ID value. To fix
this, initialize a local Target ID variable to an invalid value and change that
variable to a valid value only if the pointer to the Target ID is not NULL.
- No need to set the MPSSAS_SHUTDOWN flag because it's never used.
- done_ccb pointer can be used if it is NULL.
To prevent this, move check for done_ccb == NULL to before done_ccb is used in
mpssas_stop_unit_done().
- Disks can go missing until a reboot is done in some cases.
This is due to the DevHandle not being released, which causes the Firmware to
not allow that disk to be re-added.
Reviewed by: ken
Approved by: re (gjb), ken, scottl, ambrisko (mentors)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D6872
This started showing up when doing lots of aggregate traffic. For TDMA it's
always no-ACK traffic and I didn't notice this, and I didn't notice it
when doing 11abg traffic as it didn't fail enough in a bad way to trigger
this.
This showed up as the fifo depth being < 0.
Eg:
Jun 19 09:23:07 gertrude kernel: ath0: ath_tx_edma_push_staging_list: queued 2 packets; depth=2, fifo depth=1
Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1, bf=0xfffffe000385f068, start=1, end=1
Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1: FIFO depth is now 0 (1)
Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1, bf=0xfffffe0003866fe8, start=0, end=1
Jun 19 09:23:07 gertrude kernel: ath0: ath_edma_tx_processq: Q1: FIFO depth is now -1 (0)
So, clear the flags before adding them to a TX queue, so if they're
re-added for the retransmit path it'll clear whatever they were and
not double-account the FIFOEND flag. Oops.
Tested:
* AR9380, STA mode, 11n iperf testing (~130mbit)
Approved by: re (delphij)
It turns out the frame scheduling policies (eg DBA_GATED) operate on
a single TX FIFO entry. ASAP scheduling is fine; those frames always
go out.
DBA-gated sets the TX queue ready when the DBA timer fires, which triggers
a beacon transmit. Normally this is used for content-after-beacon queue
(CABQ) work, which needs to burst out immediately after a beacon.
(eg broadcast, multicast, etc frames.) This is a general policy that you
can use for any queue, and Sam's TDMA code uses it.
When DBA_GATED is used and something like say, an 11e TX burst window,
it only operates on a single TX FIFO entry. If you have a single frame
per TX FIFO entry and say, a 2.5ms long burst window (eg TDMA!) then it'll
only burst a single frame every 2.5ms. If there's no gating (eg ASAP) then
the burst window is fine, and multiple TX FIFO slots get used.
The CABQ code does pack in a list of frames (ie, the whole cabq) but
up until this commit, the normal TX queues didn't. It showed up when
I started to debug TDMA on the AR9380 and later.
This commit doesn't fix the TDMA case - that's still broken here, because
all I'm doing here is allowing 'some' frames to be bursting, but I'm
certainly not filling the whole TX FIFO slot entry with frames.
Doing that 'properly' kind of requires me to take into account how long
packets should take to transmit and say, doing 1.5 or something times that
per TX FIFO slot, as if you partially transmit a slot, when it's next
gated it'll just finish that TX FIFO slot, then not advance to the next
one.
Now, I /also/ think queuing a new packet restarts DMA, but you have to
push new frames into the TX FIFO. I need to experiment some more with
this because if it's really the case, I will be able to do TDMA support
without the egregious hacks I have in my local tree. Sam's TDMA code
for previous chips would just kick the TXE bit to push along DMA
again, but we can't do that for EDMA chips - we /have/ to push a new
frame into the TX FIFO to restart DMA. Ugh.
Tested:
* AR9380, STA mode
* AR9380, hostap mode
* AR9580, hostap mode
Approved by: re (gjb)
This allows IPv6 link local addresses (and other IPv6 functionality) to work.
PR: 210355
Submitted by: Steve Wahl and David Bright (both at Dell Inc.)
Reviewed by: cem, mav
Tested by: mav (on Intel hardware)
Approved by: re (kib)
MFC after: 5 days
Sponsored by: Dell Inc.
Differential Revision: https://reviews.freebsd.org/D6885
Maps Sonics/OCP per-core address spaces to bcma(4)-compatible port/region
identifiers.
This permits the use of common address map identifiers in bhnd device
drivers, independent of the underlying interconnect type.
Approved by: re (gjb), adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6850
- Delete all chipc children on attachment failure.
- Added missing bhnd_nexus bhnd_bus_deactivate_resource implementation.
- Drop a CHIPC_UNLOCK() accidentally left behind after lifting
synchronization into the chipc region refcounting API.
- Fix re-allocation of chipc resources. Previously, the resource ID was
reset to -1 on release, preventing later re-allocation.
Approved by: re (gjb), adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6849
supported, e.g. CPUID or MSR, return ENODEV from the ioctl which needs
that feature.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Approved by: re (hrs)
Inserting a full mbuf with an external cluster into the socket buffer
resulted in sbspace() returning -MLEN. However, since sb_hiwat is
unsigned, the -MLEN value was converted to unsigned in comparisons. As a
result, the socket buffer was never autosized. Note that sb_lowat is signed
to permit direct comparisons with sbspace(), but sb_hiwat is unsigned.
Follow suit with what tcp_output() does and compare the value of sbused()
with sb_hiwat instead.
Approved by: re (gjb)
Sponsored by: Chelsio Communications
This reduces the size of kaiocb slightly. I've also added some generic
fields that other backends can use in place of the BIO-specific fields.
Change the socket and Chelsio DDP backends to use 'backend3' instead of
abusing _aiocb_private.status directly. This confines the use of
_aiocb_private to the AIO internals in vfs_aio.c.
Reviewed by: kib (earlier version)
Approved by: re (gjb)
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D6547
Release the hold on ep->com immediately after sending the RST. This
fixes a bug that sometimes leaves userspace iWARP tools hung when the
user presses ^C.
Submitted by: Krishnamraju Eraparaju @ Chelsio
Approved by: re (gjb@)
Sponsored by: Chelsio Communications
When allocating a new mbuf or bus_dmamap_load()-ing it fails,
we can just keep the old mbuf since we are dropping that packet anyway.
Instead of doing bus_dmamap_create() and bus_dmamap_destroy() all the time,
create an extra bus_dmamap_t which we can use to safely try
bus_dmamap_load()-ing the new mbuf. On success we just swap the spare
bus_dmamap_t with the data->map of that ring entry.
Tested:
Tested with Intel AC7260, verified with vmstat -m that new kernel no
longer visibly leaks memory from the M_DEVBUF malloc type.
Before, leakage was 1KB every few seconds while ping(8)-ing over the wlan
connection.
Submitted by: Imre Vadasz <imre@vdsz.com>
Approved by: re@
Obtained from: DragonflyBSD.git cc440b26818b5dfdd9af504d71c1b0e6522b53ef
Differential Revision: https://reviews.freebsd.org/D6742
For DWC_GMAC_ALT_DESC implementations, the multicast hash table has only
64 entries. Instead of 8 registers starting at 0x500, a pair of registers
at 0x08 and 0x0c are used instead.
Approved by: re (hrs)
Submitted by: Guy Yur <guyyur@gmail.com>
Some later code I'll commit pushes lists of frames into the EDMA TX
FIFO, rather than a single frame at a time. The CABQ code already
pushes frame lists, but it turns out we should actually be doing it
in general or performance tanks. :(
Since key table is cleared on every device shutdown,
static WEP keys (which are set only once) need to be
reinstalled manually every time when device starts running.
Tested with RTL8188EU, STA (all ciphers) / IBSS (WPA-none) modes.
r298930 removed the inittodr call, but it seems like this prevents
"calcru: runtime went backwards ..." messages from occasionally appearing
when resuming from migration.
Reported by: Karl Pielorz <kpielorz@tdx.co.uk>
Sponsored by: Citrix Systems R&D
ticks are signed int and if statistics is not updated for a long time
(more than INT_MAX ticks, but less than UINT_MAX) difference becomes
negative and less than hz for a long time.
Other option to repeat is simply load driver (which initializes
timestamps to 0) when ticks are negative.
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D6777
