* Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
@ 2016-06-02 17:20 Manoharan, Rajkumar
2016-06-02 17:27 ` Ben Greear
2016-06-03 16:02 ` Valo, Kalle
0 siblings, 2 replies; 8+ messages in thread
From: Manoharan, Rajkumar @ 2016-06-02 17:20 UTC (permalink / raw)
To: nbd; +Cc: Valo, Kalle, ath10k, Rajkumar Manoharan
Found a regression in ath.git TOT that system hangs while probing qca99x0 device on x86_64 platform.
It seems the system hangs while DMA mapping of bigger memory chunks. Below are the list of memory
chucks requested by target for qca99x0 during service ready event. This issue is seen only on x86 platform.
No issues are observed on ARM platform (AP148). After reverting below commit able to bring up device on x86.
Jun 2 17:24:37 rmanohar-arch kernel: idx 0 pool_size 689816 num_units 529 unit_len 1304
Jun 2 17:24:37 rmanohar-arch kernel: idx 1 pool_size 17152 num_units 67 unit_len 256
Jun 2 17:24:37 rmanohar-arch kernel: idx 2 pool_size 68608 num_units 67 unit_len 1024
Jun 2 17:24:37 rmanohar-arch kernel: idx 3 pool_size 274432 num_units 67 unit_len 4096
Jun 2 17:24:37 rmanohar-arch kernel: idx 4 pool_size 107520 num_units 35 unit_len 3072
Jun 2 17:24:37 rmanohar-arch kernel: idx 5 pool_size 6144 num_units 1 unit_len 6144
Jun 2 17:24:37 rmanohar-arch kernel: idx 6 pool_size 865444 num_units 529 unit_len 1636
commit b057886524be060021e3cfad0ba8458c850330cd
Author: Felix Fietkau <nbd@openwrt.org>
Date: Mon Nov 30 19:32:01 2015 +0100
ath10k: do not use coherent memory for allocated device memory chunks
Coherent memory is more expensive to allocate (and constrained on some
architectures where it has to be pre-allocated). It is also completely
unnecessary, since the host has no reason to even access these allocated
memory spaces
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-Rajkumar
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
2016-06-02 17:20 Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath Manoharan, Rajkumar
@ 2016-06-02 17:27 ` Ben Greear
2016-06-02 17:46 ` Rajkumar Manoharan
2016-06-03 16:02 ` Valo, Kalle
1 sibling, 1 reply; 8+ messages in thread
From: Ben Greear @ 2016-06-02 17:27 UTC (permalink / raw)
To: Manoharan, Rajkumar, nbd; +Cc: Valo, Kalle, Rajkumar Manoharan, ath10k
On 06/02/2016 10:20 AM, Manoharan, Rajkumar wrote:
> Found a regression in ath.git TOT that system hangs while probing qca99x0 device on x86_64 platform.
> It seems the system hangs while DMA mapping of bigger memory chunks. Below are the list of memory
> chucks requested by target for qca99x0 during service ready event. This issue is seen only on x86 platform.
> No issues are observed on ARM platform (AP148). After reverting below commit able to bring up device on x86.
>
> Jun 2 17:24:37 rmanohar-arch kernel: idx 0 pool_size 689816 num_units 529 unit_len 1304
> Jun 2 17:24:37 rmanohar-arch kernel: idx 1 pool_size 17152 num_units 67 unit_len 256
> Jun 2 17:24:37 rmanohar-arch kernel: idx 2 pool_size 68608 num_units 67 unit_len 1024
> Jun 2 17:24:37 rmanohar-arch kernel: idx 3 pool_size 274432 num_units 67 unit_len 4096
> Jun 2 17:24:37 rmanohar-arch kernel: idx 4 pool_size 107520 num_units 35 unit_len 3072
> Jun 2 17:24:37 rmanohar-arch kernel: idx 5 pool_size 6144 num_units 1 unit_len 6144
> Jun 2 17:24:37 rmanohar-arch kernel: idx 6 pool_size 865444 num_units 529 unit_len 1636
We have seen similar. But, if we enable VT-d in our BIOS, then it works, at least in
our scenarios. I have not tried putting more than one 99x0 NIC in a system to date, so possibly
more than one would cause more issues, and I guess systems without VT-d might
fail too...
Thanks,
Ben
>
> commit b057886524be060021e3cfad0ba8458c850330cd
> Author: Felix Fietkau <nbd@openwrt.org>
> Date: Mon Nov 30 19:32:01 2015 +0100
>
> ath10k: do not use coherent memory for allocated device memory chunks
>
> Coherent memory is more expensive to allocate (and constrained on some
> architectures where it has to be pre-allocated). It is also completely
> unnecessary, since the host has no reason to even access these allocated
> memory spaces
>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>
> -Rajkumar
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>
--
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
2016-06-02 17:27 ` Ben Greear
@ 2016-06-02 17:46 ` Rajkumar Manoharan
2016-06-02 17:52 ` Ben Greear
0 siblings, 1 reply; 8+ messages in thread
From: Rajkumar Manoharan @ 2016-06-02 17:46 UTC (permalink / raw)
To: Ben Greear; +Cc: nbd, ath10k, Manoharan, Rajkumar, Valo, Kalle
On 2016-06-02 22:57, Ben Greear wrote:
> On 06/02/2016 10:20 AM, Manoharan, Rajkumar wrote:
>> Found a regression in ath.git TOT that system hangs while probing
>> qca99x0 device on x86_64 platform.
>> It seems the system hangs while DMA mapping of bigger memory chunks.
>> Below are the list of memory
>> chucks requested by target for qca99x0 during service ready event.
>> This issue is seen only on x86 platform.
>> No issues are observed on ARM platform (AP148). After reverting below
>> commit able to bring up device on x86.
>>
>> Jun 2 17:24:37 rmanohar-arch kernel: idx 0 pool_size 689816 num_units
>> 529 unit_len 1304
>> Jun 2 17:24:37 rmanohar-arch kernel: idx 1 pool_size 17152 num_units
>> 67 unit_len 256
>> Jun 2 17:24:37 rmanohar-arch kernel: idx 2 pool_size 68608 num_units
>> 67 unit_len 1024
>> Jun 2 17:24:37 rmanohar-arch kernel: idx 3 pool_size 274432 num_units
>> 67 unit_len 4096
>> Jun 2 17:24:37 rmanohar-arch kernel: idx 4 pool_size 107520 num_units
>> 35 unit_len 3072
>> Jun 2 17:24:37 rmanohar-arch kernel: idx 5 pool_size 6144 num_units 1
>> unit_len 6144
>> Jun 2 17:24:37 rmanohar-arch kernel: idx 6 pool_size 865444 num_units
>> 529 unit_len 1636
>
> We have seen similar. But, if we enable VT-d in our BIOS, then it
> works, at least in
> our scenarios. I have not tried putting more than one 99x0 NIC in a
> system to date, so possibly
> more than one would cause more issues, and I guess systems without VT-d
> might
> fail too...
>
Yeah.. But the code should work even on non-VT-d systems. ins't it?
>
>
>>
>> commit b057886524be060021e3cfad0ba8458c850330cd
>> Author: Felix Fietkau <nbd@openwrt.org>
>> Date: Mon Nov 30 19:32:01 2015 +0100
>>
>> ath10k: do not use coherent memory for allocated device memory
>> chunks
>>
>> Coherent memory is more expensive to allocate (and constrained on
>> some
>> architectures where it has to be pre-allocated). It is also
>> completely
>> unnecessary, since the host has no reason to even access these
>> allocated
>> memory spaces
>>
>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>>
>>
Ben,
Can you help to confirm this issue by disabling VT-d and bring up
qca99x0? If it freezes, try reverting the patch.
-Rajkumar
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
2016-06-02 17:46 ` Rajkumar Manoharan
@ 2016-06-02 17:52 ` Ben Greear
2016-06-14 6:21 ` Rajkumar Manoharan
0 siblings, 1 reply; 8+ messages in thread
From: Ben Greear @ 2016-06-02 17:52 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: nbd, ath10k, Manoharan, Rajkumar, Valo, Kalle
On 06/02/2016 10:46 AM, Rajkumar Manoharan wrote:
> On 2016-06-02 22:57, Ben Greear wrote:
>> On 06/02/2016 10:20 AM, Manoharan, Rajkumar wrote:
>>> Found a regression in ath.git TOT that system hangs while probing qca99x0 device on x86_64 platform.
>>> It seems the system hangs while DMA mapping of bigger memory chunks. Below are the list of memory
>>> chucks requested by target for qca99x0 during service ready event. This issue is seen only on x86 platform.
>>> No issues are observed on ARM platform (AP148). After reverting below commit able to bring up device on x86.
>>>
>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 0 pool_size 689816 num_units 529 unit_len 1304
>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 1 pool_size 17152 num_units 67 unit_len 256
>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 2 pool_size 68608 num_units 67 unit_len 1024
>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 3 pool_size 274432 num_units 67 unit_len 4096
>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 4 pool_size 107520 num_units 35 unit_len 3072
>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 5 pool_size 6144 num_units 1 unit_len 6144
>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 6 pool_size 865444 num_units 529 unit_len 1636
>>
>> We have seen similar. But, if we enable VT-d in our BIOS, then it
>> works, at least in
>> our scenarios. I have not tried putting more than one 99x0 NIC in a
>> system to date, so possibly
>> more than one would cause more issues, and I guess systems without VT-d might
>> fail too...
>>
> Yeah.. But the code should work even on non-VT-d systems. ins't it?
It would be great if it did.
>>> commit b057886524be060021e3cfad0ba8458c850330cd
>>> Author: Felix Fietkau <nbd@openwrt.org>
>>> Date: Mon Nov 30 19:32:01 2015 +0100
>>>
>>> ath10k: do not use coherent memory for allocated device memory chunks
>>>
>>> Coherent memory is more expensive to allocate (and constrained on some
>>> architectures where it has to be pre-allocated). It is also completely
>>> unnecessary, since the host has no reason to even access these allocated
>>> memory spaces
>>>
>>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>>> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>>>
>>>
> Ben,
>
> Can you help to confirm this issue by disabling VT-d and bring up qca99x0? If it freezes, try reverting the patch.
At the time, I bisected to this commit as well, but I decided to just live with it
since it seemed it fixed some other bug and we had a work-around. My understanding
is that without the patch above, some ARM systems failed to work.
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
2016-06-02 17:20 Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath Manoharan, Rajkumar
2016-06-02 17:27 ` Ben Greear
@ 2016-06-03 16:02 ` Valo, Kalle
1 sibling, 0 replies; 8+ messages in thread
From: Valo, Kalle @ 2016-06-03 16:02 UTC (permalink / raw)
To: Manoharan, Rajkumar; +Cc: ath10k, Rajkumar Manoharan, nbd
(Fixing Felix' address to nbd@nbd.name)
"Manoharan, Rajkumar" <rmanohar@qti.qualcomm.com> writes:
> Found a regression in ath.git TOT that system hangs while probing qca99x0 device on x86_64 platform.
> It seems the system hangs while DMA mapping of bigger memory chunks. Below are the list of memory
> chucks requested by target for qca99x0 during service ready event. This issue is seen only on x86 platform.
> No issues are observed on ARM platform (AP148). After reverting below commit able to bring up device on x86.
>
> Jun 2 17:24:37 rmanohar-arch kernel: idx 0 pool_size 689816 num_units 529 unit_len 1304
> Jun 2 17:24:37 rmanohar-arch kernel: idx 1 pool_size 17152 num_units 67 unit_len 256
> Jun 2 17:24:37 rmanohar-arch kernel: idx 2 pool_size 68608 num_units 67 unit_len 1024
> Jun 2 17:24:37 rmanohar-arch kernel: idx 3 pool_size 274432 num_units 67 unit_len 4096
> Jun 2 17:24:37 rmanohar-arch kernel: idx 4 pool_size 107520 num_units 35 unit_len 3072
> Jun 2 17:24:37 rmanohar-arch kernel: idx 5 pool_size 6144 num_units 1 unit_len 6144
> Jun 2 17:24:37 rmanohar-arch kernel: idx 6 pool_size 865444 num_units 529 unit_len 1636
Did you enable kernel debugging features, like deplock, memory
poisoning, DMA-API debug etc? They might give more hints why it's
failing. We should get bottom of this.
Felix, in case you missed because of the old email address the commit
is:
commit b057886524be060021e3cfad0ba8458c850330cd
Author: Felix Fietkau <nbd@openwrt.org>
Date: Mon Nov 30 19:32:01 2015 +0100
ath10k: do not use coherent memory for allocated device memory chunks
Coherent memory is more expensive to allocate (and constrained on some
architectures where it has to be pre-allocated). It is also completely
unnecessary, since the host has no reason to even access these allocated
memory spaces
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
2016-06-02 17:52 ` Ben Greear
@ 2016-06-14 6:21 ` Rajkumar Manoharan
2016-06-14 13:44 ` Ben Greear
0 siblings, 1 reply; 8+ messages in thread
From: Rajkumar Manoharan @ 2016-06-14 6:21 UTC (permalink / raw)
To: Ben Greear; +Cc: nbd, ath10k, Manoharan, Rajkumar, Valo, Kalle, nbd
On 2016-06-02 23:22, Ben Greear wrote:
> On 06/02/2016 10:46 AM, Rajkumar Manoharan wrote:
>> On 2016-06-02 22:57, Ben Greear wrote:
>>> On 06/02/2016 10:20 AM, Manoharan, Rajkumar wrote:
>>>> Found a regression in ath.git TOT that system hangs while probing
>>>> qca99x0 device on x86_64 platform.
>>>> It seems the system hangs while DMA mapping of bigger memory chunks.
>>>> Below are the list of memory
>>>> chucks requested by target for qca99x0 during service ready event.
>>>> This issue is seen only on x86 platform.
>>>> No issues are observed on ARM platform (AP148). After reverting
>>>> below commit able to bring up device on x86.
>>>>
>>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 0 pool_size 689816
>>>> num_units 529 unit_len 1304
>>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 1 pool_size 17152
>>>> num_units 67 unit_len 256
>>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 2 pool_size 68608
>>>> num_units 67 unit_len 1024
>>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 3 pool_size 274432
>>>> num_units 67 unit_len 4096
>>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 4 pool_size 107520
>>>> num_units 35 unit_len 3072
>>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 5 pool_size 6144 num_units
>>>> 1 unit_len 6144
>>>> Jun 2 17:24:37 rmanohar-arch kernel: idx 6 pool_size 865444
>>>> num_units 529 unit_len 1636
>>>
>>> We have seen similar. But, if we enable VT-d in our BIOS, then it
>>> works, at least in
>>> our scenarios. I have not tried putting more than one 99x0 NIC in a
>>> system to date, so possibly
>>> more than one would cause more issues, and I guess systems without
>>> VT-d might
>>> fail too...
>>>
>> Yeah.. But the code should work even on non-VT-d systems. ins't it?
>
> It would be great if it did.
>
>>>> commit b057886524be060021e3cfad0ba8458c850330cd
>>>> Author: Felix Fietkau <nbd@openwrt.org>
>>>> Date: Mon Nov 30 19:32:01 2015 +0100
>>>>
>>>> ath10k: do not use coherent memory for allocated device memory
>>>> chunks
>>>>
>>>> Coherent memory is more expensive to allocate (and constrained
>>>> on some
>>>> architectures where it has to be pre-allocated). It is also
>>>> completely
>>>> unnecessary, since the host has no reason to even access these
>>>> allocated
>>>> memory spaces
>>>>
>>>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>>>> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>>>>
>>>>
>> Ben,
>>
>> Can you help to confirm this issue by disabling VT-d and bring up
>> qca99x0? If it freezes, try reverting the patch.
>
> At the time, I bisected to this commit as well, but I decided to just
> live with it
> since it seemed it fixed some other bug and we had a work-around. My
> understanding
> is that without the patch above, some ARM systems failed to work.
>
Ben,
I posted a fix for the freeze issue
(https://patchwork.kernel.org/patch/9175029/). Can you please give a try
with VT-d disabled?
-Rajkumar
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
2016-06-14 6:21 ` Rajkumar Manoharan
@ 2016-06-14 13:44 ` Ben Greear
2016-06-15 2:55 ` Rajkumar Manoharan
0 siblings, 1 reply; 8+ messages in thread
From: Ben Greear @ 2016-06-14 13:44 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: nbd, ath10k, Manoharan, Rajkumar, Valo, Kalle, nbd
On 06/13/2016 11:21 PM, Rajkumar Manoharan wrote:
> On 2016-06-02 23:22, Ben Greear wrote:
>> At the time, I bisected to this commit as well, but I decided to just
>> live with it
>> since it seemed it fixed some other bug and we had a work-around. My
>> understanding
>> is that without the patch above, some ARM systems failed to work.
>>
> Ben,
>
> I posted a fix for the freeze issue (https://patchwork.kernel.org/patch/9175029/). Can you please give a try with VT-d disabled?
>
> -Rajkumar
Yes, but it might be a bit. I just ported my patches to 4.7, and will add yours
there. We are mainly focussed on getting a stable 4.4+ out the door currently though.
Were you able to test on the ARM platform that originally had the problem that
Felix's patch was supposed to fix?
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath
2016-06-14 13:44 ` Ben Greear
@ 2016-06-15 2:55 ` Rajkumar Manoharan
0 siblings, 0 replies; 8+ messages in thread
From: Rajkumar Manoharan @ 2016-06-15 2:55 UTC (permalink / raw)
To: Ben Greear; +Cc: nbd, ath10k, Manoharan, Rajkumar, Valo, Kalle, nbd
On 2016-06-14 19:14, Ben Greear wrote:
> On 06/13/2016 11:21 PM, Rajkumar Manoharan wrote:
>> On 2016-06-02 23:22, Ben Greear wrote:
>
>>> At the time, I bisected to this commit as well, but I decided to just
>>> live with it
>>> since it seemed it fixed some other bug and we had a work-around. My
>>> understanding
>>> is that without the patch above, some ARM systems failed to work.
>>>
>> Ben,
>>
>> I posted a fix for the freeze issue
>> (https://patchwork.kernel.org/patch/9175029/). Can you please give a
>> try with VT-d disabled?
>>
>> -Rajkumar
>
> Yes, but it might be a bit. I just ported my patches to 4.7, and will
> add yours
> there. We are mainly focussed on getting a stable 4.4+ out the door
> currently though.
>
Thanks..
> Were you able to test on the ARM platform that originally had the
> problem that
> Felix's patch was supposed to fix?
>
I tested this patch on ARM platform. Unfortunately I did not observe
original dma_alloc_coherent failures. Felix replaced dma_alloc_coherent
by kmalloc + dma_map_single. I retained the logic as it is. Thee change
is that host memory chuck size for target is limited by 256 KiB.
-Rajkumar
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-06-15 2:55 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-02 17:20 Regression in qca99x0 on x86 platform (kernel: 4.7.0-rc1-wt-ath Manoharan, Rajkumar
2016-06-02 17:27 ` Ben Greear
2016-06-02 17:46 ` Rajkumar Manoharan
2016-06-02 17:52 ` Ben Greear
2016-06-14 6:21 ` Rajkumar Manoharan
2016-06-14 13:44 ` Ben Greear
2016-06-15 2:55 ` Rajkumar Manoharan
2016-06-03 16:02 ` Valo, Kalle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.