All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: Ben Greear <greearb@candelatech.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	ath10k@lists.infradead.org
Subject: Re: ath10k hits warning in sta_info.c:839.
Date: Mon, 28 Oct 2013 11:23:31 +0200	[thread overview]
Message-ID: <871u35eoks.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <CA+BoTQmomxywSjUB9nrniMT+HeZeBD=L3m2K8c=m6ehGcSp7eQ@mail.gmail.com> (Michal Kazior's message of "Wed, 23 Oct 2013 09:42:16 +0200")

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

> On 23 October 2013 00:22, Ben Greear <greearb@candelatech.com> wrote:
>> On 10/22/2013 11:25 AM, Ben Greear wrote:
>>> Kernel is stock 'ath' tree, with small printk to debug an ath10k
>>> crash.
>>>
>>> This is FYI for now...will be looking at other ath10k crash bugs
>>> before digging into this tone.
>>>
>>> Setup is 2 stations trying to associate to same AP, which causes
>>> endless failures and firmware crashes.  Good for chasing bugs :)
>>>
>>>
>>> DMAR:[fault reason 05] PTE Write access is not set
>>> dmar: DRHD: handling fault status reg 3
>>> dmar: DMAR:[DMA Write] Request device [05:00.0] fault addr ffd52000
>>> DMAR:[fault reason 05] PTE Write access is not set
>>> dmar: DRHD: handling fault status reg 3
>>> dmar: DMAR:[DMA Write] Request device [05:00.0] fault addr ffd52000
>>> DMAR:[fault reason 05] PTE Write access is not set
>>>
>>> sta300: authentication with 00:03:83:3d:30:aa timed out
>>> [root@ct523-9292 ~]# ath10k: Failed to delete peer: 00:03:83:3d:30:aa for VDEV: 1
>>> ath10k: WMI vdev stop failed: ret -108
>>
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 1 PID: 6 at /mnt/sda/home/greearb/git/ath/net/mac80211/sta_info.c:839 __sta_info_destroy+0x12)
>>> Modules linked in: nf_nat_ipv4 nf_nat veth 8021q garp stp mrp llc macvlan pktgen lockd f71882fg coretemp hw]
>>
>> I think this may be a result of whatever bug or limitation
>> caused the firmware to error and/or crash when adding a second
>> station VIF and trying to associate it to the same AP.
>>
>> Probably not a problem with the rest of the wifi stacks.
>
> Yup. This originates from the firmware limitation. It's unable to
> handle two peer nodes with same mac addr on different vdevs. That's
> why it's impossible to associate 2 (or more) station interfaces to the
> same BSS.

I think we should add some sort of check to ath10k to detect that and
not crash firmware.

-- 
Kalle Valo

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

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: Ben Greear <greearb@candelatech.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	<ath10k@lists.infradead.org>
Subject: Re: ath10k hits warning in sta_info.c:839.
Date: Mon, 28 Oct 2013 11:23:31 +0200	[thread overview]
Message-ID: <871u35eoks.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <CA+BoTQmomxywSjUB9nrniMT+HeZeBD=L3m2K8c=m6ehGcSp7eQ@mail.gmail.com> (Michal Kazior's message of "Wed, 23 Oct 2013 09:42:16 +0200")

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

> On 23 October 2013 00:22, Ben Greear <greearb@candelatech.com> wrote:
>> On 10/22/2013 11:25 AM, Ben Greear wrote:
>>> Kernel is stock 'ath' tree, with small printk to debug an ath10k
>>> crash.
>>>
>>> This is FYI for now...will be looking at other ath10k crash bugs
>>> before digging into this tone.
>>>
>>> Setup is 2 stations trying to associate to same AP, which causes
>>> endless failures and firmware crashes.  Good for chasing bugs :)
>>>
>>>
>>> DMAR:[fault reason 05] PTE Write access is not set
>>> dmar: DRHD: handling fault status reg 3
>>> dmar: DMAR:[DMA Write] Request device [05:00.0] fault addr ffd52000
>>> DMAR:[fault reason 05] PTE Write access is not set
>>> dmar: DRHD: handling fault status reg 3
>>> dmar: DMAR:[DMA Write] Request device [05:00.0] fault addr ffd52000
>>> DMAR:[fault reason 05] PTE Write access is not set
>>>
>>> sta300: authentication with 00:03:83:3d:30:aa timed out
>>> [root@ct523-9292 ~]# ath10k: Failed to delete peer: 00:03:83:3d:30:aa for VDEV: 1
>>> ath10k: WMI vdev stop failed: ret -108
>>
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 1 PID: 6 at /mnt/sda/home/greearb/git/ath/net/mac80211/sta_info.c:839 __sta_info_destroy+0x12)
>>> Modules linked in: nf_nat_ipv4 nf_nat veth 8021q garp stp mrp llc macvlan pktgen lockd f71882fg coretemp hw]
>>
>> I think this may be a result of whatever bug or limitation
>> caused the firmware to error and/or crash when adding a second
>> station VIF and trying to associate it to the same AP.
>>
>> Probably not a problem with the rest of the wifi stacks.
>
> Yup. This originates from the firmware limitation. It's unable to
> handle two peer nodes with same mac addr on different vdevs. That's
> why it's impossible to associate 2 (or more) station interfaces to the
> same BSS.

I think we should add some sort of check to ath10k to detect that and
not crash firmware.

-- 
Kalle Valo

  parent reply	other threads:[~2013-10-28  9:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-22 18:25 ath10k hits warning in sta_info.c:839 Ben Greear
2013-10-22 18:25 ` Ben Greear
2013-10-22 22:22 ` Ben Greear
2013-10-22 22:22   ` Ben Greear
2013-10-23  7:42   ` Michal Kazior
2013-10-23  7:42     ` Michal Kazior
2013-10-23 23:28     ` Ben Greear
2013-10-28  9:23     ` Kalle Valo [this message]
2013-10-28  9:23       ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871u35eoks.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@qca.qualcomm.com \
    --cc=ath10k@lists.infradead.org \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=michal.kazior@tieto.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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.