Michal Kazior writes:
> The power up procedure was overly complex due to
> warm/cold reset workarounds and issues.
>
> Signed-off-by: Michal Kazior
[...]
> + ret = ath10k_pci_wait_for_target_init(ar);
> + if (ret) {
> + ath10k_warn(ar, "failed to wait for target after cold
On 13 October 2014 09:35, voncken wrote:
> Thanks for your reply,
>
>>
>> Can you then provide a crash register dump for 10.1, please? I can't help you
>> much with the 636 dump.
>>
> Yes I can, but where I find it?
https://github.com/kvalo/ath10k-firmware/blob/master/10.1/firmware-2.bin_
Thanks for your reply,
>
> Can you then provide a crash register dump for 10.1, please? I can't help you
> much with the 636 dump.
>
Yes I can, but where I find it?
> Are you perhaps trying to run STA with 4addr bridging? If so then make sure
> you use recent ath10k as this was known to
Michal Kazior writes:
> The power up/down didn't make much sense any more
> since hif_stop already stops the device
> compeletely. The target lifecycle was never symmetric
> so don't bother trying to make it look like it is
> and expose a reset hif callback instead of power
> up/down callbacks.
>
Michal Kazior writes:
> Until now it was possible to simulate soft and
> hard fw crashes but it wasn't possible to trigger
> an immediately hw restart itself (without the fw
> crash).
>
> This can be useful when stress testing hw
> restarting stability, e.g. during heavy tx/rx
> traffic.
>
> Sign
Michal Kazior writes:
> In some cases hw recovery was taking an absurdly
> long time due to ath10k waiting for things that
> would never really complete.
>
> Instead of waiting for inevitable timeouts poke
> all completions and wakequeues and check if it's
> still worth waiting.
>
> Signed-off-by
On 13 October 2014 10:01, Kalle Valo wrote:
> Michal Kazior writes:
>
>> The power up/down didn't make much sense any more
>> since hif_stop already stops the device
>> compeletely. The target lifecycle was never symmetric
>> so don't bother trying to make it look like it is
>> and expose a reset
On 13 October 2014 10:15, Kalle Valo wrote:
> Michal Kazior writes:
>
>> In some cases hw recovery was taking an absurdly
>> long time due to ath10k waiting for things that
>> would never really complete.
>>
>> Instead of waiting for inevitable timeouts poke
>> all completions and wakequeues and
Michal Kazior writes:
> On 13 October 2014 10:15, Kalle Valo wrote:
>> Michal Kazior writes:
>>
>>> In some cases hw recovery was taking an absurdly
>>> long time due to ath10k waiting for things that
>>> would never really complete.
>>>
>>> Instead of waiting for inevitable timeouts poke
>>> a
On 13 October 2014 10:07, Kalle Valo wrote:
> Michal Kazior writes:
[...]
>> --- a/drivers/net/wireless/ath/ath10k/debug.c
>> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>> @@ -694,7 +694,8 @@ static ssize_t ath10k_read_simulate_fw_crash(struct file
>> *file,
>> "To simulate firm
From: Rickard Strandqvist
> Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
> And changed from using strncpy to strlcpy to simplify code.
I think you should return an error if the strings get truncated.
Silent truncation is going to lead to issues at some point in the fu
> -Message d'origine-
> De : Michal Kazior [mailto:michal.kaz...@tieto.com]
> Envoyé : lundi 13 octobre 2014 09:54
> À : voncken
> Cc : ath...@lists.infradead.org; linux-wireless
> Objet : Re: ath10k firmware crash
>
> On 13 October 2014 09:35, voncken wrote:
> > Thanks for your
On 13 October 2014 11:20, voncken wrote:
>
>
>> -Message d'origine-
>> De : Michal Kazior [mailto:michal.kaz...@tieto.com]
>> Envoyé : lundi 13 octobre 2014 09:54
>> À : voncken
>> Cc : ath...@lists.infradead.org; linux-wireless
>> Objet : Re: ath10k firmware crash
>>
>> On 13 October 2014
On 13 October 2014 11:23, voncken wrote:
>
>
>>
>> Are you perhaps trying to run STA with 4addr bridging? If so then make sure
>> you use recent ath10k as this was known to be a problem.
>>
> We tested without the 4addr bridging, that works fine but we can't add the
> interface in bridge :-(
>
>
>
> Are you perhaps trying to run STA with 4addr bridging? If so then make sure
> you use recent ath10k as this was known to be a problem.
>
We tested without the 4addr bridging, that works fine but we can't add the
interface in bridge :-(
Have you a benchmark reference with ATH10K ? at this
From: Karl Beldan
It affects non-(V)HT rates and can lead to selecting an rts_cts rate
that is not a basic rate or way superior to the reference rate (ATM
rates[0] used for the 1st attempt of the protected frame data).
E.g, assuming drivers register growing (bitrate) sorted tables of
ieee80211_r
Properly cc'ing stable (I used kernel.org instead of vger.kernel.org).
On Mon, Oct 13, 2014 at 11:48:12AM +0200, Karl Beldan wrote:
> From: Karl Beldan
>
> It affects non-(V)HT rates and can lead to selecting an rts_cts rate
> that is not a basic rate or way superior to the reference rate (ATM
>
> > I'm using the compat wireless from Openwrt.
> > Compat wireless version 2014-05-22, but we updated the
> > firmware with the latest version provided by openwrt (commit number
> > 38eeda3ae6f90fde5546bdd48ee4ff3090f238c0 from
> > kernel.org/pub/scm/linux/kernel/git/firmare/linux-firmware
> >
> > Have you a benchmark reference with ATH10K ? at this time we can send
> around 700 Mbit/s, is it the maximum or we can expected better ?
>
> If this is OTA then this is pretty good. If this is cabled RF w/ attentuator
> it should be possible to get ~900mbps of UDP traffic with multiple str
From: Karl Beldan
It affects non-(V)HT rates and can lead to selecting an rts_cts rate
that is not a basic rate or way superior to the reference rate (ATM
rates[0] used for the 1st attempt of the protected frame data).
E.g, assuming drivers register growing (bitrate) sorted tables of
ieee80211_r
Hi Marek,
>>
>> That's good :) Actually kernel will take care of freeing skb when
>driver submits received packet using netif_rx(). Could you please share
>your hack?
>Yes it should be freed when netif_rx() is processed but I have feeling
>that sometimes (my case) during high load (-b 100m) packet
> >>
> >> >> Are you perhaps trying to run STA with 4addr bridging? If so then
> >> >> make sure you use recent ath10k as this was known to be a problem.
> >> >>
> >> > Yes I'm testing with 4 addr bridging because I need to bridge this
> >> interface. I' ll try without this option.
> >> > I'm testi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey,
Since r8723au is out I have tried it with every kernel version.
But every time the connection is flaky, it works fine in the beginning
but after ~2 - 5 minutes it stops routing packages get slow, but
it shows all the time connected (on my wlan w
2014-10-13 10:55 GMT+02:00 David Laight :
> From: Rickard Strandqvist
>> Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
>> And changed from using strncpy to strlcpy to simplify code.
>
> I think you should return an error if the strings get truncated.
> Silent truncation
(Sending this to the right people this time, hopefully.)
I have been getting a consistent boot failure with 3.17, which I have
bisected to
38506ecefab911785d5e1aa5889f6eeb462e0954 is the first bad commit
commit 38506ecefab911785d5e1aa5889f6eeb462e0954
Author: Larry Finger
Date: Mon Sep 22 09:3
Realtek RTL8188SU/RTL8191SU/RTL8192SU driver
https://github.com/chunkeey/rtl8192su
&
RTL8188SU
~~~
- lsusb
Bus 002 Device 003: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU 802.11n
WLAN Adapter
~~
- lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
On 10/13/2014 06:45 PM, S. Gilles wrote:
(Sending this to the right people this time, hopefully.)
I have been getting a consistent boot failure with 3.17, which I have
bisected to
38506ecefab911785d5e1aa5889f6eeb462e0954 is the first bad commit
commit 38506ecefab911785d5e1aa5889f6eeb462e0954
Au
From: Sujith Manoharan
MCC fixes for -next.
Sujith Manoharan (9):
ath9k: Add a function to check for an active GO
ath9k: Check for active GO in mgd_prepare_tx()
ath9k: Use a helper function for offchannel NoA
ath9k: Use a helper function to set NoA
ath9k: Use a helper function for bmis
From: Sujith Manoharan
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/channel.c | 61 +++-
1 file changed, 36 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
b/drivers/net/wireless/ath/ath9k/channel.c
index c
From: Sujith Manoharan
If a GO interface is active when we receive a
mgd_prepare_tx() call, then we need to send
out a new NoA before switching to a new context.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/ath9k.h | 2 ++
drivers/net/wireless/ath/ath9k/channel.c | 14
From: Sujith Manoharan
Instead of using ATH_CHANCTX_EVENT_ASSIGN to abort
a HW scan when a new interface becomes active, use the
mgd_prepare_tx() callback. This allows us to make
sure that the GO's channel becomes operational by
using flush_work().
Signed-off-by: Sujith Manoharan
---
drivers/n
From: Sujith Manoharan
mac80211 has to be notified when a RoC period
expires in the driver. In MCC mode, since the
offchannel/RoC timer is set with the requested
duration, ieee80211_remain_on_channel_expired() needs
to be called when the timer expires.
But, currently it is done after we move bac
From: Sujith Manoharan
The flush timeout in MCC mode is very small, since
we are constrained by the time slice for each
channel context, but since only the HW queues are
flushed when switching contexts, it is acceptable.
Since the SW queues are also emptied in the mac80211 flush()
callback, a la
From: Sujith Manoharan
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/channel.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
b/drivers/net/wireles
From: Sujith Manoharan
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/channel.c | 45 ++--
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
b/drivers/net/wireless/ath/ath9k/channel.c
index 7
From: Sujith Manoharan
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/channel.c | 45 +++-
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c
b/drivers/net/wireless/ath/ath9k/channel.c
index 4
From: Sujith Manoharan
This patch makes sure that a GO interface
sends out a new NoA schedule with 200ms duration
when mgd_prepare_tx() is called.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/channel.c | 41
On Mon, Oct 13, 2014 at 10:41:26PM -0500, Larry Finger wrote:
> On 10/13/2014 06:45 PM, S. Gilles wrote:
> > (Sending this to the right people this time, hopefully.)
> >
> > I have been getting a consistent boot failure with 3.17, which I have
> > bisected to
> >
> > 38506ecefab911785d5e1aa5889f6ee
Dear Amitkumar Karwar,
On Mon, Oct 13, 2014 at 3:41 PM, Amitkumar Karwar wrote:
> Hi Marek,
>
>>>
>>> That's good :) Actually kernel will take care of freeing skb when
>>driver submits received packet using netif_rx(). Could you please share
>>your hack?
>>Yes it should be freed when netif_rx() i
39 matches
Mail list logo
