diff mbox

Reporting a bug for QCA6174 802.11ac

Message ID CAAf+CsCKx3p=TdWZxbSi9JRfKUicCqyAUaP-Kzxgj1N6XK0WqQ@mail.gmail.com (mailing list archive)
State RFC
Delegated to: Kalle Valo
Headers show

Commit Message

Guilherme Íscaro March 28, 2017, 5:45 p.m. UTC
Hello everyone,

I would like to inform that I "fixed" the problem. After my last
email, I cloned the linux repo and started to hack around the driver
source code. By looking at the dmesg output that I provided to you
guys, I noticed that for some reason the board was not being properly
awake ( ath10k_pci_wake_wait() returns ETIMEOUT). I so sick with this
problem that I hardcoded "ar_pci->pci_ps" to false, thus the board
can't sleep now.

Please, send some thoughts.

I attached the patch so you guys can take a look.

Thanks.

2017-03-23 20:11 GMT-03:00 Guilherme Íscaro <cabelitostos@gmail.com>:
> Hello Ryan, thanks for your contact.
>
> My AP is a D-link DMG 6661. I'll try another wifi settings and check
> if it happens and if it happens I'll provide de ftrace logs.
>
> Btw, just after I read your email the bug happened. Here's the full
> dmesg. After the "failed to wake target" problem happens it keeps
> flooding dmesg forever. There are no other error indications.
>
> I guess that the dmesg output will not help us, maybe ftrace will be
> more helpful. Anyway, here's the dmesg...
>
> Thanks for your help
>
> 2017-03-23 19:46 GMT-03:00 Ryan Hsu <ryanhsu@qca.qualcomm.com>:
>> Let's start from the basic, could you provide the ftrace logs and also the AP model you're using? try without security or different phy mode to see if it would behave differently?
>>
>> The last thing is, your previous logs only stuffed with the register access failure logs, can you share a full dmesg logs as well?
>>
>> Ryan
>> ________________________________________
>> From: Guilherme Íscaro <cabelitostos@gmail.com>
>> Sent: Wednesday, March 22, 2017 3:17 PM
>> To: Ryan Hsu
>> Cc: ath10k@lists.infradead.org
>> Subject: Re: Reporting a bug for QCA6174 802.11ac
>>
>> Hi, unfortunately the problem happened with the new drivers and firmware. :[
>> I really don't know what to do anymore.....
>>
>> thanks.
>>
>> 2017-03-22 10:56 GMT-03:00 Guilherme Íscaro <cabelitostos@gmail.com>:
>>> I've installed the new firmware/driver. I'll send a new email in some
>>> days to tell you guys if the new driver/firmware resolved the problem.
>>>
>>> Thanks for the help.
>>>
>>> 2017-03-21 15:58 GMT-03:00 Guilherme Íscaro <cabelitostos@gmail.com>:
>>>> Hello Ryan, Thanks for your response.
>>>>
>>>> My AP is in the same room that I use my notebook, it's right in front
>>>> of me. There's no specific scenario for this failure to happen.
>>>> Sometimes it does not happens for days, but sometimes it happens 3/4
>>>> times in the same day.
>>>> It looks like that there is not specific scenario, sometimes it
>>>> happens while I'm using firefox, sometimes it happens when my laptop
>>>> is "doing nothing". (Was it helpful?)
>>>>
>>>> I'm using WiFi 802.11n, 2.4ghz with AES.
>>>>
>>>> I'll try this new firmware/driver.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>> 2017-03-21 15:35 GMT-03:00 Ryan Hsu <ryanhsu@qca.qualcomm.com>:
>>>>> Iscaro,
>>>>>
>>>>> Not sure how exactly the issue and scenario of your usage.
>>>>>
>>>>> e.g how far the AP from you and is there any specific scenario you're seeing the failure open?
>>>>>
>>>>> Also would you mind try to pick up the latest firmware to see if that help?
>>>>> https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0/4.4
>>>>>
>>>>> With the latest firmware, you might also need to get the latest driver backport package.
>>>>> http://buildbot.w1.fi/backports-wireless-testing/
>>>>>
>>>>> Ryan
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ath10k [mailto:ath10k-bounces@lists.infradead.org] On Behalf Of
>>>>>> Guilherme Íscaro
>>>>>> Sent: Monday, March 20, 2017 08:32 AM
>>>>>> To: ath10k@lists.infradead.org
>>>>>> Subject: Reporting a bug for QCA6174 802.11ac
>>>>>>
>>>>>> Hello everyone, I would like to report a bug for QCA6174.
>>>>>>
>>>>>> I use WiFi everyday, but from time to time I lose my connection. This might be
>>>>>> related to a firmware problem, because after I lose my connection the firmware
>>>>>> keeps flooding dmesg about problems.
>>>>>>
>>>>>> I have this problem since I  bought my laptop (which was last year) and I do
>>>>>> regular updates in my system.
>>>>>>
>>>>>> P.S: dmest output attached.
>>>>>>
>>>>>> My system:
>>>>>>
>>>>>> Dist: Arch Linux.
>>>>>> Kernel: 4.10.3-1
>>>>>> Linux-firmware version: 20170309.695f2d6-1 (commit 695f2d6d82173f4e...
>>>>>> from linux-firmware)
>>>>>> Board: 02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac
>>>>>> Wireless Network Adapter (rev 32)
>>>>>>
>>>>>>
>>>>>> Please, let me know if I should provide more info.
>>>>>>
>>>>>> Thanks.

Comments

Kalle Valo March 31, 2017, 11:12 a.m. UTC | #1
Guilherme Íscaro <cabelitostos@gmail.com> writes:

> I would like to inform that I "fixed" the problem. After my last

> email, I cloned the linux repo and started to hack around the driver

> source code. By looking at the dmesg output that I provided to you

> guys, I noticed that for some reason the board was not being properly

> awake ( ath10k_pci_wake_wait() returns ETIMEOUT). I so sick with this

> problem that I hardcoded "ar_pci->pci_ps" to false, thus the board

> can't sleep now.


Sounds like a problem with your PCI bus or the platform/laptop so try
different PCI settings both on BIOS and kernel. I have seen lots of talk
about ASPM, especially with some iwlwifi devices, so you should also
investigate about that.

Please let us know if you find anything, it's always valuable
information. Have fun googling :)

