Bug 33852

I don't see anything unusual in your /var/log/messages output.  Can you describe the problem more precisely?  What "doesn't work"?

(In reply to comment #1)
> I don't see anything unusual in your /var/log/messages output.  Can you
> describe the problem more precisely?  What "doesn't work"?

I think problem in Apr 23 15:39:27 laptop kernel: [   15.668598] ADDRCONF(NETDEV_UP): wlan0: link is not ready.

I can't connect to my router.

What info do you need?

iwconfig wlan0 essid router.popov.net key XXXXXXXXXXXXXXXXXXXXXXXXXX

iwconfig wlan0

wlan0     IEEE 802.11bg  ESSID:"router.popov.net"  
          Mode:Managed  Frequency:2.452 GHz  Access Point: Not-Associated   
          Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XX
          Power Management:off

iwconfig wlan0 essid router.popov.net key XXXXXXXXXXXXXXXXXXXXXXXXXX

iwconfig wlan0

wlan0     IEEE 802.11bg  ESSID:"router.popov.net"  
          Mode:Managed  Frequency:2.452 GHz  Access Point: Not-Associated   
          Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XX
          Power Management:off

kernel 2.6.37.6:

boris@laptop:~$ /sbin/iwconfig wlan0
wlan0     IEEE 802.11bg  ESSID:"router.popov.net"  
          Mode:Managed  Frequency:2.452 GHz  Access Point: 00:18:E7:F7:B3:9D   
          Bit Rate=54 Mb/s   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=68/70  Signal level=-42 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:53   Missed beacon:0

Still not much information...perhaps we could see the output of "lspci -n" and "iwlist wlan0 scan"?

Created attachment 55592 [details]
lspci and iwlist in kernel 2.6.38.4

Created attachment 55602 [details]
lspci and iwlist in kernel 2.6.37.6

(In reply to comment #6)
> Still not much information...perhaps we could see the output of "lspci -n"
> and
> "iwlist wlan0 scan"?

Ok John, please see attachment.
Can I help you any more (debuginfo etc...)?

So, it looks like you aren't receiving any scan information (and possibly nothing at all).

Could you do a git bisect between 2.6.37 and 2.6.38.4?

I will try.

> Could you do a git bisect between 2.6.37 and 2.6.38.4?

I am doing bisect.

In 42c025f3de9042d9c9abd9a6f6205d1a0f4bcadf:

iwlist wlan0 scan works well, but
in kern.log:

Apr 30 07:58:24 laptop kernel: [   67.073537] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Apr 30 07:58:25 laptop kernel: [   67.258316] wlan0: authenticate with 00:18:e7:f7:b3:9d (try 1)
Apr 30 07:58:25 laptop kernel: [   67.261474] wlan0: authenticated
Apr 30 07:58:25 laptop kernel: [   67.263641] wlan0: associate with 00:18:e7:f7:b3:9d (try 1)
Apr 30 07:58:25 laptop kernel: [   67.274361] wlan0: RX AssocResp from 00:18:e7:f7:b3:9d (capab=0x431 status=0 aid=1)
Apr 30 07:58:25 laptop kernel: [   67.274369] wlan0: associated
Apr 30 07:58:25 laptop kernel: [   67.275894] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Apr 30 07:58:25 laptop kernel: [   67.619988] ath5k phy0: gain calibration timeout (2452MHz)
Apr 30 07:58:27 laptop kernel: [   69.328244] cfg80211: Calling CRDA to update world regulatory domain
Apr 30 07:58:31 laptop kernel: [   73.637083] ath5k phy0: gain calibration timeout (2452MHz)
Apr 30 07:58:35 laptop kernel: [   77.768144] wlan0: no IPv6 routers present
Apr 30 07:59:10 laptop kernel: [  112.276479] ath5k phy0: gain calibration timeout (2452MHz)
Apr 30 07:59:10 laptop kernel: [  112.624093] ath5k phy0: gain calibration timeout (2452MHz)
Apr 30 07:59:10 laptop kernel: [  112.626185] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Apr 30 07:59:10 laptop kernel: [  113.102671] ath5k phy0: gain calibration timeout (2452MHz)
Apr 30 07:59:11 laptop kernel: [  113.608067] ath5k phy0: gain calibration timeout (2452MHz)
Apr 30 08:00:31 laptop kernel: [  193.276325] ath5k phy0: gain calibration timeout (2452MHz)
Apr 30 08:00:31 laptop kernel: [  193.623698] ath5k phy0: gain calibration timeout (2452MHz)
Apr 30 08:00:31 laptop kernel: [  193.625725] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Apr 30 08:00:31 laptop kernel: [  194.102689] ath5k phy0: gain calibration timeout (2452MHz)
Apr 30 08:00:32 laptop kernel: [  194.617677] ath5k phy0: gain calibration timeout (2452MHz)
Apr 30 08:03:50 laptop kernel: [  392.757340] ath5k phy0: gain calibration timeout (2452MHz)
Apr 30 08:03:50 laptop kernel: [  393.104117] ath5k phy0: gain calibration timeout (2452MHz)
Apr 30 08:03:50 laptop kernel: [  393.106053] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Apr 30 08:03:51 laptop kernel: [  393.577207] ath5k phy0: gain calibration timeout (2452MHz)
Apr 30 08:03:51 laptop kernel: [  394.077608] ath5k phy0: gain calibration timeout (2452MHz)

Created attachment 55932 [details]
first bad commit

Created attachment 55942 [details]
log of bisecting

First-Bad-Commit : 42c025f3de9042d9c9abd9a6f6205d1a0f4bcadf

Umm... I'm sorry but that bisection gotta be incorrect.  The only thing the commit does is adding a comment.

 kernel/workqueue.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 930c239..11869fa 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -768,7 +768,11 @@ static inline void worker_clr_flags(struct worker *worker, unsigned int flags)
 
        worker->flags &= ~flags;
 
-       /* if transitioning out of NOT_RUNNING, increment nr_running */
+       /*
+        * If transitioning out of NOT_RUNNING, increment nr_running.  Note
+        * that the nested NOT_RUNNING is not a noop.  NOT_RUNNING is mask
+        * of multiple flags, not a single flag.
+        */
        if ((flags & WORKER_NOT_RUNNING) && (oflags & WORKER_NOT_RUNNING))
                if (!(worker->flags & WORKER_NOT_RUNNING))
                        atomic_inc(get_gcwq_nr_running(gcwq->cpu));

Boris, can you concentrate your good/bad decision only on the scanning not working? It's expected that other issues crop up and get fixed while bisecting through a range of commits... if they don't interfere with the scanning, ignore them, if you can't test the wifi scanning (maybe a commit does not compile) just skip that commit. 

[You can always check where you're at with the command 'git bisect visualize', which will you show all commits you have not yet eleminated]

I repeated bisect and have new first bad commit:

573cfde7aaeaadb0fd356ff2a14bdf9238967661 is the first bad commit
commit 573cfde7aaeaadb0fd356ff2a14bdf9238967661
Author: Nick Kossifidis <mickflemm@gmail.com>
Date:   Fri Feb 4 01:41:02 2011 +0200

    ath5k: Fix fast channel switching
    
    Fast channel change fixes:
    
    a) Always set OFDM timings
    b) Don't re-activate PHY
    c) Enable only NF calibration, not AGC
    
    https://bugzilla.kernel.org/show_bug.cgi?id=27382
    
    Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

