2010-05-25 02:21:47

by Satish Eerpini

[permalink] [raw]
Subject: iwl3945 bug in 2.6.34

> Actually, sorry, but that patch will not work on 2.6.34 since the
> feature it enables is not present there - it will be in 2.6.35 though.
> To enable the feature in 2.6.34 will take some more backporting effort
> that I'm looking into now.
>
the patch does lead to a reject, I am not very experienced with
code-fu in the kernel, and have no clue about the iwl code base, but
comparing the code from 2.6.24 and the latest compat-wireless tarball,
I found that in iwl-core.c
iwl_check_stuck_queue
iwl_bg_monitor_recover
are not present in the 2.6.34 version of the file, is there a
particular reason for doing this ?
is there a patch series/discussion I can follow to know the details on this ?
and I am trying to compile 2.6.34 by adding just these two functions
to iwl-core.c. If that works I will report back (though you might
already know if it will work or not)


Cheers
Satish


--
http://tuxitter.blogspot.com



--
http://tuxitter.blogspot.com


2010-05-31 13:11:08

by Ivan Bulatovic

[permalink] [raw]
Subject: Re: iwl3945 bug in 2.6.34

On Tue, 2010-05-25 at 16:29 -0700, reinette chatre wrote:
> Hi Satish,
>
> On Mon, 2010-05-24 at 15:08 -0700, reinette chatre wrote:
> > On Mon, 2010-05-24 at 11:33 -0700, reinette chatre wrote:
> > > On Sat, 2010-05-22 at 23:25 -0700, Satish Eerpini wrote:
> > >
> > > > No probe response from AP 00:1b:da:2a:a1:53 after 500ms, disconnecting.
> > > > iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
> > > > iwl3945 0000:10:00.0: Error setting new configuration (-110).
> > > > iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
> > > > iwl3945 0000:10:00.0: Error setting new configuration (-110).
> > >
> > > This did not use to be an issue with 3945 and unfortunately we do not
> > > know what is triggering it now. Please try the "Enable stuck queue
> > > detection on 3945" patch that is attached to
> > > http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 as a
> > > workaround.
> >
> > Actually, sorry, but that patch will not work on 2.6.34 since the
> > feature it enables is not present there - it will be in 2.6.35 though.
> > To enable the feature in 2.6.34 will take some more backporting effort
> > that I'm looking into now.
>
> Please try the attached two patches.
>
> Reinette
>
I didn't have a problem with 2.6.34 but with 2.6.35-rc1 while obtaing IP
address with dhcpcd it bails out with reason 3 and gets timed out. I've
tried to increase timeout to 100 but the result is the same. I can't
apply this patches because base is somewhat different, as I can see the
first patch is already applied but the second one isn't. Any
suggestions ? Thanks. In the meantime I will try to get some more debug
information.


2010-05-25 23:29:49

by Reinette Chatre

[permalink] [raw]
Subject: Re: iwl3945 bug in 2.6.34

Hi Satish,

On Mon, 2010-05-24 at 15:08 -0700, reinette chatre wrote:
> On Mon, 2010-05-24 at 11:33 -0700, reinette chatre wrote:
> > On Sat, 2010-05-22 at 23:25 -0700, Satish Eerpini wrote:
> >
> > > No probe response from AP 00:1b:da:2a:a1:53 after 500ms, disconnecting.
> > > iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
> > > iwl3945 0000:10:00.0: Error setting new configuration (-110).
> > > iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
> > > iwl3945 0000:10:00.0: Error setting new configuration (-110).
> >
> > This did not use to be an issue with 3945 and unfortunately we do not
> > know what is triggering it now. Please try the "Enable stuck queue
> > detection on 3945" patch that is attached to
> > http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 as a
> > workaround.
>
> Actually, sorry, but that patch will not work on 2.6.34 since the
> feature it enables is not present there - it will be in 2.6.35 though.
> To enable the feature in 2.6.34 will take some more backporting effort
> that I'm looking into now.

Please try the attached two patches.

Reinette


Attachments:
0001-iwlwifi-Recover-TX-flow-stall-due-to-stuck-queue.patch (18.06 kB)
0002-iwl3945-enable-stuck-queue-detection-on-3945.patch (1.14 kB)
Download all attachments

2010-06-10 18:49:49

by Satish Eerpini

[permalink] [raw]
Subject: Re: iwl3945 bug in 2.6.34

I have applied the patches to the 2.6.34 kernel, my machine has been
up for 20 hours now, there is nothing in the dmesg either, dmesg |
grep wlan0 just gives this :

ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: deauthenticating from 00:1b:da:2a:a1:53 by local choice (reason=3)
wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
wlan0: authenticated
wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: no IPv6 routers present
wlan0: deauthenticating from 00:1b:da:2a:a1:53 by local choice (reason=3)
ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: deauthenticating from 00:1b:da:2a:a1:53 by local choice (reason=3)
wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
wlan0: authenticated
wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: no IPv6 routers present
wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
wlan0: authenticated
wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
wlan0: associated
wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
wlan0: authenticated
wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
wlan0: associated

