More than one ath10k NIC in 3.19.0-rc5?

More than one ath10k NIC in 3.19.0-rc5?

[Ben Greear]

I tried running a patched version of 3.19.0-rc5 kernel, and it seems to work
fine when there is one ath10k NIC in the system, but when there is two it
doesn't try to load the firmware.

Hacked 3.17.8+ works fine.

Anyone tried more than one ath10k NIC in 3.19 kernel?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC in 3.19.0-rc5?

[Sebastian Gottschall]

Am 20.01.2015 um 22:53 schrieb Ben Greear:
> I tried running a patched version of 3.19.0-rc5 kernel, and it seems to work
> fine when there is one ath10k NIC in the system, but when there is two it
> doesn't try to load the firmware.
>
> Hacked 3.17.8+ works fine.
>
> Anyone tried more than one ath10k NIC in 3.19 kernel?
>
> Thanks,
> Ben
standard x86 system? i just can say that with 3.18 i have big troubles 
with the new pci bus code introduced on several embedded devices.
so maybe the reason is here?
>


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC in 3.19.0-rc5?

[Ben Greear]

On 01/20/2015 06:13 PM, Sebastian Gottschall wrote:
> Am 20.01.2015 um 22:53 schrieb Ben Greear:
>> I tried running a patched version of 3.19.0-rc5 kernel, and it seems to work
>> fine when there is one ath10k NIC in the system, but when there is two it
>> doesn't try to load the firmware.
>>
>> Hacked 3.17.8+ works fine.
>>
>> Anyone tried more than one ath10k NIC in 3.19 kernel?
>>
>> Thanks,
>> Ben
> standard x86 system? i just can say that with 3.18 i have big troubles with the new pci bus code introduced on several embedded devices.
> so maybe the reason is here?

Standard 64-bit x86.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC in 3.19.0-rc5?

[Ben Greear]

On 01/20/2015 06:49 PM, Ben Greear wrote:
> On 01/20/2015 06:13 PM, Sebastian Gottschall wrote:
>> Am 20.01.2015 um 22:53 schrieb Ben Greear:
>>> I tried running a patched version of 3.19.0-rc5 kernel, and it seems to work
>>> fine when there is one ath10k NIC in the system, but when there is two it
>>> doesn't try to load the firmware.
>>>
>>> Hacked 3.17.8+ works fine.
>>>
>>> Anyone tried more than one ath10k NIC in 3.19 kernel?
>>>
>>> Thanks,
>>> Ben
>> standard x86 system? i just can say that with 3.18 i have big troubles with the new pci bus code introduced on several embedded devices.
>> so maybe the reason is here?
> 
> Standard 64-bit x86.

Looks like 3.19.0-rc2 is OK, -rc5 is busted.  I'll bisect...

Thanks,
Ben

> 
> Thanks,
> Ben
> 
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC in 3.19.0-rc5?

[Ben Greear]

On 01/21/2015 11:01 AM, Ben Greear wrote:
> On 01/20/2015 06:49 PM, Ben Greear wrote:
>> On 01/20/2015 06:13 PM, Sebastian Gottschall wrote:
>>> Am 20.01.2015 um 22:53 schrieb Ben Greear:
>>>> I tried running a patched version of 3.19.0-rc5 kernel, and it seems to work
>>>> fine when there is one ath10k NIC in the system, but when there is two it
>>>> doesn't try to load the firmware.
>>>>
>>>> Hacked 3.17.8+ works fine.
>>>>
>>>> Anyone tried more than one ath10k NIC in 3.19 kernel?
>>>>
>>>> Thanks,
>>>> Ben
>>> standard x86 system? i just can say that with 3.18 i have big troubles with the new pci bus code introduced on several embedded devices.
>>> so maybe the reason is here?
>>
>> Standard 64-bit x86.
> 
> Looks like 3.19.0-rc2 is OK, -rc5 is busted.  I'll bisect...

Err, no.  rc2 is busted too...sometimes first NIC loads, sometimes
second, but not both at once....doing bigger bisect...

Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC will not load (bisected)

