Created attachment 565954 [details] dmesg output of the kernel trace Description of problem: When the RTL8192CE wireless adapter is managed by hostapd as an Access Point, it randomly drops signal. When restarting the hostapd daemon, a kernel warning is generated, the signal is back, but clients can't associate to the AP. Version-Release number of selected component (if applicable): kernel-debug-3.2.7-1.fc16.x86_64 How reproducible: Random, but once the signal drop happens, it is very likely that a subsequent restart of hostapd will get the AP into a non-working state. Usually I'd have to reboot the computer to use the AP again. Steps to Reproduce: 1. Boot computer, start hostapd (service hostapd start), wait for the signal to suddenly die. 2. service hostapd restart 3. A kernel trace is produced (INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected), see attachment for details. Additional info: In the messages log, I think the following sequence was what happened when the signal died (client MAC address is edited out): Feb 27 12:06:22 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] IEEE 802.11: authenticated Feb 27 12:06:22 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] IEEE 802.11: associated (aid 1) Feb 27 12:06:22 localhost kernel: [ 3089.348270] rtlwifi: &&&&&&&&&del entry 4 Feb 27 12:06:22 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] RADIUS: starting accounting session 4F4AF5BA-00000001 Feb 27 12:06:22 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] WPA: pairwise key handshake completed (RSN) Feb 27 12:06:23 localhost dnsmasq-dhcp[1376]: DHCPREQUEST(wlan0) 10.0.42.235 a0:0b:ba:[redacted] Feb 27 12:06:23 localhost dnsmasq-dhcp[1376]: DHCPACK(wlan0) 10.0.42.235 a0:0b:ba:[redacted] cm-android Feb 27 12:06:27 localhost dnsmasq-dhcp[1376]: DHCPREQUEST(wlan0) 10.0.42.235 a0:0b:ba:[redacted] Feb 27 12:06:27 localhost dnsmasq-dhcp[1376]: DHCPACK(wlan0) 10.0.42.235 a0:0b:ba:[redacted] cm-android Feb 27 12:11:33 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] IEEE 802.11: disassociated due to inactivity Feb 27 12:11:34 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] IEEE 802.11: deauthenticated due to inactivity After the "service hostapd restart" command was issued, systemctl said hostapd had failed and exited with status 1. Immediately after this, the kernel warning occurred (see attachment). After some 13 seconds, the log reported hostapd was up again, and the client tried to associate, producing this: Feb 27 12:33:24 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] IEEE 802.11: authenticated Feb 27 12:33:24 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] IEEE 802.11: associated (aid 1) Feb 27 12:33:27 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] IEEE 802.11: deauthenticated due to local deauth request Feb 27 12:34:22 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] IEEE 802.11: disassociated Feb 27 12:34:23 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] IEEE 802.11: deauthenticated due to inactivity Feb 27 12:34:57 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] IEEE 802.11: disassociated Feb 27 12:34:58 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] IEEE 802.11: deauthenticated due to inactivity Feb 27 12:35:22 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] IEEE 802.11: disassociated Feb 27 12:35:23 localhost hostapd: wlan0: STA a0:0b:ba:[redacted] IEEE 802.11: deauthenticated due to inactivity The dmesg report said that the kernel had been Tainted with flags G and W. This is due to a previous warning message: [ 9.865396] WARNING: at lib/dma-debug.c:930 check_for_stack+0xb3/0xf0() This is not a problem, see Bug 766921. I'm using a debug kernel so the warning is issued on every boot. I'm not sure whether I should send this to kernel or hostapd. I go with kernel because it seems to be related to the hardware driver.
To be (hopefully) more precise, the dmesg trace was produced after the command "service hostapd start" being issued, and before the log message reporting hostapd's launch.
Test with latest hostapd git snapshot and problem persists. I also noticed something new: sometimes after "service hostapd start" it gave messages like this: Feb 27 23:11:41 localhost hostapd[4007]: nl80211: Failed to set interface wlan0 into AP mode Feb 27 23:11:41 localhost hostapd[4007]: nl80211 driver initialization failed. and failed. After that, the interface wlan0 was not listed in the output of "ifconfig". When trying to bring it up using "ifconfig wlan0 up", the same kernel warning and dmesg trace message were seen, again, only with the command-line info changed from hostapd to ifconfig, and pid changed. There was an additional message after the trace: [ 2815.673883] ADDRCONF(NETDEV_UP): wlan0: link is not ready
I did not think that rtl8192ce actually worked as an AP, and I had not tested it. There is a problem with the CE chips that cause them to start ignoring incoming messages. It happens with both the kernel and the vendor drivers. I don't know if it is a driver or firmware problem. Reaktek is investigating, but they have not duplicated the problem yet. I will try the device as an AP and see what happens here.
[mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update.
(In reply to comment #6) > [mass update] > kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. > Please retest with this update. Tested with kernel-3.3.0-4 for a few hours. Still problematic. Here's a description: This time, there's no signal drop seen. But after some time, the wireless NIC stopped sending any packets. Looking at wireshark live capture, you could only see the connected station sending ARP queries to the broadcast, but the access point was not sending anything. After I noticed this, I did a "service hostapd restart". And then, a kernel WARNING is generated, with dmesg backtrace listed below. The client still had good signal indicator but were not able to connect, and no packets were transmitted. (Originally I got mixed up and accidentally posted this reply to Bug 804947. I must now be infamous for spamming rhbz.) dmesg output: [ 9497.776350] ------------[ cut here ]------------ [ 9497.776366] WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0x7a/0xa0() [ 9497.776370] Hardware name: 05794NC [ 9497.776373] Modules linked in: bluetooth act_police cls_basic cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq bridge xt_statistic xt_CT xt_time xt_connlimit xt_realm xt_addrtype iptable_raw xt_comment xt_recent xt_policy ipt_ULOG ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_CLUSTERIP ipt_ah xt_set ip_set nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_TPROXY nf_tproxy_core xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_connmark xt_CLASSIFY xt_AUDIT ipt_LOG iptable_nat nf_nat iptable_mangle nfnetlink fcoe libfcoe libfc 8021q lockd garp stp scsi_transport_fc scsi_tgt llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 ip6table_filter nf_defrag_ipv4 xt_state ip6_tables nf_conntrack snd_hda_codec_hdmi arc4 snd_hda_codec_realtek rtl8192ce rtl8192c_common snd_hda_intel snd_hda_codec rtlwifi rt2800usb rt2800lib uvcvideo crc_ccitt rt2x00usb rt2x00lib intel_ips r8169 thinkpad_acpi videobuf2_core videodev mii mac80211 snd_hwdep iTCO_wdt snd_seq media v4l2_compat_ioctl32 snd_seq_device snd_pcm cfg80211 iTCO_vendor_support i2c_i801 videobuf2_vmalloc uinput serio_raw videobuf2_memops joydev snd_timer snd snd_page_alloc sunrpc soundcore rfkill microcode xts gf128mul dm_crypt ums_realtek usb_storage i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] [ 9497.776597] Pid: 6413, comm: hostapd Not tainted 3.3.0-4.fc16.x86_64 #1 [ 9497.776601] Call Trace: [ 9497.776612] [<ffffffff81057b1f>] warn_slowpath_common+0x7f/0xc0 [ 9497.776633] [<ffffffffa034a099>] ? rtl_pci_reset_trx_ring+0x199/0x230 [rtlwifi] [ 9497.776640] [<ffffffff81057b7a>] warn_slowpath_null+0x1a/0x20 [ 9497.776646] [<ffffffff8105f06a>] local_bh_enable_ip+0x7a/0xa0 [ 9497.776654] [<ffffffff815f3ef6>] _raw_spin_unlock_bh+0x16/0x20 [ 9497.776671] [<ffffffffa03e50de>] destroy_conntrack+0x9e/0x120 [nf_conntrack] [ 9497.776681] [<ffffffff81511847>] nf_conntrack_destroy+0x17/0x20 [ 9497.776689] [<ffffffff814d9c85>] skb_release_head_state+0xe5/0x120 [ 9497.776695] [<ffffffff814d98b6>] __kfree_skb+0x16/0xa0 [ 9497.776700] [<ffffffff814d9a35>] kfree_skb+0x45/0xc0 [ 9497.776717] [<ffffffffa034a099>] rtl_pci_reset_trx_ring+0x199/0x230 [rtlwifi] [ 9497.776734] [<ffffffffa034a155>] rtl_pci_start+0x25/0x1d0 [rtlwifi] [ 9497.776750] [<ffffffffa03440b5>] rtl_op_start+0x55/0x90 [rtlwifi] [ 9497.776785] [<ffffffffa02c4956>] ieee80211_do_open+0x296/0xa10 [mac80211] [ 9497.776794] [<ffffffff815f7ddd>] ? notifier_call_chain+0x4d/0x70 [ 9497.776828] [<ffffffffa02c513d>] ieee80211_open+0x6d/0x80 [mac80211] [ 9497.776836] [<ffffffff814e8b3f>] __dev_open+0x8f/0xe0 [ 9497.776842] [<ffffffff814e8de1>] __dev_change_flags+0xa1/0x180 [ 9497.776847] [<ffffffff814e8f78>] dev_change_flags+0x28/0x70 [ 9497.776856] [<ffffffff8154e99d>] devinet_ioctl+0x61d/0x7b0 [ 9497.776863] [<ffffffff8154ef55>] inet_ioctl+0x75/0x90 [ 9497.776870] [<ffffffff814cdd50>] sock_do_ioctl+0x30/0x70 [ 9497.776876] [<ffffffff814cee09>] sock_ioctl+0x79/0x2f0 [ 9497.776885] [<ffffffff81193498>] do_vfs_ioctl+0x98/0x550 [ 9497.776891] [<ffffffff811939e1>] sys_ioctl+0x91/0xa0 [ 9497.776897] [<ffffffff815fc029>] system_call_fastpath+0x16/0x1b [ 9497.776902] ---[ end trace 22886c442489082d ]---
It also happens for me, but I'm not using my card in hotspot mode, just connecting to D-Link DIR-300 AP which is ~5 meters ahead of me. On my new MSI U180 netbook it suddenly disconnects and does not connects back. Sometimes turning card off & on helps for some time. dmesg: <...> [ 505.953869] wlan0: moving STA b8:a3:86:1b:e4:10 to state 2 [ 505.953884] wlan0: moving STA b8:a3:86:1b:e4:10 to state 1 [ 505.953895] wlan0: moving STA b8:a3:86:1b:e4:10 to state 0 [ 505.956877] cfg80211: Calling CRDA to update world regulatory domain [ 505.966629] cfg80211: World regulatory domain updated: [ 505.966648] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 505.966664] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 505.966678] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [ 505.966691] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [ 505.966704] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 505.966718] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 505.966800] cfg80211: Calling CRDA for country: RU [ 505.973132] cfg80211: Regulatory domain changed to country: RU [ 505.973143] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 505.973150] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 505.973157] cfg80211: (5735000 KHz - 5835000 KHz @ 20000 KHz), (N/A, 3000 mBm) [ 506.978036] wlan0: authenticate with b8:a3:86:1b:e4:10 (try 1) [ 506.979282] wlan0: authenticated [ 506.981395] wlan0: associate with b8:a3:86:1b:e4:10 (try 1) [ 506.983261] wlan0: RX ReassocResp from b8:a3:86:1b:e4:10 (capab=0x411 status=0 aid=2) [ 506.983290] wlan0: associated [ 506.983299] wlan0: moving STA b8:a3:86:1b:e4:10 to state 1 [ 506.983306] wlan0: moving STA b8:a3:86:1b:e4:10 to state 2 [ 506.984747] cfg80211: Calling CRDA for country: RU [ 506.989602] cfg80211: Regulatory domain changed to country: RU [ 506.989611] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 506.989617] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 506.989623] cfg80211: (5735000 KHz - 5835000 KHz @ 20000 KHz), (N/A, 3000 mBm) [ 510.189752] wlan0: moving STA b8:a3:86:1b:e4:10 to state 3 [ 802.135485] wlan0: moving STA b8:a3:86:1b:e4:10 to state 2 [ 802.135495] wlan0: moving STA b8:a3:86:1b:e4:10 to state 1 [ 802.135502] wlan0: moving STA b8:a3:86:1b:e4:10 to state 0 [ 802.215486] cfg80211: Calling CRDA to update world regulatory domain [ 806.409711] cfg80211: World regulatory domain updated: [ 806.409732] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 806.409753] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 806.409770] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [ 806.409788] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [ 806.409805] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 806.409822] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 806.410679] cfg80211: Calling CRDA for country: RU [ 806.420128] cfg80211: Regulatory domain changed to country: RU [ 806.420139] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 806.420148] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm) [ 806.420156] cfg80211: (5735000 KHz - 5835000 KHz @ 20000 KHz), (N/A, 3000 mBm) [ 811.625783] rtl8192c_common:rtl92c_firmware_selfreset(): 8051 reset fail. [ 812.314076] ------------[ cut here ]------------ [ 812.314114] WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0x7a/0xa0() [ 812.314130] Hardware name: U180 [ 812.314139] Modules linked in: ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack microcode snd_hda_codec_realtek arc4 rtl8192ce rtlwifi rtl8192c_common wmi mac80211 snd_hda_intel gma500_gfx snd_hda_codec i2c_algo_bit drm_kms_helper snd_hwdep snd_pcm i2c_i801 cfg80211 snd_page_alloc snd_timer r8169 snd rfkill mii soundcore drm i2c_core iTCO_wdt video iTCO_vendor_support usb_storage [last unloaded: scsi_wait_scan] [ 812.314372] Pid: 721, comm: wpa_supplicant Not tainted 3.3.4-1.fc17.x86_64 #1 [ 812.314386] Call Trace: [ 812.314415] [<ffffffff810568af>] warn_slowpath_common+0x7f/0xc0 [ 812.314462] [<ffffffffa01e750d>] ? rtl_pci_reset_trx_ring+0x19d/0x230 [rtlwifi] [ 812.314489] [<ffffffff8105690a>] warn_slowpath_null+0x1a/0x20 [ 812.314509] [<ffffffff8105d9fa>] local_bh_enable_ip+0x7a/0xa0 [ 812.314526] [<ffffffff815ebbe5>] _raw_spin_unlock_bh+0x15/0x20 [ 812.314556] [<ffffffffa0292c5e>] destroy_conntrack+0x9e/0x120 [nf_conntrack] [ 812.314574] [<ffffffff8150a997>] nf_conntrack_destroy+0x17/0x20 [ 812.314591] [<ffffffff814d2c9b>] skb_release_head_state+0x7b/0x100 [ 812.314606] [<ffffffff814d2986>] __kfree_skb+0x16/0xa0 [ 812.314621] [<ffffffff814d2ac6>] kfree_skb+0x36/0xa0 [ 812.314648] [<ffffffffa01e750d>] rtl_pci_reset_trx_ring+0x19d/0x230 [rtlwifi] [ 812.314676] [<ffffffffa01e408a>] rtl_ps_enable_nic+0x8a/0xf0 [rtlwifi] [ 812.314700] [<ffffffffa0242e0a>] rtl92c_phy_set_rf_power_state+0x5ca/0x8e0 [rtl8192ce] [ 812.314721] [<ffffffff815e957d>] ? mutex_lock+0x1d/0x50 [ 812.314747] [<ffffffffa01e3e17>] rtl_ps_set_rf_state+0x67/0x110 [rtlwifi] [ 812.314772] [<ffffffffa01e3f04>] _rtl_ps_inactive_ps+0x44/0xd0 [rtlwifi] [ 812.314798] [<ffffffffa01e45f3>] rtl_ips_nic_on+0x93/0xc0 [rtlwifi] [ 812.314824] [<ffffffffa01e1438>] rtl_op_config+0x228/0x3d0 [rtlwifi] [ 812.314877] [<ffffffffa0162427>] ieee80211_hw_config+0x107/0x230 [mac80211] [ 812.314935] [<ffffffffa0177b2e>] ieee80211_recalc_idle+0x4e/0x60 [mac80211] [ 812.314989] [<ffffffffa016806b>] __ieee80211_start_scan+0x10b/0x350 [mac80211] [ 812.315042] [<ffffffffa0168d39>] ieee80211_request_scan+0x39/0x60 [mac80211] [ 812.315100] [<ffffffffa0179d1c>] ieee80211_scan+0x6c/0x90 [mac80211] [ 812.315143] [<ffffffffa00fc499>] nl80211_trigger_scan+0x369/0x610 [cfg80211] [ 812.315168] [<ffffffff815092f0>] genl_rcv_msg+0x210/0x290 [ 812.315185] [<ffffffff815090e0>] ? genl_rcv+0x40/0x40 [ 812.315202] [<ffffffff81508ce1>] netlink_rcv_skb+0xa1/0xb0 [ 812.315218] [<ffffffff815090c5>] genl_rcv+0x25/0x40 [ 812.315235] [<ffffffff8150865d>] netlink_unicast+0x19d/0x1f0 [ 812.315252] [<ffffffff8150896d>] netlink_sendmsg+0x2bd/0x330 [ 812.315270] [<ffffffff814c9258>] sock_sendmsg+0xf8/0x130 [ 812.315290] [<ffffffff814ca9aa>] ? move_addr_to_kernel+0x5a/0xc0 [ 812.315306] [<ffffffff814d6616>] ? verify_iovec+0x56/0xd0 [ 812.315322] [<ffffffff814c970e>] __sys_sendmsg+0x41e/0x430 [ 812.315339] [<ffffffff81191d61>] ? core_sys_select+0x2a1/0x350 [ 812.315359] [<ffffffff81169f50>] ? kmem_cache_free+0x20/0x100 [ 812.315376] [<ffffffff8101a669>] ? read_tsc+0x9/0x20 [ 812.315393] [<ffffffff810a38d0>] ? ktime_get_ts+0xb0/0xf0 [ 812.315410] [<ffffffff81191123>] ? poll_select_copy_remaining+0xf3/0x140 [ 812.315427] [<ffffffff814cb959>] sys_sendmsg+0x49/0x90 [ 812.315444] [<ffffffff815f3be9>] system_call_fastpath+0x16/0x1b [ 812.315456] ---[ end trace ccb8eaf4359d1f79 ]--- [ 812.417678] rtl8192ce:_rtl92ce_llt_write():<0-0> Failed to polling write LLT done at address 0! [ 812.417697] rtl8192ce:rtl92ce_hw_init():<0-0> Init MAC failed [ 817.634500] rtl8192c_common:rtl92c_firmware_selfreset(): 8051 reset fail. [ 818.431890] rtl8192ce:_rtl92ce_llt_write():<0-0> Failed to polling write LLT done at address 0! [ 818.431900] rtl8192ce:rtl92ce_hw_init():<0-0> Init MAC failed [ 819.455381] rtl8192c_common:rtl92c_firmware_selfreset(): 8051 reset fail. [ 824.440119] rtl8192ce:_rtl92ce_llt_write():<0-0> Failed to polling write LLT done at address 0! [ 824.440141] rtl8192ce:rtl92ce_hw_init():<0-0> Init MAC failed <...> # lspci | grep -i wifi 01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01) kernel 3.3.4-1.fc17, x86_64 I'm also seeing some other issues with this card (slow speed, does not able to find AP's with low signal, etc), but they are not so annoying. Card works on dual-boot Windows 7 fine. All other devices (android phones with uncknown chiptets, other linux notebooks with ath5k and intel wireless) works fine.
The signal drop was fixed with mainline kernel commit 643c61e119459e9d75, which is being backported to stable. I think it is in 3.3.5. For the Realtek PCI drivers used as APs, there is another patch in commit 673f7786e205c87b5d978c that fixes a problem caused by the DMA mapping of beacon buffers not being freed. That one is also backported to stable.
It seems 643c61e119459e9d75 does not fixes this issue. If I'm not wrong, it should be in 3.4.0.rc4 and here with 3.4.0-0.rc4.git3.1.fc18.x86_64 from rawhide I'm still seeing this issue. I've also noticed conntrack is somehow involved in the warning, and tried to disable firewalld (so iptables modules are not being loaded). Warning is done, but I'm wireless connections still hangs approx. every 2 hours (versus every 30 minutes approx with firewalld on).
Using kernel 3.5-rc3+wireless-testing merging into it, I've got this trace after NIC stopped sending packets and after hostapd restart, so it's obvious that the problem was not fixed with 643c61e119459e9d75 and 673f7786e205c87b5d978c commits. rtlwifi:rtl_cam_get_free_entry():<0-0> -----hwsec_cam_bitmap: 0x0 entry_idx=4 usb 1-6: USB disconnect, device number 21 nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead. rtlwifi: &&&&&&&&&del entry 4 rtlwifi:rtl_cam_get_free_entry():<0-0> -----hwsec_cam_bitmap: 0x0 entry_idx=4 rtlwifi: &&&&&&&&&del entry 4 rtlwifi:rtl_cam_get_free_entry():<0-0> -----hwsec_cam_bitmap: 0x0 entry_idx=4 rtlwifi:rtl_cam_get_free_entry():<0-0> -----hwsec_cam_bitmap: 0x10 entry_idx=5 rtlwifi: &&&&&&&&&del entry 4 rtlwifi: &&&&&&&&&del entry 5 -----------[ cut here ]------------ WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0x60/0x90() Hardware name: P5K SE/EPU Modules linked in: nvidia(PO) aes_i586 aes_generic tun pppoe pppox ppp_generic slhc ipt_REJECT xt_tcpudp ipt_ULOG xt_limit ipv6 xt_hashlimit xt_multiport xt_conntrack iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 iptable_mangle ip_tables x_tables fuse dm_mod nf_conntrack_ftp nf_conntrack lirc_serial(C) lirc_dev snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec coretemp kvm_intel snd_hwdep snd_pcm kvm arc4 snd_page_alloc snd_timer snd rtl8192ce rtlwifi rtl8192c_common mac80211 asus_atk0110 i2c_i801 microcode cfg80211 soundcore agpgart 8139too atl1 8139cp pcspkr hwmon [last unloaded: nvidia] Pid: 7992, comm: hostapd Tainted: P C O 3.5.0-rc2-wl+ #1 Call Trace: [<c102d918>] ? warn_slowpath_common+0x78/0xb0 [<c1033f30>] ? local_bh_enable_ip+0x60/0x90 [<c1033f30>] ? local_bh_enable_ip+0x60/0x90 [<c102d96b>] ? warn_slowpath_null+0x1b/0x20 [<c1033f30>] ? local_bh_enable_ip+0x60/0x90 [<f88cc994>] ? destroy_conntrack+0x74/0xa0 [nf_conntrack] [<c13f7f96>] ? nf_conntrack_destroy+0x16/0x20 [<c13cbbc5>] ? skb_release_head_state+0xa5/0xe0 [<c13cba38>] ? __kfree_skb+0x8/0x90 [<f96e2e4d>] ? rtl_pci_reset_trx_ring+0x19d/0x210 [rtlwifi] [<f96e2ed9>] ? rtl_pci_start+0x19/0x180 [rtlwifi] [<f89090ae>] ? cfg80211_netdev_notifier_call+0x9e/0x540 [cfg80211] [<f96de79d>] ? rtl_op_start+0x5d/0x80 [rtlwifi] [<f965bd90>] ? ieee80211_do_open+0x220/0x7d0 [mac80211] [<c1450f9d>] ? packet_notifier+0x8d/0x190 [<f9659d80>] ? ieee80211_check_concurrent_iface+0x20/0x190 [mac80211] [<c104c911>] ? notifier_call_chain+0x41/0x60 [<c13d8633>] ? __dev_open+0x83/0xe0 [<c13d8590>] ? dev_set_rx_mode+0x20/0x40 [<c13d88b9>] ? __dev_change_flags+0x89/0x170 [<c13d4f6f>] ? dev_get_by_name_rcu+0x4f/0x70 [<c13d8a3b>] ? dev_change_flags+0x1b/0x60 [<c142b87a>] ? devinet_ioctl+0x4ca/0x700 [<c13c2fcf>] ? sock_ioctl+0x6f/0x270 [<c13c2f60>] ? sock_fasync+0x90/0x90 [<c10eb62a>] ? do_vfs_ioctl+0x7a/0x570 [<c10ef346>] ? d_kill+0xa6/0x100 [<c10ef95d>] ? dput+0xad/0x150 [<c10dd8ec>] ? fput+0x11c/0x220 [<c10f541d>] ? mntput_no_expire+0x1d/0x130 [<c10d9d5f>] ? filp_close+0x4f/0x80 [<c10ebb4e>] ? sys_ioctl+0x2e/0x60 [<c148ba98>] ? sysenter_do_call+0x12/0x28 ---[ end trace 272c8fec78a1d2b1 ]--- IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Each time after the network card is no longer receiving and sending packets, in dmesg this message appears rtlwifi: &&&&&&&&&del entry 5
Created attachment 592503 [details] Trial patch for problem Please try this patch. The problem is due to interrupts being disabled when the skb is freed. This trial patch is not the "final" answer as it leaks the skb, but I want to see if any other problems are exposed. If none, I will likely need to launch a work queue to free the skb.
(In reply to comment #12) > Created attachment 592503 [details] > Trial patch for problem > > Please try this patch. The problem is due to interrupts being disabled when > the skb is freed. This trial patch is not the "final" answer as it leaks the > skb, but I want to see if any other problems are exposed. If none, I will > likely need to launch a work queue to free the skb. Warning is gone but again rtlwifi: &&&&&&&&&del entry 5 and no signal after hostapd restart.
Interesting thing, after last comment I reboot computer, and after that wifi is working without any issues uptime 1 day, 22:52. In dmesg I have 7 messages with "rtlwifi: &&&&&&&&&del entry 5" but signal still present.
Those messages are only indicating that CAM (content-addressable memory) has changed. I think maybe the log level should be changed. I will put together a patch that will not leak the skb's and post for further testing.
It's just insane, 4 times for 15 minutes it stops receiving packets. There is clearly something wrong with driver because in windows it works just perfectly. Funny thing, if computer rebooted it works then a couple of minutes or hours but after a poweroff it could be a day or two.
Created attachment 593847 [details] Patch to eliminate warning This patch should fix the problem.
Created attachment 593848 [details] Patch to change CAM delete message This patch is cosmetic and changes the message to be less cryptic. In addition, it will only be printed with a higher level of debugging.
(In reply to comment #17) > Created attachment 593847 [details] > Patch to eliminate warning > > This patch should fix the problem. Problem with warning is solved, but what about a real problem with signal drops?
Thanks for testing. I will push these patches upstream. May I use a "Tested by: Ivan Ivanovich <iivanich>" line in the patch? As for the drops, please try loading the module with the "ips=0" option to disable power saving to see if that makes a difference.
(In reply to comment #20) > Ivan Ivanovich <iivanich>" line i> Thanks for testing. I will push these patches upstream. in the patch? Yes, np. > As for the drops, please try loading the module with the "ips=0" option to > disable power saving to see if that makes a difference. I've tried this before your patch but it makes no difference at all, gonna tried it again just in case.
Unfortunaly, as I expected disabling power saving doesn't help.
(In reply to comment #22) > Unfortunaly, as I expected disabling power saving doesn't help. I disabled wmm and uapsd_advertisement in hostapd.conf and more than a week no signal drops were seen. I'll try to figure out which of those 2 options helped.
WMM/WME is caused signal drops and stops in receiving any packets, withowt wmm all works fine.
I conclude that uapsd is OK, and that the problems were associated with the parameter wmm_enabled. When it worked OK, was it sufficient to set it to zero? In your setup, do you have any clients that are using any video or voice QoS levels? Did you keep the default wmm_ac_XX parameters? Did you set any of the tx_queue_dataX values?
Created attachment 597390 [details] hostapd.conf >When it worked OK, was it sufficient to set it to zero? Yes, with wmm enabled it works only few hours. No matter enabled uapsd or not. >In your setup, do you have any clients that are using any video or voice QoS levels? At the moment I have only two Android smartphones as clients so I don't know they use wmm or not. >Did you keep the default wmm_ac_XX parameters? Did you set any of the tx_queue_dataX values? All values related to the wmm are default. hostapd.conf below
(In reply to comment #26) > At the moment I have only two Android smartphones as clients so I don't know > they use wmm or not. wmm is required if you use 802.11n.
Created attachment 597641 [details] Log the priotity of the messages in the first 300 TX interrupts Ivan: Please run with this patch for wmm enabled and with it disabled. You will need to unload rtl8192ce between the two runs. On my system with rtl8192ce in STA mode, priorities 1, 3, and 6 are used. This output will tell what queues hostapd is using.
Seems there are no difference with or without wmm, it print logs just after rtl8192ce loads and restarting hostapd after that does not show anything new in dmesg. rtlwifi: Ring TX priority 6 rtlwifi: Ring TX priority 1 rtlwifi: Ring TX priority 3
The patch has a static variable that counts the output. Once the limit is reached, rtlwifi has to be unloaded and reloaded to reset the counter. That is why restarting hostapd does not yield any new output. As the same queues are used with and without wmm enabled. the problem seems not to be in the selection of the ring.
Created attachment 598918 [details] Patch 1 of 6 to update driver to 12/30/2011 vendor version
Created attachment 598919 [details] Patch 2 of 6 to update driver to 12/30/2011 vendor version
Created attachment 598920 [details] Patch 3 of 6 to update driver to 12/30/2011 vendor version
Created attachment 598921 [details] Patch 4 of 6 to update driver to 12/30/2011 vendor version
Created attachment 598922 [details] Patch 5 of 6 to update driver to 12/30/2011 vendor version
Created attachment 598924 [details] Patch 6 of 6 to update driver to 12/30/2011 vendor version This series of 6 patches updates the rtlwifi family of drivers to the code in the 12/30/2011 vendor driver. The one exception is rtl8192se - that patch is incomplete. For rtl8192ce, you will only need patches 1-5. Because the headers all list patch X/6, I decided to post all of them even though #6 is not needed here. There are no specific changes in the driver that address this problem; however, there is a change in the locking that might affect AP operation, and not usage as an STA. Please test. Thanks.
Seems these patches caused deadlocks when restarting hostapd, like it was with patch "cfg80211: track monitor interfaces count" in maillists.
(In reply to comment #37) > Seems these patches caused deadlocks when restarting hostapd, like it was > with patch "cfg80211: track monitor interfaces count" in maillists. Sorry it's not patches, its something in wireless-testing, I reverted your patches but it still locks during hostapd restart.
Testing your patches about a week and no problems was found. Are you planning to submit it in 3.6? Because now it fails to patch at Patchset4 in current torvalds/linux.git.
Those patches will be pushed through wireless-testing. The merge period for 3.6 is over. The earliest that these will appear in mainline is 3.7.
Just setting this to POST state so we know there are fixes for this.
# Mass update to all open bugs. Kernel 3.6.2-1.fc16 has just been pushed to updates. This update is a significant rebase from the previous version. Please retest with this kernel, and let us know if your problem has been fixed. In the event that you have upgraded to a newer release and the bug you reported is still present, please change the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. If you are not the original bug reporter and you still experience this bug, please file a new report, as it is possible that you may be seeing a different problem. (Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
With no response, we are closing this bug under the assumption that it is no longer an issue. If you still experience this bug, please feel free to reopen the bug report.