so I think after applying the patches, things have been working fine.

Cheers
Satish

--
http://satisheerpini.net

2010-06-03 21:32:18

by Reinette Chatre

[permalink] [raw]
Subject: Re: iwl3945 bug in 2.6.34

Hi Satish,

On Tue, 2010-05-25 at 16:29 -0700, reinette chatre wrote:
> On Mon, 2010-05-24 at 15:08 -0700, reinette chatre wrote:
> > On Mon, 2010-05-24 at 11:33 -0700, reinette chatre wrote:
> > > On Sat, 2010-05-22 at 23:25 -0700, Satish Eerpini wrote:
> > >
> > > > No probe response from AP 00:1b:da:2a:a1:53 after 500ms, disconnecting.
> > > > iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
> > > > iwl3945 0000:10:00.0: Error setting new configuration (-110).
> > > > iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
> > > > iwl3945 0000:10:00.0: Error setting new configuration (-110).
> > >
> > > This did not use to be an issue with 3945 and unfortunately we do not
> > > know what is triggering it now. Please try the "Enable stuck queue
> > > detection on 3945" patch that is attached to
> > > http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 as a
> > > workaround.
> >
> > Actually, sorry, but that patch will not work on 2.6.34 since the
> > feature it enables is not present there - it will be in 2.6.35 though.
> > To enable the feature in 2.6.34 will take some more backporting effort
> > that I'm looking into now.
>
> Please try the attached two patches.

Were you able to test these patches?

Thanks

Reinette



2010-06-11 16:27:30

by Reinette Chatre

[permalink] [raw]
Subject: Re: iwl3945 bug in 2.6.34

On Fri, 2010-06-11 at 04:39 -0700, Satish Eerpini wrote:
> The 2.6.34 vanilla kernel with the above patches applied crashed again
> today, I was amidst a conference on webex when this happened, still
> not able to figure out what is the kind of traffic that causes the
> driver to give up ... here is output from dmesg :

Instead of duplicate posts to the list and bugzilla, lets just continue
debugging this at https://bugzilla.kernel.org/show_bug.cgi?id=16084 - I
responded there to your message.

Thanks

Reinette



2010-06-11 11:39:21

by Satish Eerpini

[permalink] [raw]
Subject: Re: iwl3945 bug in 2.6.34

The 2.6.34 vanilla kernel with the above patches applied crashed again
today, I was amidst a conference on webex when this happened, still
not able to figure out what is the kind of traffic that causes the
driver to give up ... here is output from dmesg :


cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: IN
cfg80211: Regulatory domain changed to country: IN
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(5735000 KHz - 5835000 KHz @ 20000 KHz), (N/A, 2000 mBm)
wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
wlan0: authenticated
wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
wlan0: associated
usb 4-2: USB disconnect, address 4
iwl3945 0000:10:00.0: queue 2 stuck 3 time. Fw reload.
iwl3945 0000:10:00.0: On demand firmware reload
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
iwl3945 0000:10:00.0: BSM uCode verification failed at addr
0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
iwl3945 0000:10:00.0: Wait for START_ALIVE timeout after 2000ms.
No probe response from AP 00:1b:da:2a:a1:53 after 500ms, disconnecting.
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: IN
cfg80211: Regulatory domain changed to country: IN
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 2000 mBm)
(5735000 KHz - 5835000 KHz @ 20000 KHz), (N/A, 2000 mBm)

is there anything else that can be done ??

Cheers
Satish

On Fri, Jun 11, 2010 at 12:19 AM, Satish Eerpini <[email protected]> wrote:
> I have applied the patches to the 2.6.34 kernel, my machine has been
> up for 20 hours now, there is nothing in the dmesg either, dmesg |
> grep wlan0 just gives this :
>
> ADDRCONF(NETDEV_UP): wlan0: link is not ready
> wlan0: deauthenticating from 00:1b:da:2a:a1:53 by local choice (reason=3)
> wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: authenticated
> wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
> wlan0: associated
> ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> wlan0: no IPv6 routers present
> wlan0: deauthenticating from 00:1b:da:2a:a1:53 by local choice (reason=3)
> ADDRCONF(NETDEV_UP): wlan0: link is not ready
> wlan0: deauthenticating from 00:1b:da:2a:a1:53 by local choice (reason=3)
> wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: authenticated
> wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
> wlan0: associated
> ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> wlan0: no IPv6 routers present
> wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: authenticated
> wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
> wlan0: associated
> wlan0: authenticate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: authenticated
> wlan0: associate with 00:1b:da:2a:a1:53 (try 1)
> wlan0: RX AssocResp from 00:1b:da:2a:a1:53 (capab=0x411 status=0 aid=1)
> wlan0: associated
>
> so I think after applying the patches, things have been working fine.
>
> Cheers
> Satish
>
> --
> http://satisheerpini.net
>



--
http://satisheerpini.net