[Ben Greear]

On 01/21/2015 11:47 AM, Ben Greear wrote:
> On 01/21/2015 11:01 AM, Ben Greear wrote:
>> On 01/20/2015 06:49 PM, Ben Greear wrote:
>>> On 01/20/2015 06:13 PM, Sebastian Gottschall wrote:
>>>> Am 20.01.2015 um 22:53 schrieb Ben Greear:
>>>>> I tried running a patched version of 3.19.0-rc5 kernel, and it seems to work
>>>>> fine when there is one ath10k NIC in the system, but when there is two it
>>>>> doesn't try to load the firmware.

Ok, this bisects to this commit.  First (or sometimes second) NIC will load,
but the other one will not load firmware.  No obvious errors in dmesg.

Platform is x86-64, Fedora 20.  NICS:

03:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless Network Adapter
04:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless Network Adapter


7c0f0e3c9797e5a08d15da68812f24eadaf9e82b is the first bad commit
commit 7c0f0e3c9797e5a08d15da68812f24eadaf9e82b
Author: Michal Kazior <michal.kazior@tieto.com>
Date:   Mon Oct 20 14:14:38 2014 +0200

    ath10k: mask/unmask msi fw irq

    This was the final missing bit to making sure the
    device doesn't assert interrupts to host.

    This should fix possible race when target crashes
    during driver teardown.

    This also removes an early warm reset workaround
    during pci probing.

    Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

:040000 040000 f7ab5ff9f7e3713118dab6f23d02f11003de6fef fa5cb5ee76bdee2c654fcb8e6b8b1283c225bcc2 M	drivers

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC will not load (bisected)

[Michal Kazior]

On 22 January 2015 at 22:08, Ben Greear <greearb@candelatech.com> wrote:
>
> On 01/21/2015 11:47 AM, Ben Greear wrote:
>> On 01/21/2015 11:01 AM, Ben Greear wrote:
>>> On 01/20/2015 06:49 PM, Ben Greear wrote:
>>>> On 01/20/2015 06:13 PM, Sebastian Gottschall wrote:
>>>>> Am 20.01.2015 um 22:53 schrieb Ben Greear:
>>>>>> I tried running a patched version of 3.19.0-rc5 kernel, and it seems to work
>>>>>> fine when there is one ath10k NIC in the system, but when there is two it
>>>>>> doesn't try to load the firmware.
>
> Ok, this bisects to this commit.  First (or sometimes second) NIC will load,
> but the other one will not load firmware.  No obvious errors in dmesg.

So I'm confused. If it doesn't load firmware then there has to be some
error in dmesg. If there are no errors then how come you know it
doesn't load firmware? Is it being probed at all?


> Platform is x86-64, Fedora 20.  NICS:
>
> 03:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless Network Adapter
> 04:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless Network Adapter
>
>
> 7c0f0e3c9797e5a08d15da68812f24eadaf9e82b is the first bad commit
> commit 7c0f0e3c9797e5a08d15da68812f24eadaf9e82b
> Author: Michal Kazior <michal.kazior@tieto.com>
> Date:   Mon Oct 20 14:14:38 2014 +0200
>
>     ath10k: mask/unmask msi fw irq
>
>     This was the final missing bit to making sure the
>     device doesn't assert interrupts to host.
>
>     This should fix possible race when target crashes
>     during driver teardown.
>
>     This also removes an early warm reset workaround
>     during pci probing.
>
>     Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>     Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>
> :040000 040000 f7ab5ff9f7e3713118dab6f23d02f11003de6fef fa5cb5ee76bdee2c654fcb8e6b8b1283c225bcc2 M      drivers

Hmm.. This removes warm_reset in probe function but I fail to see how
this could end up not loading one of the NIC *silently*?

Anyway there's a pending patch which adds the reset back:
https://github.com/kvalo/ath/commit/bdcd6f4e4ac5d2d2a56da4813f56655e6db0ee45
. You might want to try it and see if it helps.


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC will not load (bisected)

[Ben Greear]

