I .. can't believe I missed this.
This showed up because the AP was TX'ing LDPC to an iwm(4) chipset,
which didn't advertise LDPC and doesn't /accept/ LDPC. Amusingly, all
the two other FreeBSD 11n parts I had tested with (AR9380, Intel 7260)
and I completely forgot to test on ye olde hardware.
That'll teach me.
Tested:
* AR9580 (AP) - Intel 7260 (STA), AR9380 (STA), Intel 6205 (STA)
function to error out early when no port module is present and doing
eeprom access. This also prevents error codes from filling up in
dmesg.
Sponsored by: Mellanox Technologies
Tested by: Netflix
MFC after: 1 week
LDPC adds better transmit reliability if both ends support it.
You in theory can do both STBC and LDPC at the same time.
If I see issues I'll disable it.
* Only enable it if both ends of a connection negotiate it.
* Disable it if any rate is non-11n.
* Count both LDPC TX and STBC TX.
Tested:
* AR9380, STA mode
Arguably we should only be doing the probe/attach to children of
these devices as well.
Tested by: Michal Stanek <mst_semihalf.com> (arm64)
Differential Revision: https://reviews.freebsd.org/D6133
Add new function gpio_alloc_intr_resource(), which allows an allocation
of interrupt resource associated to given gpio pin. It also allows to
specify interrupt configuration.
Note: This functionality is dependent on INTRNG, and must be
implemented in each GPIO controller.
Labels are limitted by 32 on EF10. It is not sufficient on powerful hosts.
Since only one RxQ is running over each EvQ, zero label may be used.
Reviewed by: gnn
Sponsored by: Solarflare Communications, Inc.
MFC after: 2 days
PR: 208267
Differential Revision: https://reviews.freebsd.org/D6121
This allows the PCI-PCI bridge driver to save a reference to the child
device in its softc.
Note that this required moving the "pci" device creation out of
acpi_pcib_attach(). Instead, acpi_pcib_attach() is renamed to
acpi_pcib_fetch_prt() as it's sole action now is to fetch the PCI
interrupt routing table.
Differential Revision: https://reviews.freebsd.org/D6021
Rescanning a PCI bus uses the following steps:
- Fetch the current set of child devices and save it in the 'devlist'
array.
- Allocate a parallel array 'unchanged' initalized with NULL pointers.
- Scan the bus checking each slot (and each function on slots with a
multifunction device).
- If a valid function is found, look for a matching device in the 'devlist'
array. If a device is found, save the pointer in the 'unchanged' array.
If a device is not found, add a new device.
- After the scan has finished, walk the 'devlist' array deleting any
devices that do not have a matching pointer in the 'unchanged' array.
- Finally, fetch an updated set of child devices and explicitly attach any
devices that are not present in the 'unchanged' array.
This builds on the previous changes to move subclass data management into
pci_alloc_devinfo(), pci_child_added(), and bus_child_deleted().
Subclasses of the PCI bus use custom rescan logic explicitly override the
rescan method to disable rescans.
Differential Revision: https://reviews.freebsd.org/D6018
This greatly reduces the oqdrops under heavy workload.
For TCP send/recv test (10K concurrent connections):
oqdrops is reduced by 17% on sending side, and 57% on receiving side.
For nginx-1.8/wrk-4 1KB object test (10K concurrent connections,
4 requests/connection):
oqdrops is reduced by 44% on nginx side, and 10% on wrk side.
MFC after: 1 week
Sponsored by: Microsoft OSTC
- Factor out common part to zynq-7000.dtsi
- Fix problem with Zynq interrupts by using interrupt "triples"
in .dtsi file to differentiate between edge-triggered and
level-triggered interrupts
- cgem driver now recognizes "status" property
Submitted by: Thomas Skibo <thomasskibo@yahoo.com>
Differential Revision: https://reviews.freebsd.org/D6095
The softc member 'ciss_logical' is an array of 'ciss_max_logical_bus' members.
Most of the time it is iterated correctly. This patch fixes the two instances
where the driver iterated off the end of the array.
Reported by: Coverity
CID: 1305492
Sponsored by: EMC / Isilon Storage Division
ism_stop() already destroys and frees 'sp', including a call to ic_destroy().
Don't dereference 'sp' after ism_stop() and don't invoke ic_destroy() on the
freed memory either.
Reported by: Coverity
CIDs: 1006109, 1304861
Sponsored by: EMC / Isilon Storage Division
This is a trivial follow-up to r296308. Annotate the intentional fallthrough
to make it clear for future readers and linters.
Reported by: Coverity
CID: 1352716
Discussed with: jhb
Sponsored by: EMC / Isilon Storage Division
Introduced in r298594. There is no path before the 'vap == NULL' check where
vap is not already dereferenced.
Reported by: Coverity
CID: 1354979
Sponsored by: EMC / Isilon Storage Division
Since the sub-channel offers are synchronized, we can do our own
channel setup without using the sub-channel creation callback.
This paves the way to whack the sub-channel creation callback.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Since the sub-channel offers are synchronized, we can do our own
channel setup without using the sub-channel creation callback.
This paves the way to whack the sub-channel creation callback.
MFC after: 1 week
Sponsored by: Microsoft OSTC
This fixes the sub-channel offer race after Hyper-V device probe/attach
is moved to vmbus SYSINIT/attach.
MFC after: 1 week
Sponsored by: Microsoft OSTC
I'm seeing 5GHz association work but data not work until the rate drops,
so I need way more information about what's being programmed into the
transmit descriptors.
Tested:
* 7260AC, STA mode
This enables LDPC receive support for the AR9300 chips that support it.
It'll announce LDPC support via net80211.
Tested:
* AR9380, STA mode
* AR9331, (to verify the HAL didn't attach it to a chip which
doesn't support LDPC.)
TODO:
* Add in net80211 machinery to make this configurable at runtime.
Add support for the FHT_STBC_TX flag in iv_flags_ht, so it'll now obey
the per-vap ifconfig stbctx flag.
This means that we can do STBC TX on one vap and not another VAP.
(As well as STBC RX on said vap; that changes the HTCAP announcement.)
Always print out the firmware panic info before restarting; don't
put it behind IWM_DEBUG.
Submitted by: bapt
Differential Revision: https://reviews.freebsd.org/D6081
