Bug 18368 - Atheros QCA6174 issues
Summary: Atheros QCA6174 issues
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 5
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Kernel and Drivers maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-05 10:24 CEST by Mike Burgener
Modified: 2016-11-08 08:39 CET (History)
1 user (show)

See Also:
Source RPM: kernel-firmware-nonfree-20160503-1.mga5.nonfree
CVE:
Status comment:


Attachments
Mike's Pastebin kernel log (8.17 KB, text/plain)
2016-05-08 11:36 CEST, Marja Van Waes
Details
most recent kernel logfile when it tries to load firmware-5 (106.03 KB, text/x-log)
2016-05-11 18:54 CEST, Mike Burgener
Details

Description Mike Burgener 2016-05-05 10:24:44 CEST
Hi,

i got the Atheros QCA6174 working using the firmware release mentioned above, 

to get it working i had to link /usr/lib/firmware/ath10k/QCA6174/hw3.0/firmware-5.bin to /usr/lib/firmware/ath10k/QCA6174/hw3.0/firmware-4.bin 

the remaining issue:

the firmware seems to only load after some time after a boot and the network applet seems not to get that information, so i have to start draknetcenter and connect manually.

kernel-log can be found there: http://pastebin.com/CMadj2B3
Comment 1 Marja Van Waes 2016-05-08 11:36:17 CEST
Created attachment 7764 [details]
Mike's Pastebin kernel log

@ Mike

Next time, please attach your log to the bug report.

CC: (none) => marja11

Marja Van Waes 2016-05-08 11:37:02 CEST

Assignee: bugsquad => tmb

Comment 2 Thomas Backlund 2016-05-10 23:53:40 CEST
Hm, that rpm does not contain any hw3.0/firmware-5.bin

It has the correct firmware-4.bin

$ rpm -qpl kernel-firmware-nonfree-20160503-1.mga5.nonfree.noarch.rpm |grep QCA6174
/lib/firmware/ath10k/QCA6174
/lib/firmware/ath10k/QCA6174/hw2.1
/lib/firmware/ath10k/QCA6174/hw2.1/board-2.bin
/lib/firmware/ath10k/QCA6174/hw2.1/board.bin
/lib/firmware/ath10k/QCA6174/hw2.1/firmware-5.bin
/lib/firmware/ath10k/QCA6174/hw2.1/notice_ath10k_firmware-5.txt
/lib/firmware/ath10k/QCA6174/hw3.0
/lib/firmware/ath10k/QCA6174/hw3.0/board-2.bin
/lib/firmware/ath10k/QCA6174/hw3.0/board.bin
/lib/firmware/ath10k/QCA6174/hw3.0/firmware-4.bin
/lib/firmware/ath10k/QCA6174/hw3.0/notice_ath10k_firmware-4.txt
Comment 3 Mike Burgener 2016-05-11 16:18:42 CEST
Hi, more information for my second sentence (about the symlink) you can find here: https://bbs.archlinux.org/viewtopic.php?id=208874 before that, the wireless is never becoming available and no firmware found.

regards

Mike
Comment 4 Thomas Backlund 2016-05-11 16:42:36 CEST
There should be no symlink !
We are shipping the official upstream firmwware-4.bin.

Please clean up the firmware dir as root:

rm -rf /lib/firmware/ath10k/QCA6174

then re-install the mageia firmware package with:
urpmi.update ""
urpmi --media "Nonfree Updates Testing" --replacepkgs kernel-firmware-nonfree

then reboot.

if it does not work, then please attach kernel logs (output of dmesg and journalctl -b) to this report
Comment 5 Mike Burgener 2016-05-11 18:54:01 CEST
ok, it still loads wifi however in second step, as it seems to first look at firmware-5.bin the logfile has been attached, however still it does very late initialization of the interface and i have to manually connect using the network applet, no mater what i set in the wifi configuration.
Comment 6 Mike Burgener 2016-05-11 18:54:59 CEST
Created attachment 7781 [details]
most recent kernel logfile when it tries to load firmware-5
Comment 7 Thomas Backlund 2016-05-11 21:12:43 CEST
Ok, thanks.

Now, it wont help to symlink or copy firmware-4 to firmware-5...
It will silence the message, but that's all, no technical gain what so ever.

QCA has not yet released any api 5 firmware, so for now you will have to live with that.

And that message is only an informal one that it would prefer firmware-5, but as that does not exist, it simply falls back to firmware-4 and works...

This is how most wireless drivers works... they have a range of supported firmware apis and a preferred one wich thy try first, and uses the older ones as fallbacks..

As for the wireless failing to auto-connect, you could try to remove wireless configs in mcc and try to enable and configure it with NetworkManager instead.


For some users that works better, is more stable...
We are slowly moving to using NetworkManager ...
Comment 8 Mike Burgener 2016-05-11 21:49:49 CEST
ok, thanks for that information.

still it cannot be considered normal that even using iwconfig it takes much time till there is an interface available, will play around a bit and keep this up2date if it changes anything using networkmanager

regards

Mike
Comment 9 Mike Burgener 2016-05-14 12:24:23 CEST
changed to networkmanager, however the initialization of the device itself still takes forever (till you see a wireless-interface in iwconfig for example)

regards

Mike
Comment 10 Mike Burgener 2016-07-19 20:29:53 CEST
just to keep it up2date still the same issue

all updates installed

regards

Mike
Comment 11 Marja Van Waes 2016-08-26 11:42:47 CEST
Mass-reassigning all bugs with "kernel" in the Source RPM field that are assigned to tmb, to the kernel packagers group, because tmb is currently MIA.

Assignee: tmb => kernel

Comment 12 Mike Burgener 2016-11-08 08:39:54 CET
this seems to be fixed in the latest kernel/firmware packages so i'll close it.

regards

Mike

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.