On 01/22/2015 10:43 PM, Michal Kazior wrote:
> On 22 January 2015 at 22:08, Ben Greear <greearb@candelatech.com> wrote:
>>
>> On 01/21/2015 11:47 AM, Ben Greear wrote:
>>> On 01/21/2015 11:01 AM, Ben Greear wrote:
>>>> On 01/20/2015 06:49 PM, Ben Greear wrote:
>>>>> On 01/20/2015 06:13 PM, Sebastian Gottschall wrote:
>>>>>> Am 20.01.2015 um 22:53 schrieb Ben Greear:
>>>>>>> I tried running a patched version of 3.19.0-rc5 kernel, and it seems to work
>>>>>>> fine when there is one ath10k NIC in the system, but when there is two it
>>>>>>> doesn't try to load the firmware.
>>
>> Ok, this bisects to this commit.  First (or sometimes second) NIC will load,
>> but the other one will not load firmware.  No obvious errors in dmesg.
>
> So I'm confused. If it doesn't load firmware then there has to be some
> error in dmesg. If there are no errors then how come you know it
> doesn't load firmware? Is it being probed at all?
>
>
>> Platform is x86-64, Fedora 20.  NICS:
>>
>> 03:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless Network Adapter
>> 04:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless Network Adapter
>>
>>
>> 7c0f0e3c9797e5a08d15da68812f24eadaf9e82b is the first bad commit
>> commit 7c0f0e3c9797e5a08d15da68812f24eadaf9e82b
>> Author: Michal Kazior <michal.kazior@tieto.com>
>> Date:   Mon Oct 20 14:14:38 2014 +0200
>>
>>      ath10k: mask/unmask msi fw irq
>>
>>      This was the final missing bit to making sure the
>>      device doesn't assert interrupts to host.
>>
>>      This should fix possible race when target crashes
>>      during driver teardown.
>>
>>      This also removes an early warm reset workaround
>>      during pci probing.
>>
>>      Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>>      Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>>
>> :040000 040000 f7ab5ff9f7e3713118dab6f23d02f11003de6fef fa5cb5ee76bdee2c654fcb8e6b8b1283c225bcc2 M      drivers
>
> Hmm.. This removes warm_reset in probe function but I fail to see how
> this could end up not loading one of the NIC *silently*?
>
> Anyway there's a pending patch which adds the reset back:
> https://github.com/kvalo/ath/commit/bdcd6f4e4ac5d2d2a56da4813f56655e6db0ee45
> . You might want to try it and see if it helps.

Reverting the patch made it work again for me.

I don't understand that code well, but perhaps you are disabling
a shared interrupt that silently stops the second NIC from
being able to do it's thing?

Do you have a PC with 2 NICs in it that you could try yourself?

I can grab you the logs of a failure to boot later today.

Thanks,
Ben

>
>
> Michał
>

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC will not load (bisected)

[Janusz Dziedzic]

