previous names, 'ptag' and 'pmap' -- p stands for packet.
This change reduces the difference between the code in stable/9
and head, and also helps using the same ixgbe_netmap.h on both branches.
Approved by: Jack Vogel
through the USB API and/or busdma.
The following assumptions have been made:
umass - buffers passed from CAM/SCSI layer are OK
network - mbufs are OK.
Some other nits while at it.
MFC after: 1 week
Suggested by: imp
DMA data does not reside next to non DMA data. This
might cause more memory to be allocated, but solves
problems on platforms using manual cache
synchronization.
Add a convenience function to get the buffer only
from a USB transfer's page cache structure.
MFC after: 1 week
Suggested by: imp
Unfortunately 5720S uses 5709S PHY id so add a hack to detect 5720S
PHY by checking parent device name. 5720S PHY does not support 2500SX.
Tested by: Geans Pin < geanspin <> broadcom dot com >
support for their new RAID adapter ARC-1214.
Many thanks to Areca for continuing to support FreeBSD.
Submitted by: 黃清隆 Ching-Lung Huang <ching2048 areca com tw>
MFC after: 2 weeks
Starting with firmware v7.5, the "Read TouchPad Modes" ($01) and "Read
Capabilities" ($02) commands changed: previously constant bytes now
carry variable information.
We now compare those bytes to expected constants only for firmware prior
to v7.5.
Tested by: Zeus Panchenko <zeus@gnu.org.ua>
MFC after: 1 week
* The warning message was:
'warning error: format string is not a string literal';
* Changed how make_dev is called, now a string literal
for formatting is used;
Approved by: adrian (mentor)
LUNs for the virtual processor device. This removes lots of CAM warnings,
and follows similar recent changes to tws(4) and twa(4) drivers.
Also fix case where CAM_REQ_CMP was getting OR'd with CAM_DEV_NOT_THERE
in the nonexistent LUN case, resulting in different CAM status (CAM_UA_TERMIO)
getting reported to CAM. This issue existing previously, but was more subtle
because it changed CAM_SEL_TIMEOUT to CAM_CMD_TIMEOUT.
Sponsored by: Intel
Reported and tested by: Willem Jan Withagen <wjw@digiware.nl>
MFC after: 1 week
This fixes panic when listing sysctls on INVARIANTS-enabled kernel while
having wbwd loaded.
This panic was not fatal, at worst one additional space was printed.
Also sbuf_trim() makes some sense even if drain function is set. The drain
function is called only when buffer is to be expanded. So we could still trim
existing buffer before drain is called. In this case it worked just fine - the
trailing space was correctly trimmed.
Obtained from: WHEEL Systems
MFC after: 1 week
If virtio_setup_intr() failed during boot, we would hang in
taskqueue_free() -> taskqueue_terminate() for all the taskq
threads to terminate. This will never happen since the
scheduler is not running by this point.
Reported by: neel, grehan
Approved by: grehan (mentor)
I am not exactly sure about the naming due to lack of specs on AMD site,
but it is better to have some identification then none at all.
MFC after: 1 month
These must have been accidently copied from the if statement a few
lines later. Also remove parameter name from function prototype.
Approved by: grehan (mentor)
to map, and technically this isn't allowed.
Functionally, it works OK (at least on x86) to call bus_dmamap_load with
a NULL data pointer and zero length, so this is primarily for correctness
and consistency with other drivers.
While here, remove check in isci_io_request_construct for nseg==0.
Previously, bus_dmamap_load would pass nseg==1, even for case where
buffer is NULL and length = 0, which allowed CAM_DIR_NONE CCBs
to get processed. This check is not correct though, and needed to be
removed both for the changes elsewhere in this patch, as well as jeff's
preliminary bus_dmamap_load_ccb patch (which uncovered all of this in
the first place).
MFC after: 3 days
thought I've decided its overkill,a simple tuneable for
each RX and TX limit, and then init sets the ring values
based on that, should be sufficient.
More importantly, fix a bug causing a panic, when changing
the define style to IXGBE_LEGACY_TX a taskqueue init was
inadvertently set #ifdef when it should be #ifndef.
I couldn't think of a way to maintain the hardware TXQ locks _and_ layer
on top of that per-TXQ software queuing and any other kind of fine-grained
locks (eg per-TID, or per-node locks.)
So for now, to facilitate some further code refactoring and development
as part of the final push to get software queue ps-poll and u-apsd handling
into this driver, just do away with them entirely.
I may eventually bring them back at some point, when it looks slightly more
architectually cleaner to do so. But as it stands at the present, it's
not really buying us much:
* in order to properly serialise things and not get bitten by scheduling
and locking interactions with things higher up in the stack, we need to
wrap the whole TX path in a long held lock. Otherwise we can end up
being pre-empted during frame handling, resulting in some out of order
frame handling between sequence number allocation and encryption handling
(ie, the seqno and the CCMP IV get out of sequence);
* .. so whilst that's the case, holding the lock for that long means that
we're acquiring and releasing the TXQ lock _inside_ that context;
* And we also acquire it per-frame during frame completion, but we currently
can't hold the lock for the duration of the TX completion as we need
to call net80211 layer things with the locks _unheld_ to avoid LOR.
* .. the other places were grab that lock are reset/flush, which don't happen
often.
My eventual aim is to change the TX path so all rejected frame transmissions
and all frame completions result in any ieee80211_free_node() calls to occur
outside of the TX lock; then I can cut back on the amount of locking that
goes on here.
There may be some LORs that occur when ieee80211_free_node() is called when
the TX queue path fails; I'll begin to address these in follow-up commits.
This brand of controllers expects that the number of
contexts specified in the input slot context points
to an active endpoint context, else it refuses to
operate.
- Ring the correct doorbell when streams mode is used.
- Wrap one or two long lines.
Tested by: Markus Pfeiffer (DragonFlyBSD)
MFC after: 1 week
... to avoid any races or inconsistencies.
This should fix a regression introduced in r243404.
Also, remove a stale comment that has not been true for quite a while
now.
Pointyhat to: avg
Teested by: trociny, emaste, dumbbell (earlier version)
MFC after: 1 week
enforcing the TXOP and TBTT limits:
* Frames which will overlap with TBTT will not TX;
* Frames which will exceed TXOP will be filtered.
This is not enabled by default; it's intended to be enabled by the
TDMA code on 802.11n capable chipsets.
the revamped sysctl code did not work, and needed a change. This
makes the limit get set at the time that all sysctl stats are
created and is actually more elegant imho anyway.
