Bugzilla – Bug 1822
Call trace at mac80211.h:1884
Last modified: 2009-01-20 21:04:19
You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=1664) [details] Call trace Testing Environment Platform : Intel SDV M3M41 Wireless Card : Intel(R) WiFi Link 5100 OS : Redhat Fedora 9 64bit AP : Cisco 1250 uCode : iwlwifi-5000-1.ucode 7.A.1.1B Source : official linux kernel 2.6.28-rc2 Issue: After DUT associates to AP, switch to another AP will get call trace at mac80211.h:1884. dmesg log attached. It's easy to reproduce this issue. Since it's official kernel, I don't think it's proper to see call trace many times. Steps to Reproduce: 1 modprobe iwlagn 2 ifconfig wlan0 up 3 iwconfig wlan0 channel 8 essid <essid1> 4 iwconfig to check if already associated to <essid1> 5 iwconfig wlan0 channel 149 essid <essid2> 6 dmesg will show calltrace attached.
Please try with the development tree.
Created an attachment (id=1671) [details] dmesg with debug50=0x43fff
Same on development tree with commit 957b2e1c1aca34e1ad1999d1a215db69a70f695f (Nov. 7)
This issue has been fixed in development tree. Since this issue original found in official kernel, we will check if this issue is fixed in official kernel.
*** Bug 1865 has been marked as a duplicate of this bug. ***
This issue also happens on 4965. Following script always reproduced this call trace on our machines. #!/bin/bash set -x modprobe -r iwlagn ;sleep 1 modprobe iwlagn debug=0x43fff;sleep 1 iwconfig wlan0 essid otc-11215947-dlink2-g channel 11 ;sleep 2 ifconfig wlan0 192.168.50.191 ;sleep 1 ping -c 3 192.168.50.75 ;sleep 1 iwconfig wlan0 channel 149 essid otc-11215947-dlink2-a;sleep 1 dmesg
Change the severity since this issue is top 10 of kerneloops.org. This issue happened on both official kernel and iwlwifi-2.6
Created an attachment (id=1759) [details] fix warn on rs fix call trace at mac80211.h
please try out against latest
(In reply to comment #8) > Created an attachment (id=1759) [details] [details] > fix warn on rs > > fix call trace at mac80211.h > (In reply to comment #9) > please try out against latest > Are there any results available from testing this patch? This is a high profile issue and if this patch solves the problem we should get it upstream.
*** Bug 1862 has been marked as a duplicate of this bug. ***
I didn't see this call trace in recent testing. And I tried the script in comment #4 for more than 30 times without see the call trace. So close this bug (though it's originally in official kernel). I'll reopen it if I see it again in the future.
(In reply to comment #12) > I didn't see this call trace in recent testing. And I tried the script in > comment #4 for more than 30 times without see the call trace. So close this bug > (though it's originally in official kernel). I'll reopen it if I see it again > in the future. > Did your testing use the patch from comment #8 ?
No, I didn't apply that patch.
Mohamed, Do you perhaps know why the problem disappeared without applying your patch? Do you still want your patch included upstream?
I will look at mac80211 I see if they did anything to fix. I will get back to you if this patch still needed.
I still see this problem with latest tree. make sure first you associate with G AP then you switch to A network like doing #iwconfig wlan0 channel 149 essid <essid2> you will see the assert.
Yes. I saw it again with the latest code (commit 8e26739cd40a0e9772ec3ccc11f60fd5275cf0ae). Very weired. I tried it for a long time on Tuesday since this was reported by me... I will apply Mohamed's patch and test again...
Yes. After applying Mohamed's patch, I don't see the call trace again. I tried on both 32/64bit OS on 4965 machines.
(In reply to comment #19) > Yes. After applying Mohamed's patch, I don't see the call trace again. I tried > on both 32/64bit OS on 4965 machines. > Jeff, thank you very much for testing. Mohamed, could you please send me the patch with a descriptive commit message and Signed-off-by ?
This issue exists on 3945/4965/5300 for official 2.6.28 kernel
Still exists in 2.6.29-rc1
Mohamed's patch as integrated into Fedora's kernel-2.6.28.1-9.rc2.fc10.x86_64 fixes the problem for me. No more oopses or disconnects.
(In reply to comment #22) > Still exists in 2.6.29-rc1 > The patch has not been included in the vanilla 2.6.29-rcX kernel yet.