On 23 January 2015 at 16:54, Ben Greear <greearb@candelatech.com> wrote:
>
>
> On 01/22/2015 10:43 PM, Michal Kazior wrote:
>>
>> On 22 January 2015 at 22:08, Ben Greear <greearb@candelatech.com> wrote:
>>>
>>>
>>> On 01/21/2015 11:47 AM, Ben Greear wrote:
>>>>
>>>> On 01/21/2015 11:01 AM, Ben Greear wrote:
>>>>>
>>>>> On 01/20/2015 06:49 PM, Ben Greear wrote:
>>>>>>
>>>>>> On 01/20/2015 06:13 PM, Sebastian Gottschall wrote:
>>>>>>>
>>>>>>> Am 20.01.2015 um 22:53 schrieb Ben Greear:
>>>>>>>>
>>>>>>>> I tried running a patched version of 3.19.0-rc5 kernel, and it seems
>>>>>>>> to work
>>>>>>>> fine when there is one ath10k NIC in the system, but when there is
>>>>>>>> two it
>>>>>>>> doesn't try to load the firmware.
>>>
>>>
>>> Ok, this bisects to this commit.  First (or sometimes second) NIC will
>>> load,
>>> but the other one will not load firmware.  No obvious errors in dmesg.
>>
>>
>> So I'm confused. If it doesn't load firmware then there has to be some
>> error in dmesg. If there are no errors then how come you know it
>> doesn't load firmware? Is it being probed at all?
>>
>>
>>> Platform is x86-64, Fedora 20.  NICS:
>>>
>>> 03:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless
>>> Network Adapter
>>> 04:00.0 Network controller: Qualcomm Atheros QCA988x 802.11ac Wireless
>>> Network Adapter
>>>
>>>
>>> 7c0f0e3c9797e5a08d15da68812f24eadaf9e82b is the first bad commit
>>> commit 7c0f0e3c9797e5a08d15da68812f24eadaf9e82b
>>> Author: Michal Kazior <michal.kazior@tieto.com>
>>> Date:   Mon Oct 20 14:14:38 2014 +0200
>>>
>>>      ath10k: mask/unmask msi fw irq
>>>
>>>      This was the final missing bit to making sure the
>>>      device doesn't assert interrupts to host.
>>>
>>>      This should fix possible race when target crashes
>>>      during driver teardown.
>>>
>>>      This also removes an early warm reset workaround
>>>      during pci probing.
>>>
>>>      Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>>>      Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>>>
>>> :040000 040000 f7ab5ff9f7e3713118dab6f23d02f11003de6fef
>>> fa5cb5ee76bdee2c654fcb8e6b8b1283c225bcc2 M      drivers
>>
>>
>> Hmm.. This removes warm_reset in probe function but I fail to see how
>> this could end up not loading one of the NIC *silently*?
>>
>> Anyway there's a pending patch which adds the reset back:
>>
>> https://github.com/kvalo/ath/commit/bdcd6f4e4ac5d2d2a56da4813f56655e6db0ee45
>> . You might want to try it and see if it helps.
>
>
> Reverting the patch made it work again for me.
>
> I don't understand that code well, but perhaps you are disabling
> a shared interrupt that silently stops the second NIC from
> being able to do it's thing?
>
> Do you have a PC with 2 NICs in it that you could try yourself?
>
I have laptop with 2 ath10k cards (one internal one external), and yes
I had some problems, but that was timeout issue (I am not sure,
reading chip_id), but we fixed this.

> I can grab you the logs of a failure to boot later today.
>
Please send logs.

BR
Janusz

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC will not load (bisected)

[Kalle Valo]

Ben Greear <greearb@candelatech.com> writes:

>> Hmm.. This removes warm_reset in probe function but I fail to see how
>> this could end up not loading one of the NIC *silently*?
>>
>> Anyway there's a pending patch which adds the reset back:
>> https://github.com/kvalo/ath/commit/bdcd6f4e4ac5d2d2a56da4813f56655e6db0ee45
>> . You might want to try it and see if it helps.
>
> Reverting the patch made it work again for me.
>
> I don't understand that code well, but perhaps you are disabling
> a shared interrupt that silently stops the second NIC from
> being able to do it's thing?
>
> Do you have a PC with 2 NICs in it that you could try yourself?
>
> I can grab you the logs of a failure to boot later today.

What should we do with this one? I didn't look at the details yet, but
do we have any other option than to revert?

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC will not load (bisected)

[Michal Kazior]

On 4 February 2015 at 10:07, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>>> Hmm.. This removes warm_reset in probe function but I fail to see how
>>> this could end up not loading one of the NIC *silently*?
>>>
>>> Anyway there's a pending patch which adds the reset back:
>>> https://github.com/kvalo/ath/commit/bdcd6f4e4ac5d2d2a56da4813f56655e6db0ee45
>>> . You might want to try it and see if it helps.
>>
>> Reverting the patch made it work again for me.
>>
>> I don't understand that code well, but perhaps you are disabling
>> a shared interrupt that silently stops the second NIC from
>> being able to do it's thing?
>>
>> Do you have a PC with 2 NICs in it that you could try yourself?
>>
>> I can grab you the logs of a failure to boot later today.
>
> What should we do with this one? I didn't look at the details yet, but
> do we have any other option than to revert?

