AP association timeout bugzilla PR?

AP association timeout bugzilla PR?

[Jack Howarth]

   Is there an existing bugzilla PR for the problems
with AP association timeouts due to the changes in
the kernel tip (and 2.6.26 gits)? I would like to test
the fix for this against the current 2.6.26-git with
the ath9k git patch but am uncertain where to expect
the proposed patches to show up at (linux-wireless,
linux-kernel or in a bugzilla attachment)? Thanks in
advance for any information.
             Jack
 

Re: AP association timeout bugzilla PR?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 530 bytes --]

On Mon, 2008-07-28 at 13:27 -0400, Jack Howarth wrote:
> Is there an existing bugzilla PR for the problems
> with AP association timeouts due to the changes in
> the kernel tip (and 2.6.26 gits)? I would like to test
> the fix for this against the current 2.6.26-git with
> the ath9k git patch but am uncertain where to expect
> the proposed patches to show up at (linux-wireless,
> linux-kernel or in a bugzilla attachment)? 

Here. But I don't have any fixes yet. Maybe tonight, if I don't fall
asleep...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: AP association timeout bugzilla PR?

[Jack Howarth]

Johannes,
    Could you extend your partial fix for skb-cb use
to include patches for the new ath9k driver? I can use
the ath5k changes for a template for what to do for
the lines in drivers/net/wireless/ath9k/xmit.c with
IEEE80211_TX_CTL_DO_NOT_ENCRYPT but I don't how to change
the line with IEEE80211_TX_CTL_EAPOL_FRAME in that file.
Thanks in advance.
                       Jack

Re: AP association timeout bugzilla PR?

[Jack Howarth]

Johannes,
   I do see one oddity with the current ath9k git, 2.6.26-rc1
(which appears to have all of the changes in the mywireless-testing
git, your skb->cb fix and my attempt at the same patch for ath9k.
The ath9k driver seems to work okay but I see the following in
the messages log...

Jul 30 08:19:39 localhost kernel:
Jul 30 08:19:39 localhost kernel: =============================================
Jul 30 08:19:39 localhost kernel: [ INFO: possible recursive locking detected ]
Jul 30 08:19:39 localhost kernel: 2.6.27-0.186.rc1.fc9.x86_64 #1
Jul 30 08:19:39 localhost kernel: ---------------------------------------------
Jul 30 08:19:39 localhost kernel: ath9k/1379 is trying to acquire lock:
Jul 30 08:19:39 localhost kernel: (_xmit_IEEE80211#2){-...}, at: [<ffffffffa00f5
c46>] ieee80211_scan_completed+0x142/0x2e2 [mac80211]
Jul 30 08:19:39 localhost kernel:
Jul 30 08:19:39 localhost kernel: but task is already holding lock:
Jul 30 08:19:39 localhost kernel: (_xmit_IEEE80211#2){-...}, at: [<ffffffffa00f5
c46>] ieee80211_scan_completed+0x142/0x2e2 [mac80211]
Jul 30 08:19:39 localhost kernel:
Jul 30 08:19:39 localhost kernel: other info that might help us debug this:
Jul 30 08:19:39 localhost kernel: 3 locks held by ath9k/1379:
Jul 30 08:19:39 localhost kernel: #0:  ((name)){--..}, at: [<ffffffff81053f56>]
run_workqueue+0xb6/0x207
Jul 30 08:19:39 localhost kernel: #1:  (&(&local->scan_work)->work){--..}, at: [
<ffffffff81053f56>] run_workqueue+0xb6/0x207
Jul 30 08:19:39 localhost kernel: #2:  (_xmit_IEEE80211#2){-...}, at: [<ffffffff
a00f5c46>] ieee80211_scan_completed+0x142/0x2e2 [mac80211]
Jul 30 08:19:39 localhost kernel:
Jul 30 08:19:39 localhost kernel: stack backtrace:
Jul 30 08:19:39 localhost kernel: Pid: 1379, comm: ath9k Not tainted 2.6.27-0.18
6.rc1.fc9.x86_64 #1
Jul 30 08:19:39 localhost kernel:
Jul 30 08:19:39 localhost kernel: Call Trace:
Jul 30 08:19:39 localhost kernel: [<ffffffff8106625e>] __lock_acquire+0x790/0xaa
7
Jul 30 08:19:39 localhost kernel: [<ffffffffa00f5c46>] ? ieee80211_scan_complete
d+0x142/0x2e2 [mac80211]
Jul 30 08:19:39 localhost kernel: [<ffffffff8106660b>] lock_acquire+0x96/0xc3
Jul 30 08:19:39 localhost kernel: [<ffffffffa00f5c46>] ? ieee80211_scan_complete
d+0x142/0x2e2 [mac80211]
Jul 30 08:19:39 localhost kernel: [<ffffffff81309838>] _spin_lock+0x2b/0x58
Jul 30 08:19:39 localhost kernel: [<ffffffffa00f5c46>] ieee80211_scan_completed+
0x142/0x2e2 [mac80211]
Jul 30 08:19:39 localhost kernel: [<ffffffff81053f56>] ? run_workqueue+0xb6/0x20
7
Jul 30 08:19:39 localhost kernel: [<ffffffffa00f6097>] ieee80211_sta_scan_work+0
xb4/0x1ad [mac80211]
Jul 30 08:19:39 localhost kernel: [<ffffffff81053fa0>] run_workqueue+0x100/0x207
Jul 30 08:19:39 localhost kernel: [<ffffffffa00f5fe3>] ? ieee80211_sta_scan_work
+0x0/0x1ad [mac80211]
Jul 30 08:19:39 localhost kernel: [<ffffffff810541a4>] worker_thread+0xfd/0x111
Jul 30 08:19:39 localhost kernel: [<ffffffff81057ee1>] ? autoremove_wake_functio
n+0x0/0x3d
Jul 30 08:19:39 localhost kernel: [<ffffffff810540a7>] ? worker_thread+0x0/0x111
Jul 30 08:19:39 localhost kernel: [<ffffffff81057b64>] kthread+0x4e/0x7b
Jul 30 08:19:39 localhost kernel: [<ffffffff81011849>] child_rip+0xa/0x11
Jul 30 08:19:39 localhost kernel: [<ffffffff81010b5e>] ? restore_args+0x0/0x30
Jul 30 08:19:39 localhost kernel: [<ffffffff81057b16>] ? kthread+0x0/0x7b
Jul 30 08:19:39 localhost kernel: [<ffffffff8101183f>] ? child_rip+0x0/0x11
Jul 30 08:19:39 localhost kernel:
Jul 30 08:19:39 localhost kernel: ADDRCONF(NETDEV_CHANGE): ath0: link becomes re
ady

