Hello, I've got a problem where a single device (HP Pavilion Laptop running AR9285 bgn WiFi card) is causing a stack-trace/kernel panic on OpenWRT based router (WD MyNet N750). This happens just when the laptop connects to the WiFi network (which is running using "option noscan 1"). Up until this point, all devices connected to the router work without any problem. As soon as *this* laptop connects, router switches operation to 20MHz mode on the TX Leg. Up until r41021, openwrt builds did not exhibit such behavior. The router maintained a 40MHz connection to all clients. Just before the stack-trace, the system log also indicates that the device switched from 40MHz to 20MHz mode of operation.
For me the culprit is any build that includes the latest *hostapd* changes in r41022 and higher. However, r41022 broke the build (fixed in r41023). Consequently, every build upwards of r41023 result in the following stack trace. [12340.170000] ------------[ cut here ]------------ [12340.180000] WARNING: at /home/chirag/bb/mynet/build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2014-05-22/net/mac80211/chan.c:535 ieee80211_recalc_chanctx_min_def+0x4f8/0x6c4 [mac80211]() [12340.200000] Modules linked in: ath9k ath9k_common pppoe ppp_async iptable_nat ath9k_hw ath pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211 ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT ums_usbat ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle iptable_filter ipt_REJECT ip_tables crc_ccitt compat fuse sg ledtrig_usbdev ip6t_REJECT ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 vfat fat ntfs nls_utf8 nls_iso8859_1 nls_cp850 nls_cp437 ipv6 arc4 crypto_blkcipher usb_storage uhci_hcd ohci_hcd ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 crc16 jbd2 mbcache usbcore nls_base usb_common crypto_hash [12340.290000] CPU: 0 PID: 2200 Comm: hostapd Not tainted 3.10.49 #1 [12340.290000] Stack : 00000000 00000000 00000000 00000000 80362eba 00000035 86b4e758 873f9274 [12340.290000] 802c0c68 8030f21b 00000898 80362664 86b4e758 873f9274 86a33b88 0000002c [12340.290000] 00000008 80079040 00000003 80076ac0 872cbdd0 873f9274 802c2528 86a33a7c [12340.290000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [12340.290000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 86a33a08 [12340.290000] ... [12340.330000] Call Trace: [12340.330000] [<8006e294>] show_stack+0x48/0x70I [12340.340000] [<80076bbc>] warn_slowpath_common+0x78/0xa8 [12340.340000] [<80076c74>] warn_slowpath_null+0x18/0x24 [12340.350000] [<872ab464>] ieee80211_recalc_chanctx_min_def+0x4f8/0x6c4 [mac80211] [12340.350000] [12340.360000] ---[ end trace 5bded13efd434a80 ]--- Syslog shows the same thing, except the following line appears just before the stack-trace: daemon.info hostapd: wlan0: STA 4c:xx:xx:xx:xx:xx IEEE 802.11: Switching to 20 MHz operation Here's what my WiFi config looks like: config wifi-device radio0 option type mac80211 option hwmode 11g option path 'platform/ar934x_wmac' option channel 4 option htmode HT40 option noscan 1 option country US config wifi-iface option device radio0 option network lan option wds 1 option mode ap option ssid OPENWRT2G option encryption psk2 option key blahblahblah config wifi-device radio1 option type mac80211 option hwmode 11a option path 'pci0000:00/0000:00:00.0' option channel 149 option htmode HT40 option noscan 1 option country US config wifi-iface option device radio1 option network lan option wds 1 option mode ap option ssid OPENWRT5G option encryption psk2 option key blahblahblah Between r41021 and r41023, there seem to be only hostapd related changes. mac80211 is the same version. I'm no expert, but I would like to help getting to the bottom of this issue. Would a tcpdump be helpful? Most recent build r41797 also exhibits this behavior. I've also set this up as a bug against BB on dev.openwrt.org as ticket #17253 <https://dev.openwrt.org/ticket/17253>. regards, Chirag
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