I believe this is an issue in Ben's userspace (he sent me logs
privately) or some sort of kernel event bug. It basically looked like
this: both devices were detected by ath10k and both started
register_work. One of the devices loaded all the way while the other
tried to load a few non-existing firmware files and it stopped. Few
minutes later there was a hung task splat pointing to
request_firmware() called from ath10k suggesting userspace didn't
handle firmware request.

The "offending" patch effectively removed 200ms from probe() in
ath10k. This could've change timing on request_firmware() calls on
Ben's system. Btw. the 200ms is back again now with
1a7fecb766c83dace747f42b25bbb544b00a0163 ("ath10k: reset chip before
reading chip_id in probe").

Marek tried running 2 qca988x on his laptop some time ago (with and
without the extra timing) and didn't have any issues.


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC will not load (bisected)

[Kalle Valo]

Michal Kazior <michal.kazior@tieto.com> writes:

> On 4 February 2015 at 10:07, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Ben Greear <greearb@candelatech.com> writes:
>>
>>>> Hmm.. This removes warm_reset in probe function but I fail to see how
>>>> this could end up not loading one of the NIC *silently*?
>>>>
>>>> Anyway there's a pending patch which adds the reset back:
>>>> https://github.com/kvalo/ath/commit/bdcd6f4e4ac5d2d2a56da4813f56655e6db0ee45
>>>> . You might want to try it and see if it helps.
>>>
>>> Reverting the patch made it work again for me.
>>>
>>> I don't understand that code well, but perhaps you are disabling
>>> a shared interrupt that silently stops the second NIC from
>>> being able to do it's thing?
>>>
>>> Do you have a PC with 2 NICs in it that you could try yourself?
>>>
>>> I can grab you the logs of a failure to boot later today.
>>
>> What should we do with this one? I didn't look at the details yet, but
>> do we have any other option than to revert?
>
> I believe this is an issue in Ben's userspace (he sent me logs
> privately) or some sort of kernel event bug. It basically looked like
> this: both devices were detected by ath10k and both started
> register_work. One of the devices loaded all the way while the other
> tried to load a few non-existing firmware files and it stopped. Few
> minutes later there was a hung task splat pointing to
> request_firmware() called from ath10k suggesting userspace didn't
> handle firmware request.
>
> The "offending" patch effectively removed 200ms from probe() in
> ath10k. This could've change timing on request_firmware() calls on
> Ben's system. Btw. the 200ms is back again now with
> 1a7fecb766c83dace747f42b25bbb544b00a0163 ("ath10k: reset chip before
> reading chip_id in probe").
>
> Marek tried running 2 qca988x on his laptop some time ago (with and
> without the extra timing) and didn't have any issues.

Good, thanks for checking this.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC will not load (bisected)

[Ben Greear]

On 02/04/2015 01:35 AM, Michal Kazior wrote:
> On 4 February 2015 at 10:07, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Ben Greear <greearb@candelatech.com> writes:
>>
>>>> Hmm.. This removes warm_reset in probe function but I fail to see how
>>>> this could end up not loading one of the NIC *silently*?
>>>>
>>>> Anyway there's a pending patch which adds the reset back:
>>>> https://github.com/kvalo/ath/commit/bdcd6f4e4ac5d2d2a56da4813f56655e6db0ee45
>>>> . You might want to try it and see if it helps.
>>>
>>> Reverting the patch made it work again for me.
>>>
>>> I don't understand that code well, but perhaps you are disabling
>>> a shared interrupt that silently stops the second NIC from
>>> being able to do it's thing?
>>>
>>> Do you have a PC with 2 NICs in it that you could try yourself?
>>>
>>> I can grab you the logs of a failure to boot later today.
>>
>> What should we do with this one? I didn't look at the details yet, but
>> do we have any other option than to revert?
>
> I believe this is an issue in Ben's userspace (he sent me logs
> privately) or some sort of kernel event bug. It basically looked like
> this: both devices were detected by ath10k and both started
> register_work. One of the devices loaded all the way while the other
> tried to load a few non-existing firmware files and it stopped. Few
> minutes later there was a hung task splat pointing to
> request_firmware() called from ath10k suggesting userspace didn't
> handle firmware request.
>
> The "offending" patch effectively removed 200ms from probe() in
> ath10k. This could've change timing on request_firmware() calls on
> Ben's system. Btw. the 200ms is back again now with
> 1a7fecb766c83dace747f42b25bbb544b00a0163 ("ath10k: reset chip before
> reading chip_id in probe").
>
> Marek tried running 2 qca988x on his laptop some time ago (with and
> without the extra timing) and didn't have any issues.

I can retry my system with stock Fedora 20 and see if it works there.

If not, then I think it still needs to be worked on...you agree?

Thanks,
Ben



-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC will not load (bisected)

[Michal Kazior]

On 4 February 2015 at 16:23, Ben Greear <greearb@candelatech.com> wrote:
> On 02/04/2015 01:35 AM, Michal Kazior wrote:
>>
>> On 4 February 2015 at 10:07, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>>>
>>> Ben Greear <greearb@candelatech.com> writes:
>>>
>>>>> Hmm.. This removes warm_reset in probe function but I fail to see how
>>>>> this could end up not loading one of the NIC *silently*?
>>>>>
>>>>> Anyway there's a pending patch which adds the reset back:
>>>>>
>>>>> https://github.com/kvalo/ath/commit/bdcd6f4e4ac5d2d2a56da4813f56655e6db0ee45
>>>>> . You might want to try it and see if it helps.
>>>>
>>>>
>>>> Reverting the patch made it work again for me.
>>>>
>>>> I don't understand that code well, but perhaps you are disabling
>>>> a shared interrupt that silently stops the second NIC from
>>>> being able to do it's thing?
>>>>
>>>> Do you have a PC with 2 NICs in it that you could try yourself?
>>>>
>>>> I can grab you the logs of a failure to boot later today.
>>>
>>>
>>> What should we do with this one? I didn't look at the details yet, but
>>> do we have any other option than to revert?
>>
>>
>> I believe this is an issue in Ben's userspace (he sent me logs
>> privately) or some sort of kernel event bug. It basically looked like
>> this: both devices were detected by ath10k and both started
>> register_work. One of the devices loaded all the way while the other
>> tried to load a few non-existing firmware files and it stopped. Few
>> minutes later there was a hung task splat pointing to
>> request_firmware() called from ath10k suggesting userspace didn't
>> handle firmware request.
>>
>> The "offending" patch effectively removed 200ms from probe() in
>> ath10k. This could've change timing on request_firmware() calls on
>> Ben's system. Btw. the 200ms is back again now with
>> 1a7fecb766c83dace747f42b25bbb544b00a0163 ("ath10k: reset chip before
>> reading chip_id in probe").
>>
>> Marek tried running 2 qca988x on his laptop some time ago (with and
>> without the extra timing) and didn't have any issues.
>
>
> I can retry my system with stock Fedora 20 and see if it works there.
>
> If not, then I think it still needs to be worked on...you agree?

In the driver? I'd argue. I don't see how ath10k could make
request_firmware() hang, do you?


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: More than one ath10k NIC will not load (bisected)

[Ben Greear]

On 02/04/2015 10:02 PM, Michal Kazior wrote:
> On 4 February 2015 at 16:23, Ben Greear <greearb@candelatech.com> wrote:
>> On 02/04/2015 01:35 AM, Michal Kazior wrote:
>>>
>>> On 4 February 2015 at 10:07, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>>>>
>>>> Ben Greear <greearb@candelatech.com> writes:
>>>>
>>>>>> Hmm.. This removes warm_reset in probe function but I fail to see how
>>>>>> this could end up not loading one of the NIC *silently*?
>>>>>>
>>>>>> Anyway there's a pending patch which adds the reset back:
>>>>>>
>>>>>> https://github.com/kvalo/ath/commit/bdcd6f4e4ac5d2d2a56da4813f56655e6db0ee45
>>>>>> . You might want to try it and see if it helps.
>>>>>
>>>>>
>>>>> Reverting the patch made it work again for me.
>>>>>
>>>>> I don't understand that code well, but perhaps you are disabling
>>>>> a shared interrupt that silently stops the second NIC from
>>>>> being able to do it's thing?
>>>>>
>>>>> Do you have a PC with 2 NICs in it that you could try yourself?
>>>>>
>>>>> I can grab you the logs of a failure to boot later today.
>>>>
>>>>
>>>> What should we do with this one? I didn't look at the details yet, but
>>>> do we have any other option than to revert?
>>>
>>>
>>> I believe this is an issue in Ben's userspace (he sent me logs
>>> privately) or some sort of kernel event bug. It basically looked like
>>> this: both devices were detected by ath10k and both started
>>> register_work. One of the devices loaded all the way while the other
>>> tried to load a few non-existing firmware files and it stopped. Few
>>> minutes later there was a hung task splat pointing to
>>> request_firmware() called from ath10k suggesting userspace didn't
>>> handle firmware request.
>>>
>>> The "offending" patch effectively removed 200ms from probe() in
>>> ath10k. This could've change timing on request_firmware() calls on
>>> Ben's system. Btw. the 200ms is back again now with
>>> 1a7fecb766c83dace747f42b25bbb544b00a0163 ("ath10k: reset chip before
>>> reading chip_id in probe").
>>>
>>> Marek tried running 2 qca988x on his laptop some time ago (with and
>>> without the extra timing) and didn't have any issues.
>>
>>
>> I can retry my system with stock Fedora 20 and see if it works there.
>>
>> If not, then I think it still needs to be worked on...you agree?
>
> In the driver? I'd argue. I don't see how ath10k could make
> request_firmware() hang, do you?

I can lard up the kernel with lockdep and related things and see if
that offers some clues.  Will be a bit though, I'm pretty busy
with other things at the moment.

Thanks,
Ben

>
>
> Michał
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

AW: More than one ath10k NIC will not load (bisected)

[Conrad Kostecki]

> Do you have a PC with 2 NICs in it that you could try yourself?

I have two ath10k cards build in my soekris.
Those are working fine without any problems.
Both cards are loading fine.

[    2.731750] ath10k_pci 0000:07:00.0: PCI->APIC IRQ transform: INT A -> IRQ 17
[    3.037142] ath10k_pci 0000:07:00.0: irq 42 for MSI/MSI-X
[    3.037192] ath10k_pci 0000:07:00.0: pci irq msi interrupts 1 irq_mode 0 reset_mode 0
[    3.037564] ath10k_pci 0000:0c:00.0: PCI->APIC IRQ transform: INT A -> IRQ 18
[    3.340106] ath10k_pci 0000:0c:00.0: irq 43 for MSI/MSI-X
[    3.340145] ath10k_pci 0000:0c:00.0: pci irq msi interrupts 1 irq_mode 0 reset_mode 0
[    4.461521] ath10k_pci 0000:07:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 api 3 htt 2.1
[    4.469965] ath10k_pci 0000:07:00.0: debug 0 debugfs 0 tracing 0 dfs 1 testmode 0
[    5.070084] ath: EEPROM regdomain: 0x0
[    5.070086] ath: EEPROM indicates default country code should be used
[    5.070087] ath: doing EEPROM country->regdmn map search
[    5.070090] ath: country maps to regdmn code: 0x37
[    5.070092] ath: Country alpha2 being used: DE
[    5.070093] ath: Regpair used: 0x37
[    5.085625] ath10k_pci 0000:0c:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 api 3 htt 2.1
[    5.085631] ath10k_pci 0000:0c:00.0: debug 0 debugfs 0 tracing 0 dfs 1 testmode 0
[    5.680073] ath: EEPROM regdomain: 0x0
[    5.680078] ath: EEPROM indicates default country code should be used
[    5.680080] ath: doing EEPROM country->regdmn map search
[    5.680083] ath: country maps to regdmn code: 0x37
[    5.680085] ath: Country alpha2 being used: DE
[    5.680087] ath: Regpair used: 0x37

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k