Red Hat Bugzilla – Bug 810737
Kernel panic when connecting to an an 802.11n AP on channel 157 with an Asus USB-N53 wireless adapter
Last modified: 2012-11-14 10:30:23 EST
Description of problem: When trying to connect to a an 802.11n network on channel 157 (5785 MHz), I get a kernel panic and am unable to connect. But if I use any other channel, I am able to connect to the network. Version-Release number of selected component (if applicable): Asus USB-N53 wireless adapter Fedora 16 system with all updates applied Fedora linux kernel 3.3.1-3 How reproducible: Everytime Steps to Reproduce: 1. Change channel of my wi-fi network on my access point to 157 (5785 MHz) 2. Try to connect to my network Actual results: Kernel panics and I'm unable to connect Expected results: I should be able to connect to a network on channel 157, just like I can with any other channel. Additional info: [ 3586.448281] ------------[ cut here ]------------ [ 3586.448298] WARNING: at drivers/net/wireless/rt2x00/rt2x00config.c:201 rt2x00lib_config+0x28b/0x2c0 [rt2x00lib]() [ 3586.448302] Hardware name: [ 3586.448304] Modules linked in: tcp_lp fuse ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle rfcomm bridge stp llc lockd bnep coretemp adt7475 hwmon_vid arc4 rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib mac80211 cfg80211 joydev snd_hda_codec_hdmi snd_hda_codec_realtek btusb bluetooth rfkill serio_raw microcode i7core_edac edac_core i2c_i801 iTCO_wdt iTCO_vendor_support e1000e snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc vhost_net macvtap macvlan tun virtio_net kvm_intel kvm uinput sunrpc ata_generic pata_acpi mxm_wmi pata_marvell wmi radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan] [ 3586.448382] Pid: 2474, comm: kworker/u:1 Tainted: G W 3.3.1-3.fc16.x86_64 #1 [ 3586.448386] Call Trace: [ 3586.448396] [<ffffffff8105798f>] warn_slowpath_common+0x7f/0xc0 [ 3586.448402] [<ffffffff810579ea>] warn_slowpath_null+0x1a/0x20 [ 3586.448411] [<ffffffffa03bebcb>] rt2x00lib_config+0x28b/0x2c0 [rt2x00lib] [ 3586.448418] [<ffffffffa0372ed4>] ? rt2800usb_stop_queue+0xd4/0xe0 [rt2800usb] [ 3586.448427] [<ffffffffa03be0a8>] rt2x00mac_config+0x48/0x80 [rt2x00lib] [ 3586.448444] [<ffffffffa042c4e7>] ieee80211_hw_config+0x127/0x230 [mac80211] [ 3586.448463] [<ffffffffa043988a>] ieee80211_enable_ht+0x1da/0x400 [mac80211] [ 3586.448481] [<ffffffffa043bcc6>] ieee80211_assoc_success+0x5a6/0x860 [mac80211] [ 3586.448502] [<ffffffffa043c00e>] ieee80211_assoc_done+0x8e/0x430 [mac80211] [ 3586.448510] [<ffffffff814335c1>] ? ehci_urb_enqueue+0xf1/0x1080 [ 3586.448529] [<ffffffffa043e056>] ieee80211_work_work+0x266/0x16d0 [mac80211] [ 3586.448537] [<ffffffffa032c6bb>] ? rt2x00usb_kick_rx_entry+0xcb/0x100 [rt2x00usb] [ 3586.448544] [<ffffffffa032cf17>] ? rt2x00usb_clear_entry+0x27/0x30 [rt2x00usb] [ 3586.448552] [<ffffffffa03bc39f>] ? rt2x00lib_rxdone+0x2af/0x470 [rt2x00lib] [ 3586.448559] [<ffffffffa032c26b>] ? rt2x00usb_work_rxdone+0x7b/0xa0 [rt2x00usb] [ 3586.448578] [<ffffffffa043ddf0>] ? free_work+0x20/0x20 [mac80211] [ 3586.448584] [<ffffffff810744fe>] process_one_work+0x11e/0x470 [ 3586.448590] [<ffffffff8107530f>] worker_thread+0x15f/0x360 [ 3586.448595] [<ffffffff810751b0>] ? manage_workers+0x230/0x230 [ 3586.448601] [<ffffffff81079af3>] kthread+0x93/0xa0 [ 3586.448607] [<ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10 [ 3586.448612] [<ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70 [ 3586.448617] [<ffffffff815fd3a0>] ? gs_change+0x13/0x13 [ 3586.448621] ---[ end trace 5107b9e3c4c88884 ]--- [ 3586.471955] ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready [ 3590.465977] ieee80211 phy0: wlan1: No probe response from AP 10:6f:3f:0c:24:8d after 500ms, disconnecting. [ 3590.494896] wlan1: moving STA 10:6f:3f:0c:24:8d to state 1 [ 3590.494901] wlan1: moving STA 10:6f:3f:0c:24:8d to state 0 [ 3590.495264] cfg80211: Calling CRDA to update world regulatory domain [ 3590.499211] cfg80211: World regulatory domain updated: [ 3590.499217] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 3590.499224] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 3590.499231] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [ 3590.499238] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [ 3590.499244] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 3590.499251] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 3590.499482] cfg80211: Calling CRDA for country: US [ 3590.503365] cfg80211: Regulatory domain changed to country: US [ 3590.503369] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 3590.503374] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) [ 3590.503379] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) [ 3590.503383] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 3590.503387] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 3590.503391] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 3590.503396] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) [ 3593.958269] wlan1: authenticate with 10:6f:3f:0c:24:8d (try 1) [ 3593.959277] wlan1: authenticated [ 3593.963561] wlan1: associate with 10:6f:3f:0c:24:8d (try 1) [ 3593.964728] wlan1: RX ReassocResp from 10:6f:3f:0c:24:8d (capab=0x11 status=0 aid=1) [ 3593.964733] wlan1: associated [ 3593.964737] wlan1: moving STA 10:6f:3f:0c:24:8d to state 1 [ 3593.964740] wlan1: moving STA 10:6f:3f:0c:24:8d to state 2
re-assigned to the kernel
Does the problem can be reproduced with recent kernel ?
First of all this is not "kernel panic" but WARNING, perhaps ABRT call this "kernel panic or kernel crash", but in this case we do not have this kind of problem. Channel 157 is prohibited in Europe, perhaps you are using device dedicated to Europe market. What shows "iw phy" ?
@Nicolas, the problem is still reproducible in Fedora 17 with the 3.3.7-1.fc17.x86_64 kernel. @ Stanislaw, "iw phy" shows the following: [vinu@vinu ~]$ iw phy Wiphy phy0 Band 1: Capabilities: 0x2f2 HT20/HT40 Static SM Power Save RX Greenfield RX HT20 SGI RX HT40 SGI TX STBC RX STBC 2-streams Max AMSDU length: 3839 bytes No DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 2 usec (0x04) HT RX MCS rate indexes supported: 0-15, 32 TX unequal modulation not supported HT TX Max spatial streams: 2 HT TX MCS rate indexes supported may differ Frequencies: * 2412 MHz [1] (20.0 dBm) * 2417 MHz [2] (20.0 dBm) * 2422 MHz [3] (20.0 dBm) * 2427 MHz [4] (20.0 dBm) * 2432 MHz [5] (20.0 dBm) * 2437 MHz [6] (20.0 dBm) * 2442 MHz [7] (20.0 dBm) * 2447 MHz [8] (20.0 dBm) * 2452 MHz [9] (20.0 dBm) * 2457 MHz [10] (20.0 dBm) * 2462 MHz [11] (20.0 dBm) * 2467 MHz [12] (20.0 dBm) * 2472 MHz [13] (20.0 dBm) * 2484 MHz [14] (disabled) Bitrates (non-HT): * 1.0 Mbps * 2.0 Mbps (short preamble supported) * 5.5 Mbps (short preamble supported) * 11.0 Mbps (short preamble supported) * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Band 2: Capabilities: 0x2f2 HT20/HT40 Static SM Power Save RX Greenfield RX HT20 SGI RX HT40 SGI TX STBC RX STBC 2-streams Max AMSDU length: 3839 bytes No DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 2 usec (0x04) HT RX MCS rate indexes supported: 0-15, 32 TX unequal modulation not supported HT TX Max spatial streams: 2 HT TX MCS rate indexes supported may differ Frequencies: * 5180 MHz [36] (20.0 dBm) * 5190 MHz [38] (20.0 dBm) * 5200 MHz [40] (20.0 dBm) * 5220 MHz [44] (20.0 dBm) * 5230 MHz [46] (20.0 dBm) * 5240 MHz [48] (20.0 dBm) * 5260 MHz [52] (20.0 dBm) (radar detection) * 5270 MHz [54] (20.0 dBm) (radar detection) * 5280 MHz [56] (20.0 dBm) (radar detection) * 5300 MHz [60] (20.0 dBm) (radar detection) * 5310 MHz [62] (20.0 dBm) (radar detection) * 5320 MHz [64] (20.0 dBm) (radar detection) * 5500 MHz [100] (disabled) * 5510 MHz [102] (disabled) * 5520 MHz [104] (disabled) * 5540 MHz [108] (disabled) * 5550 MHz [110] (disabled) * 5560 MHz [112] (disabled) * 5580 MHz [116] (disabled) * 5590 MHz [118] (disabled) * 5600 MHz [120] (disabled) * 5620 MHz [124] (disabled) * 5630 MHz [126] (disabled) * 5640 MHz [128] (disabled) * 5660 MHz [132] (disabled) * 5670 MHz [134] (disabled) * 5680 MHz [136] (disabled) * 5700 MHz [140] (disabled) * 5745 MHz [149] (20.0 dBm) * 5755 MHz [151] (20.0 dBm) * 5765 MHz [153] (20.0 dBm) * 5785 MHz [157] (20.0 dBm) * 5795 MHz [159] (20.0 dBm) * 5805 MHz [161] (20.0 dBm) * 5825 MHz [165] (20.0 dBm) * 5835 MHz [167] (disabled) * 5845 MHz [169] (disabled) * 5855 MHz [171] (disabled) * 5865 MHz [173] (disabled) Bitrates (non-HT): * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps max # scan SSIDs: 4 max scan IEs length: 2257 bytes Coverage class: 0 (up to 0m) Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) * CCMP (00-0f-ac:4) Available Antennas: TX 0 RX 0 Supported interface modes: * IBSS * managed * AP * AP/VLAN * WDS * monitor * mesh point software interface modes (can always be added): * AP/VLAN * monitor interface combinations are not supported Supported commands: * new_interface * set_interface * new_key * new_beacon * new_station * new_mpath * set_mesh_params * set_bss * authenticate * associate * deauthenticate * disassociate * join_ibss * join_mesh * remain_on_channel * set_tx_bitrate_mask * action * frame_wait_cancel * set_wiphy_netns * set_channel * set_wds_peer * Unknown command (84) * Unknown command (87) * Unknown command (85) * connect * disconnect Supported TX frame types: * IBSS: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0 * managed: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0 * AP: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0 * AP/VLAN: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0 * mesh point: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0 * P2P-client: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0 * P2P-GO: 0x0000 0x0010 0x0020 0x0030 0x0040 0x0050 0x0060 0x0070 0x0080 0x0090 0x00a0 0x00b0 0x00c0 0x00d0 0x00e0 0x00f0 Supported RX frame types: * IBSS: 0x00d0 * managed: 0x0040 0x00d0 * AP: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0 * AP/VLAN: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0 * mesh point: 0x00b0 0x00c0 0x00d0 * P2P-client: 0x0040 0x00d0 * P2P-GO: 0x0000 0x0020 0x0040 0x00a0 0x00b0 0x00c0 0x00d0 HT Capability overrides: * MCS: ff ff ff ff ff ff ff ff ff ff * maximum A-MSDU length * supported channel width * short GI for 40 MHz * max A-MPDU length exponent * min MPDU start spacing Device supports TX status socket option. Device supports HT-IBSS.
> * 5755 MHz [151] (20.0 dBm) > * 5765 MHz [153] (20.0 dBm) > * 5785 MHz [157] (20.0 dBm) > * 5795 MHz [159] (20.0 dBm) > * 5805 MHz [161] (20.0 dBm) For HT40+/-, we calculate center channel by adding 2 channels (for HT40+) or subdivide by 2 (for HT40-), and we use that center channel for calibration. For channel 157, center HT40+ channel is 159 and center HT40- channel is 155. We do not have 155 defined in our tables, i.e. we can not make calibration for it. I don't know if this is actual a bug. I looked at the tables on rt2x00 driver and vendor driver, both looks the same - there is no 155 channel definition. Gertjan, Ivo, any idea if we should support this channel ? Or if calibration on 157 should work ?
# 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.