Is this a known issue or perhaps due to may skb->cb patch for ath9k?
                                 Jack

On Wed, Jul 30, 2008 at 09:16:50AM +0200, Johannes Berg wrote:
> On Tue, 2008-07-29 at 20:10 -0400, Jack Howarth wrote:
> > Johannes,
> >     FYI, does this following patch look okay for ath9k?
> > 
> > --- drivers/net/wireless/ath9k/xmit.c.orig	2008-07-29 19:32:26.000000000 -0400
> > +++ drivers/net/wireless/ath9k/xmit.c	2008-07-29 20:04:09.000000000 -0400
> > @@ -37,6 +37,10 @@
> >  
> >  #define OFDM_SIFS_TIME    	    16
> >  
> > +#ifndef ETH_P_PAE
> > +#define ETH_P_PAE 0x888E /* Port Access Entity (IEEE 802.1X) */
> > +#endif /* ETH_P_PAE */
> > +
> >  static u_int32_t bits_per_symbol[][2] = {
> 
> I guess that should finally be moved to a more appropriate place as the
> todo-list on wireless.kernel.org mentions.
> 
> johannes

Re: AP association timeout bugzilla PR?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

On Wed, 2008-07-30 at 09:28 -0400, Jack Howarth wrote:

> Jul 30 08:19:39 localhost kernel: =============================================
> Jul 30 08:19:39 localhost kernel: [ INFO: possible recursive locking detected ]
> Jul 30 08:19:39 localhost kernel: 2.6.27-0.186.rc1.fc9.x86_64 #1
> Jul 30 08:19:39 localhost kernel: ---------------------------------------------
> Jul 30 08:19:39 localhost kernel: ath9k/1379 is trying to acquire lock:
> Jul 30 08:19:39 localhost kernel: (_xmit_IEEE80211#2){-...}, at: [<ffffffffa00f5
> c46>] ieee80211_scan_completed+0x142/0x2e2 [mac80211]
> Jul 30 08:19:39 localhost kernel:
> Jul 30 08:19:39 localhost kernel: but task is already holding lock:
> Jul 30 08:19:39 localhost kernel: (_xmit_IEEE80211#2){-...}, at: [<ffffffffa00f5
> c46>] ieee80211_scan_completed+0x142/0x2e2 [mac80211]

I think that's the false positive due to the tx mq changes that people
were talking about all the time. Please ignore.

> Is this a known issue or perhaps due to may skb->cb patch for ath9k?

Yeah it's a known issue, nothing with your patch, except for the PAE
placement your patch is fine. And I don't understand that part of ath9k,
it shouldn't need to look at that but rather ask the RC algorithm to do
that job.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: AP association timeout bugzilla PR?

[Jack Howarth]

Johannes,
   One other question. Does the mac80211 based drivers like
ath5k and ath9k support any form of proc output? I am assuming
that the NetworkManager wireless menu item reports zero signal
due to the absence of a /proc/net/wireless under ath9k. Is that
a TODO as well or should file a bug report against the Fedora
NetworkManager concerning that. I am assuming it uses the proc
to get the signal level and that is why it reports zero. If
I use iwconfig there appears to be a signal level reported for
ath9k.
               Jack

On Wed, Jul 30, 2008 at 03:52:14PM +0200, Johannes Berg wrote:
> 
> I think that's the false positive due to the tx mq changes that people
> were talking about all the time. Please ignore.
> 
> > Is this a known issue or perhaps due to may skb->cb patch for ath9k?
> 
> Yeah it's a known issue, nothing with your patch, except for the PAE
> placement your patch is fine. And I don't understand that part of ath9k,
> it shouldn't need to look at that but rather ask the RC algorithm to do
> that job.
> 
> johannes