-- 
Kalle Valo
Adrian Chadd March 31, 2017, 3:11 p.m. UTC | #2
hiya,

hm, what's the reference driver do for pci powersave versus aspm? Does
it change any pci config space register settings for allowable sleep
states?



-adrian


On 31 March 2017 at 04:12, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Guilherme Íscaro <cabelitostos@gmail.com> writes:
>
>> I would like to inform that I "fixed" the problem. After my last
>> email, I cloned the linux repo and started to hack around the driver
>> source code. By looking at the dmesg output that I provided to you
>> guys, I noticed that for some reason the board was not being properly
>> awake ( ath10k_pci_wake_wait() returns ETIMEOUT). I so sick with this
>> problem that I hardcoded "ar_pci->pci_ps" to false, thus the board
>> can't sleep now.
>
> Sounds like a problem with your PCI bus or the platform/laptop so try
> different PCI settings both on BIOS and kernel. I have seen lots of talk
> about ASPM, especially with some iwlwifi devices, so you should also
> investigate about that.
>
> Please let us know if you find anything, it's always valuable
> information. Have fun googling :)
>
> --
> Kalle Valo
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
Guilherme Íscaro April 5, 2017, 7:48 p.m. UTC | #3
Hi, I have a question

Are you sure this is an ASPM problem? I've disable pcie_aspm during
boot (Kernel boot option - pcie_aspm=off) and the problem still
persists.

2017-03-31 12:11 GMT-03:00 Adrian Chadd <adrian@freebsd.org>:
> hiya,
>
> hm, what's the reference driver do for pci powersave versus aspm? Does
> it change any pci config space register settings for allowable sleep
> states?
>
>
>
> -adrian
>
>
> On 31 March 2017 at 04:12, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Guilherme Íscaro <cabelitostos@gmail.com> writes:
>>
>>> I would like to inform that I "fixed" the problem. After my last
>>> email, I cloned the linux repo and started to hack around the driver
>>> source code. By looking at the dmesg output that I provided to you
>>> guys, I noticed that for some reason the board was not being properly
>>> awake ( ath10k_pci_wake_wait() returns ETIMEOUT). I so sick with this
>>> problem that I hardcoded "ar_pci->pci_ps" to false, thus the board
>>> can't sleep now.
>>
>> Sounds like a problem with your PCI bus or the platform/laptop so try
>> different PCI settings both on BIOS and kernel. I have seen lots of talk
>> about ASPM, especially with some iwlwifi devices, so you should also
>> investigate about that.
>>
>> Please let us know if you find anything, it's always valuable
>> information. Have fun googling :)
>>
>> --
>> Kalle Valo
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
Kalle Valo April 6, 2017, 3:52 a.m. UTC | #4
(please don't top post)

Guilherme Íscaro <cabelitostos@gmail.com> writes:

> Hi, I have a question


To whom?

> Are you sure this is an ASPM problem? I've disable pcie_aspm during

> boot (Kernel boot option - pcie_aspm=off) and the problem still

> persists.


ASPM was just one area to investigate. The real problem could be
anywhere.

-- 
Kalle Valo
diff mbox

Patch

From c3bc3e52998d8b6189da00391570359e17d1d359 Mon Sep 17 00:00:00 2001
From: Guilherme Iscaro <iscaro@profusion.mobi>
Date: Tue, 21 Mar 2017 10:05:40 -0300
Subject: [PATCH] FIX BUG.

---
 drivers/net/wireless/ath/ath10k/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index b541a1c74488..0da470b0aee4 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3187,7 +3187,7 @@  static int ath10k_pci_probe(struct pci_dev *pdev,
 	case QCA6164_2_1_DEVICE_ID:
 	case QCA6174_2_1_DEVICE_ID:
 		hw_rev = ATH10K_HW_QCA6174;
-		pci_ps = true;
+		pci_ps = false;
 		pci_soft_reset = ath10k_pci_warm_reset;
 		pci_hard_reset = ath10k_pci_qca6174_chip_reset;
 		break;
-- 
2.12.1