This addresses kernel panic observed when sending SCSI UNMAP
commands to SATA disks attached to isci(4).
1) Flesh out callback routines to allocate/free buffers needed for
translating SCSI UNMAP data to ATA DSM data.
2) Add controller-level pool for storing buffers previously allocated
for UNMAP translation, to lessen chance of no buffer available
under memory pressure.
3) Ensure driver properly handles case where buffer pool is empty
and contigmalloc returns NULL.
Sponsored by: Intel
Reported by: Maksim Yevmenkin <max at netflix dot com>
Discussed with: scottl
MFC after: 3 days
evicted from the syncache but a later syncache_expand succeeds because
of syncookies. The TOE driver has to resort to more direct means to
install its hooks in the socket in this case.
the TOE driver reports that an active open failed. toe_connect_failed is
supposed to handle this but it should be provided the inpcb instead of the
tcpcb which may no longer be around.
Note: This is totally sub-optimal and a work in progress.
* Support filling an empty FIFO TXQ with frames from the ath_buf queue
in the ath_txq list. However, since there's (currently) no clean, easy
way to separate the frames that are in the FIFO versus just waiting,
the code waits for the FIFO to be totally empty before it attempts to
queue more. This is highly sub-optimal but is enough to get the ball
rolling.
* A _lot_ of the code assumes that the TX status is filled out in the
struct ath_buf bf_status field. So for now, memcpy() the completion over.
* None of the TX drain / reset routines will attempt to complete completed
frames before draining, so it can't be used for 802.11n TX aggregation.
(This won't work anyway, as the aggregation TX descriptor API hasn't
yet been converted; and that'll happen in some future commits.)
* Fix an issue where the FIFO counter wasn't being incremented, leading
to the queue logic just plain not working.
* HAL_EIO means "descriptor wasn't valid", versus "not finished, don't
continue." So don't stop processing descriptors when HAL_EIO is hit.
* Don't service frame completion from the beacon queue. It isn't currently
fully setup like a real queue and the first attempt at accessing the
queue lock will panic the kernel.
Tested:
* AR9380, STA mode
This commit is brought to you by said AR9380 in STA mode.
sizeof(struct ath_desc). This isn't correct for EDMA TX descriptors.
This popped up during iperf tests. Ping tests never created frames that
had enough segments to overflow into a second descriptor. However,
an iperf TCP test would do that after a few seconds; the second descriptor
would almost always certainly have garbage.
Tested:
* AR9380, STA mode
* AR9280, STA mode (802.11n TX, legacy TX)
EDMA code.
* create a new TX EDMA descriptor struct to represent TX EDMA descriptors
when doing debugging;
* implement an EDMA printing function which:
+ hardcodes the TX map size to 4 for now;
+ correctly prints out the number of segments - there's one descriptor
for up to 4 buffers (segments), not one for each segment;
+ print out 4 DS buffer and len pointers;
+ print out the correct number of DWORDs in the TX descriptor.
TODO:
* Remove all of the hard-coded stuff. Ew.
is marked correctly.
The existing logic assumed that the first descriptor is i == 0, which
doesn't hold for EDMA TX. In this instance, the first time filltxdesc()
is called can be up to i == 3.
So for a two-buffer descriptor:
* firstSeg is set to 0;
* lastSeg is set to 1;
* the ath_hal_filltxdesc() code will treat it as the last segment in
a descriptor chain and blank some of the descriptor fields, causing
the TX to stop.
When firstSeg is set to 1 (regardless of lastSeg), it overrides the
lastSeg setting. Thus, ath_hal_filltxdesc() won't blank out these
fields.
Tested: AR9380, STA mode. With this, association is successful.
Basically, this is automatic rx zero copy when feasible. TCP payload is
DMA'd directly into the userspace buffer described by the uio submitted
in soreceive by an application.
- Works with sockets that are being handled by the TCP offload engine
of a T4 chip (you need t4_tom.ko module loaded after cxgbe, and an
"ifconfig +toe" on the cxgbe interface).
- Does not require any modification to the application.
- Not enabled by default. Use hw.t4nex.<X>.toe.ddp="1" to enable it.
- Setup multiple DDP page sizes. When the driver attempts DDP it will
try to combine physically contiguous pages into regions of these sizes.
- Set the indicate size such that the payload carried in the indicate can
be copied in the header mbuf (and the 16K rx buffer can be recycled).
- Set DDP threshold to the max payload that the chip will coalesce and
deliver to the driver (this is ~16K by default, which is also why the
offload rx queue is backed by 16K buffers). If the chip is able to
coalesce up to the max it's allowed to, it's a good sign that the peer
is transmitting in bulk without any TCP PSH.
MFC after: 2 weeks
TCB. Filters are programmed by modifying the TCB too (via a different
routine) and the reply to any TCB update is delivered via a
CPL_SET_TCB_RPL. Figure out whether the reply is for a filter-write or
something else and route it appropriately.
MFC after: 2 weeks
"m_getjcl:invalid cluster type" that occurred some
time back with the igb driver. This happens often when
booting over the net. I believe the NIC hardware is left
in a warm state when handed over to the driver, and a stray
RX interrupt happens earlier than the code is prepared for
it to happen. This change was verified to fix the problem,
its kind of a bandaid... but it is similar to what was done
in the igb code.
1) It is not useful to call "devfs_clear_cdevpriv()" from
"d_close" callbacks, hence for example read, write, ioctl and
so on might be sleeping at the time of "d_close" being called
and then then freed private data can still be accessed.
Examples: dtrace, linux_compat, ksyms (all fixed by this patch)
2) In sys/dev/drm* there are some cases in which memory will
be freed twice, if open fails, first by code in the open
routine, secondly by the cdevpriv destructor. Move registration
of the cdevpriv to the end of the drm open routines.
3) devfs_clear_cdevpriv() is not called if the "d_open" callback
registered cdevpriv data and the "d_open" callback function
returned an error. Fix this.
Discussed with: phk
MFC after: 2 weeks
"device_free_softc()" and "device_claim_softc()",
to allow USB serial drivers refcounting the softc.
These functions are used to grab the softc from
auto-free and to free the softc back to the correct
malloc type, respectivly.
Discussed with: jhb
MFC after: 2 weeks
* the descriptor ID, and
* the multi-buffer support that the EDMA chips support.
This is required for successful MAC transmission of multi-descriptor
frames. The MAC simply hangs if there are NULL buffers + 0 length pointers,
but the descriptor did have TxMore set.
This won't be done for the 11n aggregate path, as that will be modified
to use the newer API (ie, ath_hal_filltxdesc() and then set first|middle|
last_aggr), which will deprecate some of the current code.
TODO:
* Populate the numTxMaps field in the HAL, then make sure that's fetched
by the driver. Then I can undo that hack.
Tested:
* AR9380, AP mode, TX'ing non-aggregate 802.11n frames;
* AR9280, STA/AP mode, doing aggregate and non-aggregate traffic.
This is required to support > MCS15 as more than 32 bit rate entries are
suddenly available.
This is quite messy - instead of doing typecasts at each mask operation,
this should be migrated to use a macro and have that do the typecast.
r233822:
Remove useless and wrong piece of code in fdt_get_range() which i
overwrites passed phandle_t node. Modify debug printf in fdt_reg_to_rl()
to be consistent (that is, print start and end *virtual* addresses).
r230560:
Handle "ranges;"
Make fdt_reg_to_rl() responsible for mapping the device memory, instead
on just hoping that there's only one simplebus, and using fdt_immr_va as
the base VA.
r230315
Add a function to get the PA from range, instead of (ab)using
fdt_immr_pa, and use it for the UART driver
interface's MTU. Initialize such freelists with correct values.
This wasn't a problem for common MTUs (1500 and 9000) as the buffers (2048
and 9216 in size) happened to have enough spare room. I ran into it when
playing around with unusual MTUs.
MFC after: 2 weeks
re-used by the upcoming EDMA TX completion code.
Make ath_stoptxdma() public, again so the EDMA TX code can use it.
Don't check for the TXQ bitmap in the ISR when doing EDMA work as it
doesn't apply for EDMA.
make maintaining this driver from the documentation easier in the future.
This is a mostly mechanical change.
In uslcom_param(), move the zeroing of the final two fields of the
flowctrl structure outside of the "if CRTSCTS" section - not only were
they being zeroed in both the clauses, but these two fields have nothing
to do with hardware flow control anyway.
values).
- cong_drop specifies what to do on congestion: nothing, backpressure,
or drop.
- fl_pktshift specifies the padding before Ethernet payload.
- fl_pad specifies the boundary upto which to pad Ethernet payload.
- spg_len controls the length of the status page.
MFC after: 2 weeks
- Add per-controller configuration (sx) and I/O (mutex) locks. The
configuration lock protects the relationship of volumes and drives
while the I/O lock protects access to the controller's registers and
the main I/O path.
- Remove some checks for M_WAITOK malloc()'s failing.
- Remove the explicit bus space tag/handle from the softc and use
bus_*() rather than bus_space_*().
- Reuse the existing new-bus sysctl context instead of creating a
new one.
- Remove compat shims for FreeBSD 4.x.
- Use pci_enable_busmaster() rather than doing it by hand, and rely
on bus_alloc_resource() to enable PCI I/O decoding.
Tested by: Mike Tancsa mike sentex net
Reviewed by: scottl (partially)
MFC after: 1 month
in SUPER-speed mode, USB 3.0.
This feature has not been tested yet, due to lack of hardware.
This feature is useful when implementing protocols like UASP,
USB attached SCSI which promises higher USB mass storage throughput.
This patch also implements support for hardware processing of endpoints
for increased performance. The switching to hardware processing
of an endpoint is done via a callback to the USB controller driver. The
stream feature is implemented like a variant of a hardware USB protocol.
USB controller drivers implementing device mode needs to be updated to
implement the new "xfer_stall" USB controller method and remove the
"xfer" argument from the "set_stall" method.
The API's toward existing USB drivers are preserved. To setup a USB transfer
in stream mode, set the "stream_id" field of the USB config structure to
the desired value.
The maximum number of BULK streams is currently hardcoded and limited to 8
via a define in usb_freebsd.h.
All USB drivers should be re-compiled after this change.
LibUSB will be updated next week to support streams mode. A new IOCTL to
setup BULK streams as already been implemented. The ugen device nodes
currently only supports stream ID zero.
The FreeBSD version has been bumped.
MFC after: 2 weeks
necessary to "do" EDMA.
It was just using the TX completion status for logging information about
the descriptor completion. Since with EDMA we don't know this without
checking the TX completion FIFO, we can't provide this information.
So don't.
Now that I understand what's going on with this, I've realised that
it's going to be quite difficult to implement a processq method in
the EDMA case. Because there's a separate TX status FIFO, I can't
just run processq() on each EDMA TXQ to see what's finished.
i have to actually run the TX status queue and handle individual
TXQs.
So:
* unmethodize ath_tx_processq();
* leave ath_tx_draintxq() as a method, as it only uses the completion status
for debugging rather than actively completing the frames (ie, all frames
here are failed);
* Methodize ath_draintxq().
The EDMA ath_draintxq() will have to take care of running the TX
completion FIFO before (potentially) freeing frames in the queue.
The only two places where ath_tx_draintxq() (on a single TXQ) are used:
* ath_draintxq(); and
* the CABQ handling in the beacon setup code - it drains the CABQ before
populating the CABQ with frames for a new beacon (when doing multi-VAP
operation.)
So it's quite possible that once I methodize the CABQ and beacon handling,
I can just drop ath_tx_draintxq() in its entirety.
Finally, it's also quite possible that I can remove ath_tx_draintxq()
in the future and just "teach" it to not check the status when doing
EDMA.
EDMA HAL hardware.
* The EDMA HAL code assumes the nexttbtt and intval values are in TU/8
units, rather than TU. For now, just "hack" around that here, at least
until I code up something to translate it in the HAL.
* Setup some different TXQ flags for EDMA hardware.
* The EDMA HAL doesn't support setting the first rate series via
ath_hal_setuptxdesc() - instead, a call to ath_hal_set11nratescenario()
is always required. So for now, just do an 11n rate series setup
for EDMA beacon frames.
This allows my AR9380 to successfully transmit beacon frames.
However, CABQ TX and all normal data frame TX and TX completion is
still not functional and will require some more significant code churn
to make work.
I was having TX hang issues, which I root caused to having the
legacy ath_hal_setupxtxdesc() called, rather than the 11n rate scenario
setup code. This meant that rate control information wasn't being
put into frames, causing the MAC to stall/hang.
* Add ATH_TXQ_FIRST() for easy tasting of what's on the list;
* Add an "axq_fifo_depth" for easy tracking of how deep the current
FIFO is;
* Flesh out the handoff (mcast, hw) functions;
* Begin fleshing out a TX ISR proc, which tastes the TX status FIFO.
The legacy hardware stuffs the TX completion at the end of the final frame
descriptor (or final sub-frame when doing aggregate.) So it's feasible
to do a per-TXQ drain and process, as the needed info is right there.
For EDMA hardware, there's a separate TX completion FIFO. So the TX
process routine needs to read the single FIFO and then process the
frames in each hardware queue.
This makes it difficult to do a per-queue process, as you'll end up with
frames in the TX completion FIFO for a different TXQ to the one you've
passed to ath_tx_draintxq() or ath_tx_processq().
Testing:
I've tested the TX queue and TX completion code in hostap mode on an
AR9380. Beacon frames successfully transmit and the completion routine
is called. Occasional data frames end up in TXQ 1 and are also
successfully completed.
However, this requires some changes to the beacon code path as:
* The AR9380 beacon configuration API is now in TU/8, rather than
TU;
* The AR9380 TX API requires the rate control is setup using a call
to setup11nratescenario, rather than having the try0 series setup
(rate/tries for the first series); so the beacon won't go out.
I'll follow this up with commits to the beacon code.
the device_detach() function doesn't block on UCOM device
drivers until the TTY handle is closed by the userspace
application. This is implemented by a postpone of the
softc free where the UCOM structures reside until the
TTY references are gone.
Discussed with: kib, ed
MFC after: 2 weeks
Extend the callback table of UCOM to include a
"ucom_free" function pointer which is called when
all refs on a UCOM super structure is gone.
Implement various helper functions to handle
refcounting and draining on the UCOM super
structure.
Implement macro which can be used in device
drivers to avoid module unload before all
pending TTY references are gone.
The UCOM API is backwards compatible after this
change and device drivers require no changes
to function with this change. Only a recompilation
of UCOM device drivers is required. The FreeBSD
version has been bumped in that regard.
Discussed with: kib, ed
MFC after: 2 weeks
- Move destruction of per-ring locks to netmap_dtor_locked to mirror the
initialization that happens in NIOCREGIF. Otherwise unloading a netmap-
capable interface that was never put into netmap mode would try to
mtx_destroy an uninitialized mutex, and panic.
- Destroy core_lock in netmap_detach, mirroring init in netmap_attach.
- Also comment out the knlist_destroy for now as there is currently no
knlist_init.
Sponsored by: ADARA Networks
Reviewed by: luigi@
CCB at a time outstanding reliable. It's not there yet, but this
is the direction to go in so might as well commit. So far,
multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode),
but it fails if there are more downstream than the SIM wants
to handle and SRR is sort of confused when this happens, plus
it is not entirely quite clear what one does if a CCB/CTIO fails
and you have more in flight (that don't fail, say) and more queued
up at the SIM level that haven't been started yet.
Some of this is driven because there apparently is no flow control
to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO
requests. It is also more driven in that the few target mode
periph drivers there are are not really set up for handling pushback-
heck most of them don't even check for errors (and what would they
really do with them anyway? It's the initiator's problem, really....).
The data transfer arithmetic has been worked over again to handle
multiple outstanding commands, so you have a notion of what's been
moved already as well as what's currently in flight. It turns that
this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET
code which was sending back 24 bytes of rpl data instead of the
specified 16. What happened furthermore here is that sending back
16 bytes and reporting an overrun of 8 bytes made the initiator
(running FC-Tape aware f/w) mad enough to request, and keep
requesting, another FCP response (I guess it didn't like the answer
so kept asking for it again).
Sponsored by: Spectralogic
MFC after: 1 month
Starting or stopping the IPMI watchdog is rather expensive with the
current implementation as all IPMI requests are bounced via thread.
This is not viable during shutdown or dumps, and this avoids headache
in the common case that the watchdog is not enabled. The IPMI watchdog
should probably be reworked to not use a separate thread to fix this
in the case when the watchdog timer is enabled.
MFC after: 2 weeks
packet delivery, always enqueue when possible. Also
correct the DEPLETED test as multiple bits might be
set. Thanks to Randall Stewart for the changes!
on the secondary side of a bridge will not be propagated to the primary
bus unless this is enabled. Busmastering is not enabled by default (we
have relied on firmware to set this bit to date). The OS needs to set it
for any bridges not configured by system firmware.
Tested by: Steve Polyack korvus comcast net
MFC after: 2 weeks
'fw_hdr_intfver' into an anonymous enum, which avoids a clang 3.2
warning about all the enum values being the same value.
Reviewed by: np
MFC after: 1 week
