* unloading WiFi modules is usually triggering kernel crash @ 2012-07-31 12:54 Pedro Francisco 2012-07-31 13:13 ` John W. Linville 2012-08-07 10:22 ` Stanislaw Gruszka 0 siblings, 2 replies; 10+ messages in thread From: Pedro Francisco @ 2012-07-31 12:54 UTC (permalink / raw) To: ML linux-wireless I've noticed in the past few days a pattern: sometimes nm-applet starts showing empty bars for the signal strength. Running the script: sudo ifconfig wlan0 down; sleep 1 sudo rmmod hp_wmi; sudo rmmod iwl3945; sudo rmmod iwlegacy; sudo rmmod mac80211; sudo rmmod cfg80211 sleep 2; sudo rmmod rfkill; sync sudo modprobe rfkill; sudo modprobe cfg80211; sudo modprobe mac80211; sudo modprobe iwlegacy sudo modprobe iwl3945; sudo modprobe hp_wmi; sleep 1; sudo ifconfig wlan0 up usually triggers a kernel crash. This has happened twice so far. I tried it now for the third time but it didn't crash. Logs (running with slub_debug ): https://dl.dropbox.com/u/1332655/WiFi-issues/notTainted-cfg80211_mlme_disassoc-WARNING.log https://dl.dropbox.com/u/1332655/WiFi-issues/alreadyTainted-debug_print_object-WARNING.log (debug_print_object-WARNING was caused by running the above script rmmoding things) https://dl.dropbox.com/u/1332655/WiFi-issues/iw_dev_scan.log https://dl.dropbox.com/u/1332655/WiFi-issues/gshell-wifiBars_empty.png Any ideas on what is going on? Looking at other mails around here it seems not to be driver specific, at least the cfg80211_mlme_disassoc part. Thanks in Advance, -- Pedro ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: unloading WiFi modules is usually triggering kernel crash 2012-07-31 12:54 unloading WiFi modules is usually triggering kernel crash Pedro Francisco @ 2012-07-31 13:13 ` John W. Linville 2012-08-07 10:22 ` Stanislaw Gruszka 1 sibling, 0 replies; 10+ messages in thread From: John W. Linville @ 2012-07-31 13:13 UTC (permalink / raw) To: Pedro Francisco; +Cc: ML linux-wireless, johannes On Tue, Jul 31, 2012 at 01:54:52PM +0100, Pedro Francisco wrote: > I've noticed in the past few days a pattern: sometimes nm-applet > starts showing empty bars for the signal strength. > > Running the script: > sudo ifconfig wlan0 down; sleep 1 > sudo rmmod hp_wmi; sudo rmmod iwl3945; sudo rmmod iwlegacy; sudo rmmod > mac80211; sudo rmmod cfg80211 > sleep 2; sudo rmmod rfkill; sync > sudo modprobe rfkill; sudo modprobe cfg80211; sudo modprobe mac80211; > sudo modprobe iwlegacy > sudo modprobe iwl3945; sudo modprobe hp_wmi; sleep 1; sudo ifconfig wlan0 up > > usually triggers a kernel crash. This has happened twice so far. I > tried it now for the third time but it didn't crash. > > Logs (running with slub_debug ): > https://dl.dropbox.com/u/1332655/WiFi-issues/notTainted-cfg80211_mlme_disassoc-WARNING.log > https://dl.dropbox.com/u/1332655/WiFi-issues/alreadyTainted-debug_print_object-WARNING.log > (debug_print_object-WARNING was caused by running the above script > rmmoding things) > https://dl.dropbox.com/u/1332655/WiFi-issues/iw_dev_scan.log > https://dl.dropbox.com/u/1332655/WiFi-issues/gshell-wifiBars_empty.png > > Any ideas on what is going on? Looking at other mails around here it > seems not to be driver specific, at least the cfg80211_mlme_disassoc > part. Looks the same as this one, FWIW... https://bugzilla.redhat.com/show_bug.cgi?id=834158 John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: unloading WiFi modules is usually triggering kernel crash 2012-07-31 12:54 unloading WiFi modules is usually triggering kernel crash Pedro Francisco 2012-07-31 13:13 ` John W. Linville @ 2012-08-07 10:22 ` Stanislaw Gruszka 2012-08-30 15:58 ` Pedro Francisco 1 sibling, 1 reply; 10+ messages in thread From: Stanislaw Gruszka @ 2012-08-07 10:22 UTC (permalink / raw) To: Pedro Francisco; +Cc: ML linux-wireless On Tue, Jul 31, 2012 at 01:54:52PM +0100, Pedro Francisco wrote: > I've noticed in the past few days a pattern: sometimes nm-applet > starts showing empty bars for the signal strength. RSSI reporting problem or maybe NM issue. When you change kernel to older or newer does this problem go away ? > Running the script: > sudo ifconfig wlan0 down; sleep 1 > sudo rmmod hp_wmi; sudo rmmod iwl3945; sudo rmmod iwlegacy; sudo rmmod > mac80211; sudo rmmod cfg80211 > sleep 2; sudo rmmod rfkill; sync > sudo modprobe rfkill; sudo modprobe cfg80211; sudo modprobe mac80211; > sudo modprobe iwlegacy > sudo modprobe iwl3945; sudo modprobe hp_wmi; sleep 1; sudo ifconfig wlan0 up I run a bit modified script (I do not have hp_wmi.ko and rfkill.ko) for few hours, and did not get any WARNING/crash. I used 3.5, can you check if that problem is also fixed on your system on 3.5 or newer. Stanislaw ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: unloading WiFi modules is usually triggering kernel crash 2012-08-07 10:22 ` Stanislaw Gruszka @ 2012-08-30 15:58 ` Pedro Francisco 2012-09-26 12:47 ` Pedro Francisco 0 siblings, 1 reply; 10+ messages in thread From: Pedro Francisco @ 2012-08-30 15:58 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: ML linux-wireless On Tue, Aug 7, 2012 at 11:22 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote: > On Tue, Jul 31, 2012 at 01:54:52PM +0100, Pedro Francisco wrote: >> I've noticed in the past few days a pattern: sometimes nm-applet >> starts showing empty bars for the signal strength. > > RSSI reporting problem or maybe NM issue. When you change kernel to > older or newer does this problem go away ? > >> Running the script: >> sudo ifconfig wlan0 down; sleep 1 >> sudo rmmod hp_wmi; sudo rmmod iwl3945; sudo rmmod iwlegacy; sudo rmmod >> mac80211; sudo rmmod cfg80211 >> sleep 2; sudo rmmod rfkill; sync >> sudo modprobe rfkill; sudo modprobe cfg80211; sudo modprobe mac80211; >> sudo modprobe iwlegacy >> sudo modprobe iwl3945; sudo modprobe hp_wmi; sleep 1; sudo ifconfig wlan0 up > > I run a bit modified script (I do not have hp_wmi.ko and rfkill.ko) for few > hours, and did not get any WARNING/crash. I used 3.5, can you check if that > problem is also fixed on your system on 3.5 or newer. On 3.5.2-3.fc17.i686.PAE everything seems stable. The problem I had described hasn't happened recently. I guess it got fixed in the meantime. Thank you for your time, -- Pedro ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: unloading WiFi modules is usually triggering kernel crash 2012-08-30 15:58 ` Pedro Francisco @ 2012-09-26 12:47 ` Pedro Francisco 2012-10-03 14:30 ` Stanislaw Gruszka 0 siblings, 1 reply; 10+ messages in thread From: Pedro Francisco @ 2012-09-26 12:47 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: ML linux-wireless On Thu, Aug 30, 2012 at 4:58 PM, Pedro Francisco <pedrogfrancisco@gmail.com> wrote: > On Tue, Aug 7, 2012 at 11:22 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote: >> On Tue, Jul 31, 2012 at 01:54:52PM +0100, Pedro Francisco wrote: >>> I've noticed in the past few days a pattern: sometimes nm-applet >>> starts showing empty bars for the signal strength. >> >> RSSI reporting problem or maybe NM issue. When you change kernel to >> older or newer does this problem go away ? >> >>> Running the script: >>> sudo ifconfig wlan0 down; sleep 1 >>> sudo rmmod hp_wmi; sudo rmmod iwl3945; sudo rmmod iwlegacy; sudo rmmod >>> mac80211; sudo rmmod cfg80211 >>> sleep 2; sudo rmmod rfkill; sync >>> sudo modprobe rfkill; sudo modprobe cfg80211; sudo modprobe mac80211; >>> sudo modprobe iwlegacy >>> sudo modprobe iwl3945; sudo modprobe hp_wmi; sleep 1; sudo ifconfig wlan0 up >> >> I run a bit modified script (I do not have hp_wmi.ko and rfkill.ko) for few >> hours, and did not get any WARNING/crash. I used 3.5, can you check if that >> problem is also fixed on your system on 3.5 or newer. > > On 3.5.2-3.fc17.i686.PAE everything seems stable. The problem I had > described hasn't happened recently. > I guess it got fixed in the meantime. I was wrong, got it again. So, to recap: once the network applet shows no signal, but only then, removing the wireless modules triggers an unrecoverable kernel panic. I still haven't compiled a relocatable x86 kernel to get a proper backtrace using kexec/kdump, sorry. I found something else as well. Notice this output of "iwconfig" when everything is _normal_: $ iwconfig wlan0 wlan0 IEEE 802.11abg ESSID:"eduroam" Mode:Managed Frequency:2.437 GHz Access Point: B8:62:1F:XX:XX:XX Bit Rate=54 Mb/s Tx-Power=15 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=58/70 Signal level=-52 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 When I have the "empty signal bars" issue: $ iwconfig wlan0 wlan0 IEEE 802.11abg ESSID:off/any Mode:Managed Access Point: Not-Associated Tx-Power=15 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off In case you're wondering, it is connected and streaming stuff :) I can sometimes trigger it on purpose: I just have to roam to a 5GHz AP of the same ESS, cycle around 2GHz and back to 5GHz (using wpa_cli roam XX:XX:XX:XX:XX ). If I get "SME: Authentication request to the driver failed", then disabling NetworkManager (not wireless) and reenabling will _probably_ get the "empty signal bars" (I was just able to trigger the "empty signal bars" now after a clean boot). So I'm guessing something gets corrupted, which is why reloading the modules will crash. I'm aware due to a patch to _iwlwifi_ (not iwl3945/iwlegacy) [1] that 2->5GHz roaming is not working very well on newer Intel wireless cards so it is worth considering it is happening here as well. Also, note some info, collected two days ago, relative to "Invalid misc:" is getting 10 "invalid misc" packets in 10 seconds normal? Several 'VAL=`date`; VAL="$VAL $(iwconfig wlan0 |grep "Invalid misc")"; echo $VAL' follow: Seg Set 24 15:06:36 WEST 2012 Tx excessive retries:5 Invalid misc:133 Missed beacon:0 Seg Set 24 15:06:46 WEST 2012 Tx excessive retries:5 Invalid misc:143 Missed beacon:0 Seg Set 24 15:07:00 WEST 2012 Tx excessive retries:5 Invalid misc:148 Missed beacon:0 Seg Set 24 15:21:46 WEST 2012 Tx excessive retries:22 Invalid misc:495 Missed beacon:0 Seg Set 24 15:24:41 WEST 2012 Tx excessive retries:24 Invalid misc:593 Missed beacon:0 So, something is getting corrupted here. Do you want the full logs? [1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/89361/focus=89445 -- Pedro ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: unloading WiFi modules is usually triggering kernel crash 2012-09-26 12:47 ` Pedro Francisco @ 2012-10-03 14:30 ` Stanislaw Gruszka 2012-10-09 9:14 ` Pedro Francisco 0 siblings, 1 reply; 10+ messages in thread From: Stanislaw Gruszka @ 2012-10-03 14:30 UTC (permalink / raw) To: Pedro Francisco; +Cc: ML linux-wireless, Johannes Berg On Wed, Sep 26, 2012 at 01:47:18PM +0100, Pedro Francisco wrote: > On Thu, Aug 30, 2012 at 4:58 PM, Pedro Francisco > <pedrogfrancisco@gmail.com> wrote: > > On Tue, Aug 7, 2012 at 11:22 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote: > >> On Tue, Jul 31, 2012 at 01:54:52PM +0100, Pedro Francisco wrote: > >>> I've noticed in the past few days a pattern: sometimes nm-applet > >>> starts showing empty bars for the signal strength. > >> > >> RSSI reporting problem or maybe NM issue. When you change kernel to > >> older or newer does this problem go away ? > >> > >>> Running the script: > >>> sudo ifconfig wlan0 down; sleep 1 > >>> sudo rmmod hp_wmi; sudo rmmod iwl3945; sudo rmmod iwlegacy; sudo rmmod > >>> mac80211; sudo rmmod cfg80211 > >>> sleep 2; sudo rmmod rfkill; sync > >>> sudo modprobe rfkill; sudo modprobe cfg80211; sudo modprobe mac80211; > >>> sudo modprobe iwlegacy > >>> sudo modprobe iwl3945; sudo modprobe hp_wmi; sleep 1; sudo ifconfig wlan0 up > >> > >> I run a bit modified script (I do not have hp_wmi.ko and rfkill.ko) for few > >> hours, and did not get any WARNING/crash. I used 3.5, can you check if that > >> problem is also fixed on your system on 3.5 or newer. > > > > On 3.5.2-3.fc17.i686.PAE everything seems stable. The problem I had > > described hasn't happened recently. > > I guess it got fixed in the meantime. > > I was wrong, got it again. > > So, to recap: once the network applet shows no signal, but only then, > removing the wireless modules triggers an unrecoverable kernel panic. > I still haven't compiled a relocatable x86 kernel to get a proper > backtrace using kexec/kdump, sorry. > > I found something else as well. Notice this output of "iwconfig" when > everything is _normal_: > $ iwconfig wlan0 > wlan0 IEEE 802.11abg ESSID:"eduroam" > Mode:Managed Frequency:2.437 GHz Access Point: B8:62:1F:XX:XX:XX > Bit Rate=54 Mb/s Tx-Power=15 dBm > Retry long limit:7 RTS thr:off Fragment thr:off > Power Management:off > Link Quality=58/70 Signal level=-52 dBm > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > When I have the "empty signal bars" issue: > $ iwconfig wlan0 > wlan0 IEEE 802.11abg ESSID:off/any > Mode:Managed Access Point: Not-Associated Tx-Power=15 dBm > Retry long limit:7 RTS thr:off Fragment thr:off > Power Management:off > > In case you're wondering, it is connected and streaming stuff :) > > I can sometimes trigger it on purpose: I just have to roam to a 5GHz > AP of the same ESS, cycle around 2GHz and back to 5GHz (using wpa_cli > roam XX:XX:XX:XX:XX ). If I get "SME: Authentication request to the > driver failed", then disabling NetworkManager (not wireless) and > reenabling will _probably_ get the "empty signal bars" (I was just > able to trigger the "empty signal bars" now after a clean boot). > So I'm guessing something gets corrupted, which is why reloading the > modules will crash. We do not stop mac80211 timers on module unload. I reproduced below warnings with iwlwifi on 3.5 kernel with DEBUG_OBJECTS enabled. I forced roaming many times, and then do "modprobe -r iwlwifi". Unfortunately those steps do not trigger warnings anytime, they happened just once. iwlwifi 0000:02:00.0: ACTIVATE a non DRIVER active station id 0 addr 6c:50:4d:3f:79:73 ------------[ cut here ]------------ WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0() Hardware name: SandyBridge Platform ODEBUG: free active (active state 0) object type: timer_list hint: ieee80211_sta_conn_mon_timer+0x0/0x40 [mac80211] Modules linked in: autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 uinput arc4 sg iwlwifi(-) mac80211 cfg80211 rfkill coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr lpc_ich mfd_core i2c_i801 e1000e ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom aesni_intel cryptd aes_x86_64 aes_generic ahci libahci i915 drm_kms_helper drm i2c_algo_bit i2c_core video dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan] Pid: 3064, comm: modprobe Not tainted 3.5.0 #1 Call Trace: [<ffffffff810535af>] warn_slowpath_common+0x7f/0xc0 [<ffffffff810536a6>] warn_slowpath_fmt+0x46/0x50 [<ffffffff812901be>] debug_print_object+0x8e/0xb0 [<ffffffffa03a09b0>] ? ieee80211_chswitch_timer+0x40/0x40 [mac80211] [<ffffffff81290a0d>] __debug_check_no_obj_freed+0x10d/0x200 [<ffffffff81290b1d>] debug_check_no_obj_freed+0x1d/0x30 [<ffffffff8117a2b0>] kfree+0xc0/0x330 [<ffffffff810b9083>] ? __lock_release+0x133/0x1a0 [<ffffffff815555f0>] ? _raw_spin_unlock_irqrestore+0x40/0x80 [<ffffffff814957c4>] netdev_release+0x44/0x60 [<ffffffff813704b7>] device_release+0x27/0xa0 [<ffffffff8127da42>] kobject_cleanup+0x82/0x1b0 [<ffffffff8127db7d>] kobject_release+0xd/0x10 [<ffffffff8127d8cc>] kobject_put+0x2c/0x60 [<ffffffff8147e371>] netdev_run_todo+0x101/0x180 [<ffffffff8148f5ae>] rtnl_unlock+0xe/0x10 [<ffffffffa0366178>] ieee80211_unregister_hw+0x58/0x120 [mac80211] [<ffffffffa040912b>] iwlagn_mac_unregister+0x2b/0x40 [iwlwifi] [<ffffffffa03fdf59>] iwl_op_mode_dvm_stop+0x49/0xf0 [iwlwifi] [<ffffffffa041f730>] iwl_drv_stop+0x40/0x60 [iwlwifi] [<ffffffffa0430a39>] iwl_pci_remove+0x25/0x3c [iwlwifi] [<ffffffff812aafc2>] pci_device_remove+0x52/0x120 [<ffffffff813741cc>] __device_release_driver+0x7c/0xe0 [<ffffffff81374308>] driver_detach+0xd8/0xe0 [<ffffffff81372f61>] bus_remove_driver+0x91/0x110 [<ffffffff81374fd2>] driver_unregister+0x62/0xa0 [<ffffffff812ab2b4>] pci_unregister_driver+0x44/0xa0 [<ffffffffa041f3d5>] iwl_pci_unregister_driver+0x15/0x20 [iwlwifi] [<ffffffffa0430a01>] iwl_exit+0x9/0x1c [iwlwifi] [<ffffffff810c50f1>] sys_delete_module+0x1d1/0x2c0 [<ffffffff81555855>] ? retint_swapgs+0x13/0x1b [<ffffffff810e169c>] ? __audit_syscall_entry+0xcc/0x210 [<ffffffff812896ce>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff8155de69>] system_call_fastpath+0x16/0x1b ---[ end trace 8070f580fc119b8b ]--- ------------[ cut here ]------------ WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0() Hardware name: SandyBridge Platform ODEBUG: free active (active state 0) object type: timer_list hint: ieee80211_sta_bcn_mon_timer+0x0/0x40 [mac80211] Modules linked in: autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 uinput arc4 sg iwlwifi(-) mac80211 cfg80211 rfkill coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr lpc_ich mfd_core i2c_i801 e1000e ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom aesni_intel cryptd aes_x86_64 aes_generic ahci libahci i915 drm_kms_helper drm i2c_algo_bit i2c_core video dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan] Pid: 3064, comm: modprobe Tainted: G W 3.5.0 #1 Call Trace: [<ffffffff810535af>] warn_slowpath_common+0x7f/0xc0 [<ffffffff810536a6>] warn_slowpath_fmt+0x46/0x50 [<ffffffff812901be>] debug_print_object+0x8e/0xb0 [<ffffffffa03a09f0>] ? ieee80211_sta_conn_mon_timer+0x40/0x40 [mac80211] [<ffffffff81290a0d>] __debug_check_no_obj_freed+0x10d/0x200 [<ffffffff81290b1d>] debug_check_no_obj_freed+0x1d/0x30 [<ffffffff8117a2b0>] kfree+0xc0/0x330 [<ffffffff810b9083>] ? __lock_release+0x133/0x1a0 [<ffffffff815555f0>] ? _raw_spin_unlock_irqrestore+0x40/0x80 [<ffffffff814957c4>] netdev_release+0x44/0x60 [<ffffffff813704b7>] device_release+0x27/0xa0 [<ffffffff8127da42>] kobject_cleanup+0x82/0x1b0 [<ffffffff8127db7d>] kobject_release+0xd/0x10 [<ffffffff8127d8cc>] kobject_put+0x2c/0x60 [<ffffffff8147e371>] netdev_run_todo+0x101/0x180 [<ffffffff8148f5ae>] rtnl_unlock+0xe/0x10 [<ffffffffa0366178>] ieee80211_unregister_hw+0x58/0x120 [mac80211] [<ffffffffa040912b>] iwlagn_mac_unregister+0x2b/0x40 [iwlwifi] [<ffffffffa03fdf59>] iwl_op_mode_dvm_stop+0x49/0xf0 [iwlwifi] [<ffffffffa041f730>] iwl_drv_stop+0x40/0x60 [iwlwifi] [<ffffffffa0430a39>] iwl_pci_remove+0x25/0x3c [iwlwifi] [<ffffffff812aafc2>] pci_device_remove+0x52/0x120 [<ffffffff813741cc>] __device_release_driver+0x7c/0xe0 [<ffffffff81374308>] driver_detach+0xd8/0xe0 [<ffffffff81372f61>] bus_remove_driver+0x91/0x110 [<ffffffff81374fd2>] driver_unregister+0x62/0xa0 [<ffffffff812ab2b4>] pci_unregister_driver+0x44/0xa0 [<ffffffffa041f3d5>] iwl_pci_unregister_driver+0x15/0x20 [iwlwifi] [<ffffffffa0430a01>] iwl_exit+0x9/0x1c [iwlwifi] [<ffffffff810c50f1>] sys_delete_module+0x1d1/0x2c0 [<ffffffff81555855>] ? retint_swapgs+0x13/0x1b [<ffffffff810e169c>] ? __audit_syscall_entry+0xcc/0x210 [<ffffffff812896ce>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff8155de69>] system_call_fastpath+0x16/0x1b ---[ end trace 8070f580fc119b8c ]--- Bridge firewalling registered > misc:" is getting 10 "invalid misc" packets in 10 seconds normal? > Several 'VAL=`date`; VAL="$VAL $(iwconfig wlan0 |grep "Invalid > misc")"; echo $VAL' follow: > Seg Set 24 15:06:36 WEST 2012 Tx excessive retries:5 Invalid misc:133 > Missed beacon:0 > Seg Set 24 15:06:46 WEST 2012 Tx excessive retries:5 Invalid misc:143 > Missed beacon:0 > Seg Set 24 15:07:00 WEST 2012 Tx excessive retries:5 Invalid misc:148 > Missed beacon:0 > Seg Set 24 15:21:46 WEST 2012 Tx excessive retries:22 Invalid misc:495 > Missed beacon:0 > Seg Set 24 15:24:41 WEST 2012 Tx excessive retries:24 Invalid misc:593 > Missed beacon:0 I see lot of that. This can be caused by noisy radio environment, but also can be a firmware/driver bug. Unfortunately those kind of bugs are not easy to fix. Stanislaw ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: unloading WiFi modules is usually triggering kernel crash 2012-10-03 14:30 ` Stanislaw Gruszka @ 2012-10-09 9:14 ` Pedro Francisco 2012-10-12 12:13 ` Stanislaw Gruszka 0 siblings, 1 reply; 10+ messages in thread From: Pedro Francisco @ 2012-10-09 9:14 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: ML linux-wireless, Johannes Berg On Wed, Oct 3, 2012 at 3:30 PM, Stanislaw Gruszka <sgruszka@redhat.com> wrote: > On Wed, Sep 26, 2012 at 01:47:18PM +0100, Pedro Francisco wrote: >> On Thu, Aug 30, 2012 at 4:58 PM, Pedro Francisco >> <pedrogfrancisco@gmail.com> wrote: >> > On Tue, Aug 7, 2012 at 11:22 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote: >> >> On Tue, Jul 31, 2012 at 01:54:52PM +0100, Pedro Francisco wrote: >> >>> I've noticed in the past few days a pattern: sometimes nm-applet >> >>> starts showing empty bars for the signal strength. >> >> >> >> RSSI reporting problem or maybe NM issue. When you change kernel to >> >> older or newer does this problem go away ? >> >> >> >>> Running the script: >> >>> sudo ifconfig wlan0 down; sleep 1 >> >>> sudo rmmod hp_wmi; sudo rmmod iwl3945; sudo rmmod iwlegacy; sudo rmmod >> >>> mac80211; sudo rmmod cfg80211 >> >>> sleep 2; sudo rmmod rfkill; sync >> >>> sudo modprobe rfkill; sudo modprobe cfg80211; sudo modprobe mac80211; >> >>> sudo modprobe iwlegacy >> >>> sudo modprobe iwl3945; sudo modprobe hp_wmi; sleep 1; sudo ifconfig wlan0 up >> >> >> >> I run a bit modified script (I do not have hp_wmi.ko and rfkill.ko) for few >> >> hours, and did not get any WARNING/crash. I used 3.5, can you check if that >> >> problem is also fixed on your system on 3.5 or newer. >> > >> > On 3.5.2-3.fc17.i686.PAE everything seems stable. The problem I had >> > described hasn't happened recently. >> > I guess it got fixed in the meantime. >> >> I was wrong, got it again. >> >> So, to recap: once the network applet shows no signal, but only then, >> removing the wireless modules triggers an unrecoverable kernel panic. >> I still haven't compiled a relocatable x86 kernel to get a proper >> backtrace using kexec/kdump, sorry. >> >> I found something else as well. Notice this output of "iwconfig" when >> everything is _normal_: >> $ iwconfig wlan0 >> wlan0 IEEE 802.11abg ESSID:"eduroam" >> Mode:Managed Frequency:2.437 GHz Access Point: B8:62:1F:XX:XX:XX >> Bit Rate=54 Mb/s Tx-Power=15 dBm >> Retry long limit:7 RTS thr:off Fragment thr:off >> Power Management:off >> Link Quality=58/70 Signal level=-52 dBm >> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 >> Tx excessive retries:0 Invalid misc:0 Missed beacon:0 >> >> When I have the "empty signal bars" issue: >> $ iwconfig wlan0 >> wlan0 IEEE 802.11abg ESSID:off/any >> Mode:Managed Access Point: Not-Associated Tx-Power=15 dBm >> Retry long limit:7 RTS thr:off Fragment thr:off >> Power Management:off >> >> In case you're wondering, it is connected and streaming stuff :) >> >> I can sometimes trigger it on purpose: I just have to roam to a 5GHz >> AP of the same ESS, cycle around 2GHz and back to 5GHz (using wpa_cli >> roam XX:XX:XX:XX:XX ). If I get "SME: Authentication request to the >> driver failed", then disabling NetworkManager (not wireless) and >> reenabling will _probably_ get the "empty signal bars" (I was just >> able to trigger the "empty signal bars" now after a clean boot). >> So I'm guessing something gets corrupted, which is why reloading the >> modules will crash. > > We do not stop mac80211 timers on module unload. I reproduced below > warnings with iwlwifi on 3.5 kernel with DEBUG_OBJECTS enabled. > I forced roaming many times, and then do "modprobe -r iwlwifi". > Unfortunately those steps do not trigger warnings anytime, they > happened just once. > > iwlwifi 0000:02:00.0: ACTIVATE a non DRIVER active station id 0 addr 6c:50:4d:3f:79:73 > ------------[ cut here ]------------ > WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0() > Hardware name: SandyBridge Platform > ODEBUG: free active (active state 0) object type: timer_list hint: > ieee80211_sta_conn_mon_timer+0x0/0x40 [mac80211] > Modules linked in: autofs4 sunrpc cpufreq_ondemand acpi_cpufreq > freq_table mperf ipv6 uinput arc4 sg iwlwifi(-) mac80211 cfg80211 rfkill > coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr > lpc_ich mfd_core i2c_i801 e1000e ext4 mbcache jbd2 sd_mod crc_t10dif > sr_mod cdrom aesni_intel cryptd aes_x86_64 aes_generic ahci libahci i915 > drm_kms_helper drm i2c_algo_bit i2c_core video dm_mirror dm_region_hash > dm_log dm_mod [last unloaded: scsi_wait_scan] > Pid: 3064, comm: modprobe Not tainted 3.5.0 #1 > Call Trace: > [<ffffffff810535af>] warn_slowpath_common+0x7f/0xc0 > [<ffffffff810536a6>] warn_slowpath_fmt+0x46/0x50 > [<ffffffff812901be>] debug_print_object+0x8e/0xb0 > [<ffffffffa03a09b0>] ? ieee80211_chswitch_timer+0x40/0x40 [mac80211] > [<ffffffff81290a0d>] __debug_check_no_obj_freed+0x10d/0x200 > [<ffffffff81290b1d>] debug_check_no_obj_freed+0x1d/0x30 > [<ffffffff8117a2b0>] kfree+0xc0/0x330 > [<ffffffff810b9083>] ? __lock_release+0x133/0x1a0 > [<ffffffff815555f0>] ? _raw_spin_unlock_irqrestore+0x40/0x80 > [<ffffffff814957c4>] netdev_release+0x44/0x60 > [<ffffffff813704b7>] device_release+0x27/0xa0 > [<ffffffff8127da42>] kobject_cleanup+0x82/0x1b0 > [<ffffffff8127db7d>] kobject_release+0xd/0x10 > [<ffffffff8127d8cc>] kobject_put+0x2c/0x60 > [<ffffffff8147e371>] netdev_run_todo+0x101/0x180 > [<ffffffff8148f5ae>] rtnl_unlock+0xe/0x10 > [<ffffffffa0366178>] ieee80211_unregister_hw+0x58/0x120 [mac80211] > [<ffffffffa040912b>] iwlagn_mac_unregister+0x2b/0x40 [iwlwifi] > [<ffffffffa03fdf59>] iwl_op_mode_dvm_stop+0x49/0xf0 [iwlwifi] > [<ffffffffa041f730>] iwl_drv_stop+0x40/0x60 [iwlwifi] > [<ffffffffa0430a39>] iwl_pci_remove+0x25/0x3c [iwlwifi] > [<ffffffff812aafc2>] pci_device_remove+0x52/0x120 > [<ffffffff813741cc>] __device_release_driver+0x7c/0xe0 > [<ffffffff81374308>] driver_detach+0xd8/0xe0 > [<ffffffff81372f61>] bus_remove_driver+0x91/0x110 > [<ffffffff81374fd2>] driver_unregister+0x62/0xa0 > [<ffffffff812ab2b4>] pci_unregister_driver+0x44/0xa0 > [<ffffffffa041f3d5>] iwl_pci_unregister_driver+0x15/0x20 [iwlwifi] > [<ffffffffa0430a01>] iwl_exit+0x9/0x1c [iwlwifi] > [<ffffffff810c50f1>] sys_delete_module+0x1d1/0x2c0 > [<ffffffff81555855>] ? retint_swapgs+0x13/0x1b > [<ffffffff810e169c>] ? __audit_syscall_entry+0xcc/0x210 > [<ffffffff812896ce>] ? trace_hardirqs_on_thunk+0x3a/0x3f > [<ffffffff8155de69>] system_call_fastpath+0x16/0x1b > ---[ end trace 8070f580fc119b8b ]--- > ------------[ cut here ]------------ > WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0() > Hardware name: SandyBridge Platform > ODEBUG: free active (active state 0) object type: timer_list hint: > ieee80211_sta_bcn_mon_timer+0x0/0x40 [mac80211] > Modules linked in: autofs4 sunrpc cpufreq_ondemand acpi_cpufreq > freq_table mperf ipv6 uinput arc4 sg iwlwifi(-) mac80211 cfg80211 rfkill > coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr > lpc_ich mfd_core i2c_i801 e1000e ext4 mbcache jbd2 sd_mod crc_t10dif > sr_mod cdrom aesni_intel cryptd aes_x86_64 aes_generic ahci libahci i915 > drm_kms_helper drm i2c_algo_bit i2c_core video dm_mirror dm_region_hash > dm_log dm_mod [last unloaded: scsi_wait_scan] > Pid: 3064, comm: modprobe Tainted: G W 3.5.0 #1 > Call Trace: > [<ffffffff810535af>] warn_slowpath_common+0x7f/0xc0 > [<ffffffff810536a6>] warn_slowpath_fmt+0x46/0x50 > [<ffffffff812901be>] debug_print_object+0x8e/0xb0 > [<ffffffffa03a09f0>] ? ieee80211_sta_conn_mon_timer+0x40/0x40 > [mac80211] > [<ffffffff81290a0d>] __debug_check_no_obj_freed+0x10d/0x200 > [<ffffffff81290b1d>] debug_check_no_obj_freed+0x1d/0x30 > [<ffffffff8117a2b0>] kfree+0xc0/0x330 > [<ffffffff810b9083>] ? __lock_release+0x133/0x1a0 > [<ffffffff815555f0>] ? _raw_spin_unlock_irqrestore+0x40/0x80 > [<ffffffff814957c4>] netdev_release+0x44/0x60 > [<ffffffff813704b7>] device_release+0x27/0xa0 > [<ffffffff8127da42>] kobject_cleanup+0x82/0x1b0 > [<ffffffff8127db7d>] kobject_release+0xd/0x10 > [<ffffffff8127d8cc>] kobject_put+0x2c/0x60 > [<ffffffff8147e371>] netdev_run_todo+0x101/0x180 > [<ffffffff8148f5ae>] rtnl_unlock+0xe/0x10 > [<ffffffffa0366178>] ieee80211_unregister_hw+0x58/0x120 [mac80211] > [<ffffffffa040912b>] iwlagn_mac_unregister+0x2b/0x40 [iwlwifi] > [<ffffffffa03fdf59>] iwl_op_mode_dvm_stop+0x49/0xf0 [iwlwifi] > [<ffffffffa041f730>] iwl_drv_stop+0x40/0x60 [iwlwifi] > [<ffffffffa0430a39>] iwl_pci_remove+0x25/0x3c [iwlwifi] > [<ffffffff812aafc2>] pci_device_remove+0x52/0x120 > [<ffffffff813741cc>] __device_release_driver+0x7c/0xe0 > [<ffffffff81374308>] driver_detach+0xd8/0xe0 > [<ffffffff81372f61>] bus_remove_driver+0x91/0x110 > [<ffffffff81374fd2>] driver_unregister+0x62/0xa0 > [<ffffffff812ab2b4>] pci_unregister_driver+0x44/0xa0 > [<ffffffffa041f3d5>] iwl_pci_unregister_driver+0x15/0x20 [iwlwifi] > [<ffffffffa0430a01>] iwl_exit+0x9/0x1c [iwlwifi] > [<ffffffff810c50f1>] sys_delete_module+0x1d1/0x2c0 > [<ffffffff81555855>] ? retint_swapgs+0x13/0x1b > [<ffffffff810e169c>] ? __audit_syscall_entry+0xcc/0x210 > [<ffffffff812896ce>] ? trace_hardirqs_on_thunk+0x3a/0x3f > [<ffffffff8155de69>] system_call_fastpath+0x16/0x1b > ---[ end trace 8070f580fc119b8c ]--- > Bridge firewalling registered > Hi! I was finally able to compile a relocatable kernel: here's what I got, after a crash on iwlegacy module removal: # crash vmcore /usr/lib/debug/lib/modules/`uname -r`/vmlinux crash 6.0.8-1.fc18 [note, I'm on FC17 but had to install FC18's crash to workaround a log structure change in 3.5 kernel] (...) This GDB was configured as "i686-pc-linux-gnu"... ============ CRASH 1 ============ KERNEL: /usr/lib/debug/lib/modules/3.5.4-2.pedro.fc17.i686.PAE/vmlinux DUMPFILE: vmcore [PARTIAL DUMP] CPUS: 2 DATE: Tue Oct 9 09:17:35 2012 UPTIME: 00:12:47 LOAD AVERAGE: 0.50, 0.62, 0.60 TASKS: 322 NODENAME: s2 RELEASE: 3.5.4-2.pedro.fc17.i686.PAE VERSION: #1 SMP Mon Oct 8 23:15:44 WEST 2012 MACHINE: i686 (1496 Mhz) MEMORY: 2 GB PANIC: "Oops: 0000 [#1] SMP " (check log for details) PID: 0 COMMAND: "swapper/1" TASK: f4104240 (1 of 2) [THREAD_INFO: f4146000] CPU: 1 STATE: TASK_RUNNING (PANIC) crash> bt PID: 0 TASK: f4104240 CPU: 1 COMMAND: "swapper/1" #0 [f4147db4] crash_kexec at c04a7d59 #1 [f4147e04] timerqueue_add at c0675503 #2 [f4147e14] ktime_get at c04921ee #3 [f4147e30] bad_area_nosemaphore at c0958328 #4 [f4147e3c] do_page_fault at c0964c25 #5 [f4147eb8] error_code (via page_fault) at c0961eb1 EAX: 6b6b6b6b EBX: 00072420 ECX: 00000001 EDX: f4178930 EBP: f4147f30 DS: 007b ESI: 00000024 ES: 007b EDI: 00072420 GS: 00e0 CS: 0060 EIP: c0457993 ERR: ffffffff EFLAGS: 00010003 #6 [f4147eec] get_next_timer_interrupt at c0457993 #7 [f4147f34] tick_nohz_stop_sched_tick.isra.11 at c049a19a #8 [f4147f78] tick_nohz_idle_enter at c049a661 #9 [f4147f80] cpu_idle at c04195da ============ CRASH 2 ============ KERNEL: /usr/lib/debug/lib/modules/3.5.4-2.pedro.fc17.i686.PAE/vmlinux DUMPFILE: vmcore CPUS: 2 DATE: Tue Oct 9 09:29:35 2012 UPTIME: 00:10:22 LOAD AVERAGE: 0.30, 0.78, 0.67 TASKS: 323 NODENAME: s2 RELEASE: 3.5.4-2.pedro.fc17.i686.PAE VERSION: #1 SMP Mon Oct 8 23:15:44 WEST 2012 MACHINE: i686 (1496 Mhz) MEMORY: 2 GB PANIC: "kernel BUG at kernel/timer.c:1091!" PID: 6563 COMMAND: "rpm" <-- ? TASK: eaa5dcc0 [THREAD_INFO: f414a000] CPU: 0 STATE: TASK_RUNNING (PANIC) crash> bt PID: 6563 TASK: eaa5dcc0 CPU: 0 COMMAND: "rpm" bt: cannot resolve stack trace: #0 [f414bd58] __schedule at c095fba6 #1 [f414bdd4] sched_clock_local at c047a56d bt: text symbols on stack: [f414bd5c] kmap_atomic_prot at c0441244 [f414bd70] __kunmap_atomic at c04410dd [f414bd80] get_page_from_freelist at c0504e40 [f414bdcc] sched_clock at c0417a28 [f414bdd4] sched_clock_local at c047a572 [f414be28] update_curr at c047cdb2 [f414be60] clear_nohz_tick_stopped.part.37 at c0958f63 [f414be6c] trigger_load_balance at c047ff73 [f414be88] scheduler_tick at c04774e5 [f414beac] timerqueue_add at c0675508 [f414bec0] ktime_get at c04921f0 [f414bed4] lapic_next_event at c042f75b [f414bedc] clockevents_program_event at c049877d [f414bef4] tick_program_event at c0499a79 [f414bf04] hrtimer_interrupt at c046bcc8 [f414bf54] irq_exit at c045001d [f414bf5c] smp_apic_timer_interrupt at c042fdbe [f414bf74] apic_timer_interrupt at c0961c85 [f414bfa8] sysenter_past_esp at c0968322 bt: possible exception frame: USER-MODE EXCEPTION FRAME AT f414bfb4: EAX: 0000002d EBX: 09fba000 ECX: 45a4bff4 EDX: 09fba000 DS: 007b ESI: 09f99000 ES: 007b EDI: 09fba000 SS: 007b ESP: bff95804 EBP: bff95804 GS: 0033 CS: 0073 EIP: b7720424 ERR: 0000002d EFLAGS: 00000202 So, I'm guessing this means it is related to what you found on iwlwifi (even if I'm on iwlegacy)? The crash kernel crashed again but I can try to add a script to try to recover dmesg -- I believe slub_debug caught something as well... -- Pedro ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: unloading WiFi modules is usually triggering kernel crash 2012-10-09 9:14 ` Pedro Francisco @ 2012-10-12 12:13 ` Stanislaw Gruszka 2012-10-15 11:03 ` Johannes Berg 2012-10-15 15:48 ` Pedro Francisco 0 siblings, 2 replies; 10+ messages in thread From: Stanislaw Gruszka @ 2012-10-12 12:13 UTC (permalink / raw) To: Pedro Francisco; +Cc: ML linux-wireless, Johannes Berg On Tue, Oct 09, 2012 at 10:14:40AM +0100, Pedro Francisco wrote: > So, I'm guessing this means it is related to what you found on iwlwifi > (even if I'm on iwlegacy)? Yes, this seems to be cfg80211 problem. I think crash happen because cfg80211 is in disassociate state (i.e. has wdev->current_bss NULL) and erroneously mac80211 stays in associate state. So while we unload module cfg80211_mlme_down() we do not call ieee80211_deauth(). I think this state mishmash happens because wrong behaviour on __cfg80211_mlme_deauth(). Below patch try to correct that. Can you check if it prevent a crash? On my environment I can not reproduce this problem reliably. Thanks Stanislaw diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index ab78b53..9b99b60 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -1218,6 +1218,7 @@ struct cfg80211_deauth_request { const u8 *ie; size_t ie_len; u16 reason_code; + bool local_state_change; }; /** diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index e714ed8..e510a33 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -3549,6 +3549,7 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata, { struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; u8 frame_buf[IEEE80211_DEAUTH_FRAME_LEN]; + bool tx = !req->local_state_change; mutex_lock(&ifmgd->mtx); @@ -3565,12 +3566,12 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata, if (ifmgd->associated && ether_addr_equal(ifmgd->associated->bssid, req->bssid)) { ieee80211_set_disassoc(sdata, IEEE80211_STYPE_DEAUTH, - req->reason_code, true, frame_buf); + req->reason_code, tx, frame_buf); } else { drv_mgd_prepare_tx(sdata->local, sdata); ieee80211_send_deauth_disassoc(sdata, req->bssid, IEEE80211_STYPE_DEAUTH, - req->reason_code, true, + req->reason_code, tx, frame_buf); } diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c index 3df195a..4954010 100644 --- a/net/wireless/mlme.c +++ b/net/wireless/mlme.c @@ -457,21 +457,11 @@ int __cfg80211_mlme_deauth(struct cfg80211_registered_device *rdev, .reason_code = reason, .ie = ie, .ie_len = ie_len, + .local_state_change = local_state_change, }; ASSERT_WDEV_LOCK(wdev); - if (local_state_change) { - if (wdev->current_bss && - ether_addr_equal(wdev->current_bss->pub.bssid, bssid)) { - cfg80211_unhold_bss(wdev->current_bss); - cfg80211_put_bss(&wdev->current_bss->pub); - wdev->current_bss = NULL; - } - - return 0; - } - return rdev->ops->deauth(&rdev->wiphy, dev, &req); } ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: unloading WiFi modules is usually triggering kernel crash 2012-10-12 12:13 ` Stanislaw Gruszka @ 2012-10-15 11:03 ` Johannes Berg 2012-10-15 15:48 ` Pedro Francisco 1 sibling, 0 replies; 10+ messages in thread From: Johannes Berg @ 2012-10-15 11:03 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: Pedro Francisco, ML linux-wireless On Fri, 2012-10-12 at 14:13 +0200, Stanislaw Gruszka wrote: > On Tue, Oct 09, 2012 at 10:14:40AM +0100, Pedro Francisco wrote: > > So, I'm guessing this means it is related to what you found on iwlwifi > > (even if I'm on iwlegacy)? > > Yes, this seems to be cfg80211 problem. I think crash happen because > cfg80211 is in disassociate state (i.e. has wdev->current_bss NULL) and > erroneously mac80211 stays in associate state. So while we unload > module cfg80211_mlme_down() we do not call ieee80211_deauth(). > > I think this state mishmash happens because wrong behaviour on > __cfg80211_mlme_deauth(). Below patch try to correct that. > Can you check if it prevent a crash? On my environment I can > not reproduce this problem reliably. Ugh, yeah, what was I thinking with the code below ... ?? > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h > index ab78b53..9b99b60 100644 > --- a/include/net/cfg80211.h > +++ b/include/net/cfg80211.h > @@ -1218,6 +1218,7 @@ struct cfg80211_deauth_request { > const u8 *ie; > size_t ie_len; > u16 reason_code; > + bool local_state_change; > }; > > /** > diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c > index e714ed8..e510a33 100644 > --- a/net/mac80211/mlme.c > +++ b/net/mac80211/mlme.c > @@ -3549,6 +3549,7 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata, > { > struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; > u8 frame_buf[IEEE80211_DEAUTH_FRAME_LEN]; > + bool tx = !req->local_state_change; > > mutex_lock(&ifmgd->mtx); > > @@ -3565,12 +3566,12 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata, > if (ifmgd->associated && > ether_addr_equal(ifmgd->associated->bssid, req->bssid)) { > ieee80211_set_disassoc(sdata, IEEE80211_STYPE_DEAUTH, > - req->reason_code, true, frame_buf); > + req->reason_code, tx, frame_buf); > } else { > drv_mgd_prepare_tx(sdata->local, sdata); > ieee80211_send_deauth_disassoc(sdata, req->bssid, > IEEE80211_STYPE_DEAUTH, > - req->reason_code, true, > + req->reason_code, tx, > frame_buf); > } > > diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c > index 3df195a..4954010 100644 > --- a/net/wireless/mlme.c > +++ b/net/wireless/mlme.c > @@ -457,21 +457,11 @@ int __cfg80211_mlme_deauth(struct cfg80211_registered_device *rdev, > .reason_code = reason, > .ie = ie, > .ie_len = ie_len, > + .local_state_change = local_state_change, > }; > > ASSERT_WDEV_LOCK(wdev); > > - if (local_state_change) { > - if (wdev->current_bss && > - ether_addr_equal(wdev->current_bss->pub.bssid, bssid)) { > - cfg80211_unhold_bss(wdev->current_bss); > - cfg80211_put_bss(&wdev->current_bss->pub); > - wdev->current_bss = NULL; > - } > - > - return 0; > - } > - This looks fine to me. Probably needs Cc: stable? Then again, maybe if the deauth request is for a BSS that *isn't* the current BSS we should "swallow" it in cfg80211? IOW, something like if (local_state_change && (!wdev->current_bss || !ether_addr_equal(...)) return 0; since neither mac80211 nor cfg80211 track authentication... Doesn't matter much though. johannes ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: unloading WiFi modules is usually triggering kernel crash 2012-10-12 12:13 ` Stanislaw Gruszka 2012-10-15 11:03 ` Johannes Berg @ 2012-10-15 15:48 ` Pedro Francisco 1 sibling, 0 replies; 10+ messages in thread From: Pedro Francisco @ 2012-10-15 15:48 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: ML linux-wireless, Johannes Berg [-- Attachment #1: Type: text/plain, Size: 3578 bytes --] On Fri, Oct 12, 2012 at 1:13 PM, Stanislaw Gruszka <sgruszka@redhat.com> wrote: > On Tue, Oct 09, 2012 at 10:14:40AM +0100, Pedro Francisco wrote: >> So, I'm guessing this means it is related to what you found on iwlwifi >> (even if I'm on iwlegacy)? > > Yes, this seems to be cfg80211 problem. I think crash happen because > cfg80211 is in disassociate state (i.e. has wdev->current_bss NULL) and > erroneously mac80211 stays in associate state. So while we unload > module cfg80211_mlme_down() we do not call ieee80211_deauth(). > > I think this state mishmash happens because wrong behaviour on > __cfg80211_mlme_deauth(). Below patch try to correct that. > Can you check if it prevent a crash? On my environment I can > not reproduce this problem reliably. > > Thanks > Stanislaw > > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h > index ab78b53..9b99b60 100644 > --- a/include/net/cfg80211.h > +++ b/include/net/cfg80211.h > @@ -1218,6 +1218,7 @@ struct cfg80211_deauth_request { > const u8 *ie; > size_t ie_len; > u16 reason_code; > + bool local_state_change; > }; > > /** > diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c > index e714ed8..e510a33 100644 > --- a/net/mac80211/mlme.c > +++ b/net/mac80211/mlme.c > @@ -3549,6 +3549,7 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata, > { > struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; > u8 frame_buf[IEEE80211_DEAUTH_FRAME_LEN]; > + bool tx = !req->local_state_change; > > mutex_lock(&ifmgd->mtx); > > @@ -3565,12 +3566,12 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata, > if (ifmgd->associated && > ether_addr_equal(ifmgd->associated->bssid, req->bssid)) { > ieee80211_set_disassoc(sdata, IEEE80211_STYPE_DEAUTH, > - req->reason_code, true, frame_buf); > + req->reason_code, tx, frame_buf); > } else { > drv_mgd_prepare_tx(sdata->local, sdata); > ieee80211_send_deauth_disassoc(sdata, req->bssid, > IEEE80211_STYPE_DEAUTH, > - req->reason_code, true, > + req->reason_code, tx, > frame_buf); > } > > diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c > index 3df195a..4954010 100644 > --- a/net/wireless/mlme.c > +++ b/net/wireless/mlme.c > @@ -457,21 +457,11 @@ int __cfg80211_mlme_deauth(struct cfg80211_registered_device *rdev, > .reason_code = reason, > .ie = ie, > .ie_len = ie_len, > + .local_state_change = local_state_change, > }; > > ASSERT_WDEV_LOCK(wdev); > > - if (local_state_change) { > - if (wdev->current_bss && > - ether_addr_equal(wdev->current_bss->pub.bssid, bssid)) { > - cfg80211_unhold_bss(wdev->current_bss); > - cfg80211_put_bss(&wdev->current_bss->pub); > - wdev->current_bss = NULL; > - } > - > - return 0; > - } > - > return rdev->ops->deauth(&rdev->wiphy, dev, &req); > } > I've been testing the patch since this morning (GMT), I can't reproduce any of the issues I referred on this thread (had to adapt the patch slightly, though). Seems to be fixed! Thank you for your help! -- Pedro Francisco [-- Attachment #2: mlme-timers-fedora-3.6.1-fc17-kernel.patch --] [-- Type: application/octet-stream, Size: 1921 bytes --] diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 3d254e1..f10553c 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -1217,6 +1217,7 @@ struct cfg80211_deauth_request { const u8 *ie; size_t ie_len; u16 reason_code; + bool local_state_change; }; /** diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index f76b833..da3f5e4 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -3457,6 +3457,7 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata, { struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; u8 frame_buf[DEAUTH_DISASSOC_LEN]; + bool tx = !req->local_state_change; mutex_lock(&ifmgd->mtx); @@ -3473,11 +3474,11 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata, if (ifmgd->associated && ether_addr_equal(ifmgd->associated->bssid, req->bssid)) ieee80211_set_disassoc(sdata, IEEE80211_STYPE_DEAUTH, - req->reason_code, true, frame_buf); + req->reason_code, tx, frame_buf); else ieee80211_send_deauth_disassoc(sdata, req->bssid, IEEE80211_STYPE_DEAUTH, - req->reason_code, true, + req->reason_code, tx, frame_buf); mutex_unlock(&ifmgd->mtx); diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c index 1cdb1d5..0877efb 100644 --- a/net/wireless/mlme.c +++ b/net/wireless/mlme.c @@ -457,21 +457,11 @@ int __cfg80211_mlme_deauth(struct cfg80211_registered_device *rdev, .reason_code = reason, .ie = ie, .ie_len = ie_len, + .local_state_change = local_state_change, }; ASSERT_WDEV_LOCK(wdev); - if (local_state_change) { - if (wdev->current_bss && - ether_addr_equal(wdev->current_bss->pub.bssid, bssid)) { - cfg80211_unhold_bss(wdev->current_bss); - cfg80211_put_bss(&wdev->current_bss->pub); - wdev->current_bss = NULL; - } - - return 0; - } - return rdev->ops->deauth(&rdev->wiphy, dev, &req); } ^ permalink raw reply related [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-10-15 15:49 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-07-31 12:54 unloading WiFi modules is usually triggering kernel crash Pedro Francisco 2012-07-31 13:13 ` John W. Linville 2012-08-07 10:22 ` Stanislaw Gruszka 2012-08-30 15:58 ` Pedro Francisco 2012-09-26 12:47 ` Pedro Francisco 2012-10-03 14:30 ` Stanislaw Gruszka 2012-10-09 9:14 ` Pedro Francisco 2012-10-12 12:13 ` Stanislaw Gruszka 2012-10-15 11:03 ` Johannes Berg 2012-10-15 15:48 ` Pedro Francisco
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.
