I've been reloading the ath10k modules all afternoon, debugging issues
in my CT firmware. I've been unloading firmware with pkts queued
in the TX logic, and they could easily not be flushable at this piont.
I just saw this...and machine hung.
DMA: Out of SW-IOMMU space for 1984 bytes at device
was wrong with it, just didn't have both
raw tx and decap set properly and had some baggage from the original
patch to jettison.
Still a bit WIP but this patchset against openwrt r46584 seems to work
for me:
http://bobcopeland.com/kernel/wl/20150812/
The mac80211 bits (except for VHT) are upstream
Dear experts,
I’m testing the ath10k driver in AP mode now. Previously, I got many
warning log with backports 4.1.1-1 + firmware 10.2.4.48, such as
[30317.981129] ath10k_pci 0001:03:00.0: failed to transmit management
frame via WMI: -11
[31833.297127] ath10k_pci 0001:03:00.0: failed to delete
On 12 August 2015 at 00:48, Igor Pavlov igor.arabesc.pav...@gmail.com wrote:
I have an issue with 10.1.467.2-1 firmware - SSID disappears from the
air within a few hours from the launch of an access-point software.
I'm using OpenWrt 15.05-rc3 as an OS and a QCA9880 v2 based WiFi adapter.
On 12 August 2015 at 08:11, Joe Qiao qln...@gmail.com wrote:
Dear experts,
I’m testing the ath10k driver in AP mode now. Previously, I got many
warning log with backports 4.1.1-1 + firmware 10.2.4.48, such as
[30317.981129] ath10k_pci 0001:03:00.0: failed to transmit management
frame via
The frequency at which cycle/rx_clear counters are running might
change from one target type to another. QCA99X0 is running the
counters at 150Mhz while QCA9888X and QCA6174 are running at 88Mhz.
Add a new entry to hw_params to store the target specific frequency
and use it in msecs conversion.
There are three WMI_CHAN_INFO events reported per channel
in QCA99X0 firmware. First one is a notification at the begining
of the channel dwell time with cmd_flag as CHAN_INFO_START(cmd_flag = 0),
second one is a notification at the end of the dwell time with cmd_flag
CHAN_INFO_PRE_COMPLETE
Existing phyerr event handlers directly uses phyerr header format
(ie, struct wmi_phyerr and struct wmi_phyerr_event) in the code
exactly on how firmware packs it. This is the problem in 10.4 fw
specific phyerr event handling where it uses different phyerror
header format. Before adding 10.4
Header format of 10.4 firmware phyerr event is not alligned
with pre 10.4 firmware. Introduce new wmi handlers to parse
10.4 firmware specific phyerror event header.
With changes covered in this patch, radar detection works on
qca99x0 hw 2.0 which uses 10.4 firmware.
Signed-off-by: Raja Mani
Hello,
There are still new folks reporting this issue in the Launchpad bug
report[0]. Has there been any progress on the firmware problem reported
in the comment by Kalle Valo on March 26, 2015[1]?
Thanks in advance,
Joe
[0] http://pad.lv/1436940
[1]
10 matches
Mail list logo