"Rafael J. Wysocki" writes:
>> > AFAICT that's a simple 'use RCU without holding rcu_read_lock' warning.
>> > I've not dug through ath10k to see who should be doing rcu_read_lock,
>> > but the few places I did look at don't seem to have changed recently.
>>
>> Just this morning I applied a patch
On 2021-02-10 08:42, Shuah Khan wrote:
ath10k_mac_get_rate_flags_ht() floods dmesg with the following
messages,
when it fails to find a match for mcs=7 and rate=1440.
supported_ht_mcs_rate_nss2:
{7, {1300, 2700, 1444, 3000} }
ath10k_pci :02:00.0: invalid ht params rate 1440 100kbps nss 2
On 2021-02-10 10:14, Brian Norris wrote:
On Tue, Feb 9, 2021 at 6:12 PM Wen Gong wrote:
On 2021-02-10 03:35, Brian Norris wrote:
so this patch is to dump the top 1024 bytes only,
its 1st goal is make log smaller.
Agreed. I wasn't objecting to this patch. I just wanted to highlight
the second
On Tue, Feb 9, 2021 at 6:12 PM Wen Gong wrote:
> On 2021-02-10 03:35, Brian Norris wrote:
> so this patch is to dump the top 1024 bytes only,
> its 1st goal is make log smaller.
Agreed. I wasn't objecting to this patch. I just wanted to highlight
the second part should probably also be considered
On 2021-02-10 03:35, Brian Norris wrote:
+ Steven Rostedt
Hi Wen,
(Trimming down the description a bit:)
On Mon, Feb 8, 2021 at 6:59 PM Wen Gong wrote:
Kernel panic every time in kernel when running below case:
steps:
1. connect to an AP with good signal strength
2. echo 0x7f > /sys/kernel/
On 2021-02-10 05:34, Steven Rostedt wrote:
On Tue, 9 Feb 2021 14:55:31 -0500
Steven Rostedt wrote:
> [for-next][PATCH 2/2] tracing: Use temp buffer when filtering events
> https://lore.kernel.org/lkml/f16b14066317f6a926b6636df6974...@codeaurora.org/
Note, that is only used when filtering happ
Based on the comment block in this function and the FIXME for this, peer
being present for the offchannel tx is unlikely. Peer is deleted once tx
is complete. Change peer present msg to a warn to detect this condition.
Signed-off-by: Shuah Khan
---
drivers/net/wireless/ath/ath10k/mac.c | 5 ++---
ath10k_drain_tx() must not be called with conf_mutex held as workers can
use that also. Add check to detect conf_mutex held calls.
Signed-off-by: Shuah Khan
---
drivers/net/wireless/ath/ath10k/mac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/driv
ath10k_debug_fw_stats_request() is called ath10k_sta_statistics()
without holding conf_mutex. ath10k_debug_fw_stats_request() simply
returns when CONFIG_ATH10K_DEBUGFS is disabled.
When CONFIG_ATH10K_DEBUGFS is enabled, ath10k_debug_fw_stats_request()
code path isn't protected. This assert is trig
ieee80211_find_sta_by_ifaddr() must be called under the RCU lock and
the resulting pointer is only valid under RCU lock as well.
Fix ath10k_wmi_tlv_parse_peer_stats_info() to hold RCU lock before it
calls ieee80211_find_sta_by_ifaddr() and release it when the resulting
pointer is no longer needed.
I have been seeing lockdep asserts for a couple of months and finally
found time to debug and fix the problems. The dmesg looks clean with
these fixes.
Enabling LOCKDEP and ATH10K_DEBUGFS triggers the lockdep assert and
RCU warns.
The first two patches in this series are fixes to lockdep assert a
ath10k_mac_get_rate_flags_ht() floods dmesg with the following messages,
when it fails to find a match for mcs=7 and rate=1440.
supported_ht_mcs_rate_nss2:
{7, {1300, 2700, 1444, 3000} }
ath10k_pci :02:00.0: invalid ht params rate 1440 100kbps nss 2 mcs 7
dev_warn_ratelimited() isn't helpin
allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002
ig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a00
allyesconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210209
i386
allyesconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210209
i386
nfig
sparcallyesconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-202
On Tue, 9 Feb 2021 14:55:31 -0500
Steven Rostedt wrote:
> > [for-next][PATCH 2/2] tracing: Use temp buffer when filtering events
> > https://lore.kernel.org/lkml/f16b14066317f6a926b6636df6974...@codeaurora.org/
> >
>
> Note, that is only used when filtering happens, which doesn't appear to be
On Tue, 9 Feb 2021 11:35:07 -0800
Brian Norris wrote:
> + Steven Rostedt
Thanks.
>
> Hi Wen,
>
> (Trimming down the description a bit:)
>
> On Mon, Feb 8, 2021 at 6:59 PM Wen Gong wrote:
> >
> > Kernel panic every time in kernel when running below case:
> > steps:
> > 1. connect to an AP wi
+ Steven Rostedt
Hi Wen,
(Trimming down the description a bit:)
On Mon, Feb 8, 2021 at 6:59 PM Wen Gong wrote:
>
> Kernel panic every time in kernel when running below case:
> steps:
> 1. connect to an AP with good signal strength
> 2. echo 0x7f > /sys/kernel/debug/ieee80211/phy0/ath10k/pktlog_
On Tue, Feb 9, 2021 at 12:57 PM Kalle Valo wrote:
>
> + ath10k list
>
> Peter Zijlstra writes:
>
> > On Mon, Feb 08, 2021 at 08:04:27PM +0100, Rafael J. Wysocki wrote:
> >> Hi Peter & Paul,
> >>
> >> The traces below are present in the boot dmesg log on my Dell XPS13 9360.
> >>
> >> I haven't had
+ ath10k list
Peter Zijlstra writes:
> On Mon, Feb 08, 2021 at 08:04:27PM +0100, Rafael J. Wysocki wrote:
>> Hi Peter & Paul,
>>
>> The traces below are present in the boot dmesg log on my Dell XPS13 9360.
>>
>> I haven't had the time to look into this in detail yet, but here it goes in
>> cas
Bjorn Andersson writes:
> On Mon 08 Feb 11:21 CST 2021, Kalle Valo wrote:
>
>> Amit Pundir writes:
>>
>> > Hi Kalle,
>> >
>> > On Mon, 7 Dec 2020 at 22:25, Kalle Valo wrote:
>> >>
>> >> This is firmware version specific, right? There's also enum
>> >> ath10k_fw_features which is embedded withi
23 matches
Mail list logo
