Re: attempting mesh on ath10k
On 27 April 2015 at 15:00, Bob Copeland wrote: > On Sun, Apr 26, 2015 at 10:15:52AM -0400, Bob Copeland wrote: >> So, progress! >> >> There's still an issue with datapath -- while it looks like we can establish >> plinks, I couldn't get unicast traffic flowing even if manually setting up >> mpaths and arp table entries. I haven't yet got all of my 5 ghz capable gear >> in the same room to monitor and see where the problem lies. > > Now I had a chance to monitor it, and in so doing, rediscovered this patch of > Chun-Yeow's: > > http://lists.infradead.org/pipermail/ath10k/2014-September/003206.html > > In fact my broadcasts were truncated and the above change makes the broadcast > ARPs look correct over the air. The (non-ath10k) target mesh STA replies with > broadcast PREQ but that is not received / processed / replied-to by the > ath10k device. > > Perhaps there is a BSSID filter enabled or something like that (in mesh > there's no BSSID, just individual addresses on group addressed frames). In that case try creating a monitor interface and bring it up. This should prompt ath10k to create monitor vdev and subsequently disable most Rx filters in firmware. Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
ath10k CT firmware crash help.
Hello! I have been trying to make progress on a particular firmware crash in my 10.1 CT firmware, but I am not having much luck. For anyone using my firmware, I would appreciate if you could keep a look-out for crashes that match the crash signature at the bottom of this page: http://www.candelatech.com/ath10k.php In general, I am interested in all firmware crashes from my firmware, but I am especially interested to know if the CE engine assert happens on other's platforms. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1?
On 27/04/2015 16:00, Moritz Morawietz wrote: > Hi! > > I have the same problems with my card (also a Killer N1525). It seems > you've done it, but i can't figure out how. > > Do i need to build and use kvalo's kernel, or is it enough to build > the modules ath10k_core & ath10k_pci? > I'm a bit afraid of compiling the whole kernel ^^ > output of uname -a: > Linux companion 4.0.0-2-ARCH #1 SMP PREEMPT Tue Apr 14 07:14:46 CEST > 2015 x86_64 GNU/Linux The modules should be enough. Tell us if it works. Compiling a whole kernel isn't too hard if you already have a working configuration. > I have the disassembly.py, but cannot find the dissect.py, can you > provide the link? Or, even better, the assembled files? I won't upload the assembled files now, I don't know if I can get licensing issues. You can find the dissect.py script here: http://lists.infradead.org/pipermail/ath10k/2015-April/005074.html Good luck! Regards, Gabriele ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH] ath10k: add ATH10K_FW_FEATURE_IGNORE_OTP_RESULT
qca6174 otp binary seems to always return an error to the host, even if the
calibration succeeded. Add a firmware feature flag to detect if the firmware
image which have this problem and workaround the issue in ath10k by ignoring
the error code.
I was also considering making this hw specific flag but as this is strictly a
firmware issue it's best to handle this via a firmware feature flag so that it
will be easy to disable the workaround.
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/core.c |4 +++-
drivers/net/wireless/ath/ath10k/core.h |3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 987b266278a8..bcccae19325d 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -387,7 +387,9 @@ static int ath10k_download_and_run_otp(struct ath10k *ar)
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot otp execute result %d\n", result);
- if (!skip_otp && result != 0) {
+ if (!(skip_otp || test_bit(ATH10K_FW_FEATURE_IGNORE_OTP_RESULT,
+ ar->fw_features))
+ && result != 0) {
ath10k_err(ar, "otp calibration failed: %d", result);
return -EINVAL;
}
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 8444adf42195..827b3d79ed0c 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -460,6 +460,9 @@ enum ath10k_fw_features {
*/
ATH10K_FW_FEATURE_WOWLAN_SUPPORT = 6,
+ /* Don't trust error code from otp.bin */
+ ATH10K_FW_FEATURE_IGNORE_OTP_RESULT,
+
/* keep last */
ATH10K_FW_FEATURE_COUNT,
};
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: Tips to debug Firmware crash
On 04/26/2015 10:48 PM, Venkat Ch wrote: Hi All, I am an active developer of Atheros drivers for the last 10 years. I have been working on QCA 10.2.2 driver for the last few months and trying to understand the architecture of this offloading model. Though this forum is nothing to do with Atheros provided drivers, I took the liberty of posting the question to see if Ath10k community could help me. Sorry if I violated any guidelines. There is some problem at firmware level about which I am clueless. Whenever there is a crash in firmware the 5GHz interface goes down completely and there will not be any transmissions or receptions from the interface from then. What all I see on the console is some log message "Target Asserted" . I don't get any stack trace to see in which function it crashed. Can any of you please let me know if there is a way to dump the stack trace and debug the firmware crash? I have tools to debug my modified 10.1 'CT' firmware and get backtraces and decode the log messages and such. I can't publish the details due to NDA, but I can give vague descriptions of the problem and usually figure out a way to fix it. For 10.2, you would need to talk to someone with that firmware source code, as I have not been given access to it. Thanks, Ben Thanks & Regards Venkat -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA6174 hw2.1?
Hi! I have the same problems with my card (also a Killer N1525). It seems you've done it, but i can't figure out how. Do i need to build and use kvalo's kernel, or is it enough to build the modules ath10k_core & ath10k_pci? I'm a bit afraid of compiling the whole kernel ^^ output of uname -a: Linux companion 4.0.0-2-ARCH #1 SMP PREEMPT Tue Apr 14 07:14:46 CEST 2015 x86_64 GNU/Linux I have the disassembly.py, but cannot find the dissect.py, can you provide the link? Or, even better, the assembled files? Many thanks for help! Moritz 2015-04-27 2:21 GMT+02:00 Gabriele Martino : > Just tried the kvalo's kernel. > NetworkManager connected flawlessly at boot to my WPA2 home network on > 2.4GHz. Will try 5GHz later. > iwconfig reports a fixed 1Mb/s bitrate, but I can copy files to my nas > (smb share) at about 3.3MB/s. > That's a reasonable speed for b/g wireless. > > iwconfig: > wlp3s0IEEE 802.11abgn ESSID:"W-I-SEE-YOU-N" > Mode:Managed Frequency:2.412 GHz Access Point: > 40:16:7E:2C:79:90 > Bit Rate=1 Mb/s Tx-Power=20 dBm > Retry short limit:7 RTS thr:off Fragment thr:off > Encryption key:off > Power Management:on > Link Quality=59/70 Signal level=-51 dBm > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:42 Missed beacon:0 > > iwlist scan (part of): > wlp3s0Scan completed : > Cell 01 - Address: 40:16:7E:2C:79:90 > Channel:1 > Frequency:2.412 GHz (Channel 1) > Quality=60/70 Signal level=-50 dBm > Encryption key:on > ESSID:"W-I-SEE-YOU-N" > Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s > 24 Mb/s; 36 Mb/s; 54 Mb/s > Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s > Mode:Master > Extra:tsf=0005244f5a5d > Extra: Last beacon: 33ms ago > IE: Unknown: 000D572D492D5345452D594F552D4E > IE: Unknown: 010882848B962430486C > IE: Unknown: 030101 > IE: Unknown: 2A0104 > IE: Unknown: 2F0104 > IE: IEEE 802.11i/WPA2 Version 1 > Group Cipher : CCMP > Pairwise Ciphers (1) : CCMP > Authentication Suites (1) : PSK > > dmesg output: > [2.212106] ath10k_pci :03:00.0: enabling device ( -> 0002) > [2.212558] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 > [2.368318] ath10k_pci :03:00.0: Direct firmware load for > ath10k/cal-pci-:03:00.0.bin failed with error -2 > [2.368971] ath10k_pci :03:00.0: Direct firmware load for > ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 > [2.368974] ath10k_pci :03:00.0: failed to load spec board file, > falling back to generic: -2 > [2.369252] ath10k_pci :03:00.0: Direct firmware load for > ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 > [2.369270] ath10k_pci :03:00.0: could not fetch firmware file > 'ath10k/QCA6174/hw2.1/firmware-5.bin': -2 > [3.559021] ath10k_pci :03:00.0: qca6174 hw2.1 (0x0501, > 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt > 3.0 wmi 4 cal otp max_sta 32 > [3.559024] ath10k_pci :03:00.0: debug 1 debugfs 0 tracing 0 dfs > 0 testmode 0 > [3.623733] ath: EEPROM regdomain: 0x6c > [3.623735] ath: EEPROM indicates we should expect a direct regpair map > [3.623736] ath: Country alpha2 being used: 00 > [3.623737] ath: Regpair used: 0x6c > [3.638102] ath10k_pci :03:00.0 wlp3s0: renamed from wlan0 > [7.523617] ath10k_pci :03:00.0: no channel configured; ignoring > frame(s)! > [7.627173] ath10k_pci :03:00.0: no channel configured; ignoring > frame(s)! > [ 12.149947] wlp3s0: authenticate with 40:16:7e:2c:79:90 > [ 12.183915] wlp3s0: send auth to 40:16:7e:2c:79:90 (try 1/3) > [ 12.185559] wlp3s0: authenticated > [ 12.186043] wlp3s0: associate with 40:16:7e:2c:79:90 (try 1/3) > [ 12.189402] wlp3s0: RX AssocResp from 40:16:7e:2c:79:90 (capab=0x411 > status=0 aid=3) > [ 12.192174] wlp3s0: associated > [ 313.912952] wlp3s0: AP 40:16:7e:2c:79:90 changed bandwidth, new > config is 2412 MHz, width 1 (2412/0 MHz) > [ 313.912955] wlp3s0: AP 40:16:7e:2c:79:90 changed bandwidth in a way > we can't support - disconnect > [ 318.709453] wlp3s0: authenticate with 40:16:7e:2c:79:90 > [ 318.750807] wlp3s0: send auth to 40:16:7e:2c:79:90 (try 1/3) > [ 318.752541] wlp3s0: authenticated > [ 318.753030] wlp3s0: associate with 40:16:7e:2c:79:90 (try 1/3) > [ 318.756524] wlp3s0: RX AssocResp from 40:16:7e:2c:79:90 (capab=0x411 > status=0 aid=1) > [ 318.759082] wlp3s0: associated > > I'm using the board file
Re: attempting mesh on ath10k
On Sun, Apr 26, 2015 at 10:15:52AM -0400, Bob Copeland wrote: > So, progress! > > There's still an issue with datapath -- while it looks like we can establish > plinks, I couldn't get unicast traffic flowing even if manually setting up > mpaths and arp table entries. I haven't yet got all of my 5 ghz capable gear > in the same room to monitor and see where the problem lies. Now I had a chance to monitor it, and in so doing, rediscovered this patch of Chun-Yeow's: http://lists.infradead.org/pipermail/ath10k/2014-September/003206.html In fact my broadcasts were truncated and the above change makes the broadcast ARPs look correct over the air. The (non-ath10k) target mesh STA replies with broadcast PREQ but that is not received / processed / replied-to by the ath10k device. Perhaps there is a BSSID filter enabled or something like that (in mesh there's no BSSID, just individual addresses on group addressed frames). -- Bob Copeland %% http://bobcopeland.com/ ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Modifing and installing ath10k driver for kernel 4.0
On 23 April 2015 at 17:16, Costa Molero Edgar wrote: > Hi all, > > In order to use the latest firmware version (10.2.4.48) for my access point > I installed the kernel version 4.0 in my Ubuntu 14.04 LTS laptop. > > The problem is that with the ath10k driver it comes the option debug is not > enabled, and my domain regulatory database do not allow me to use 80Mhz > channels. > > Before upgrading the kernel, I was using the latest backports release > 3.19-r1-1-1. To install that driver I downloaded it then I enabled all the > configuration options I needed for my project (debug, debugfs, etc) and I > also modified the regulatory database by changing the content of the file > /net/wireless/db.txt. > > I never compiled a linux kernel. And therefore I don't quite understand what > should I do know to modify the current driver version. (I just want to change > the db.txt file and enable debug) Then I want to compile the driver and > install it. Could some one give me some hints ? > > Should not the driver source code be located at that directory ? > /usr/src/linux-headers-4.0.0-04-generic/drivers/net/wireless/ath/ath10k# > , and also the db.txt located here > :/usr/src/linux-headers-4.0.0-04-generic/net/wireless# . This directory, as the path name implies, contains just kernel headers. These are generally used whfor compiling DKMS (additional out-of-tree modules, e.g. nvidia gpu blob). If you want to compile an entire kernel I suggest you look into your distro wiki. All distros have different ways of doing things if you want to keep your installation clean. You can still use backports though. All you need is to build backports package yourself[1] from whatever kernel tree you desire, e.g. github.com/kvalo/ath instead of using the pre-built one. [1]: https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking Michał ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: implement more versatile set_bitrate_mask
Michal Kazior writes: > Until now only a single fixed tx rate or nss was > allowed to be set. > > The patch attempts to improve this by allowing > most bitrate masks. The limitation is VHT MCS > rates cannot be expressed separately using > existing firmware interfaces and only the > following VHT MCS ranges are supported: none, 0-7, > 0-8, and 0-9. > > This keeps the old behaviour when requesting > single tx rate or single nss. The new bitrate mask > logic is only applied to other cases that would > return -EINVAL until now. > > Depending on firmware revisions some combinations > may crash firmware so use with care, please. > > This depends on "ath10k: don't use reassoc flag". > Without it key cache would effectively be > invalidated upon bitrate change leading to > communication being no longer possible. > > Signed-off-by: Michal Kazior Thanks, applied. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