:040000 040000 47e60fb64921ea8eb2a91f5baa60b8fcd699a39e c9676b82bdca218cce2988c4952f2fcaac935d36 M      drivers

Created attachment 56922 [details]
first bad commit (new)

Created attachment 56932 [details]
log of bisecting (new)

Did you try reverting that commit?  Does that resolve the issue?

Perhaps just turning off fast channel switching would help, it's good but nonessential and a few people have reported problems with it.

(In reply to comment #21)
> Did you try reverting that commit?  Does that resolve the issue?

Reverting that commit resolve _only_ iwlist scan.
Access point is "Not-Associated" like comment #3 (https://bugzilla.kernel.org/show_bug.cgi?id=33852#c3).

Can I help you any more?

O.K. let's turn fast channel switching to a module parameter, the question is should we use a blacklist or a whitelist approach (enable by default or disable by default) ? Also we still don't have any reports on failed AR5413 hw, could we at least limit that to AR2413 ?

Anyway I'll send a patch later today that disables fast channel switching by default and adds a module parameter to enable it...

Try this out...
http://www.kernel.org/pub/linux/kernel/people/mickflemm/01-fast-chan-switch-modparm

(In reply to comment #26)
> Try this out...
>
> http://www.kernel.org/pub/linux/kernel/people/mickflemm/01-fast-chan-switch-modparm

It works great! Thanks so much!

(In reply to comment #27)
> (In reply to comment #26)
> > Try this out...
> >
> http://www.kernel.org/pub/linux/kernel/people/mickflemm/01-fast-chan-switch-modparm
> 
> It works great! Thanks so much!

Boris: what about your association problem? Does it still occur? Is this also regression between 2.6.37 and 2.6.38?

Could you do bisecting between:
a) GOOD: 2.6.37
b) BAD: One commit before "ath5k: Fix fast channel switching"
and perhaps create new bug report.

(In reply to comment #28)

> Boris: what about your association problem? Does it still occur? Is this also
> regression between 2.6.37 and 2.6.38?

I applied patch to last commit Linus' kernel tree and haven't problem.


> Could you do bisecting between:
> a) GOOD: 2.6.37
> b) BAD: One commit before "ath5k: Fix fast channel switching"
> and perhaps create new bug report.

I saw commit before "fix fast..." b5f737... and it is working well at this moment.

So do I understand correctly that this issue is now resolved and the 
Patch: http://www.kernel.org/pub/linux/kernel/people/mickflemm/01-fast-chan-switch-modparm 

resolves this issue?

(In reply to comment #30)
> So do I understand correctly that this issue is now resolved and the 
> Patch:
>
> http://www.kernel.org/pub/linux/kernel/people/mickflemm/01-fast-chan-switch-modparm 
> 
> resolves this issue?

Yes of course.

sorry for the newbie question...on what release of the kernel this patch will be implented? Thanks..i am new to linux and i don't know how to patch manually! 


Thanks a lot!