Return-path: Received: from mow302.securemx.jp ([210.130.202.52]:53722 "EHLO mow.securemx.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750748Ab1BPFQh (ORCPT ); Wed, 16 Feb 2011 00:16:37 -0500 Date: Wed, 16 Feb 2011 14:17:07 +0900 From: Takashi Kawamoto To: linux-wireless@vger.kernel.org Subject: BUG: AR9271 cause a Kernel Panic on ARM11 SMP environment Cc: Yoshitaka Imura , Yasuo Bato , Yuji Sasaki , Ryou Matsuura Message-Id: <20110216141657.9270.9AD4E5EB@silex.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: linux-wireless-owner@vger.kernel.org List-ID: Dear all, When I make an AR9271 to perform as an iperf client with compat-wireless-2011-01-30, a Kernel Panic occurs. [log] ======================================================================= BUG: spinlock lockup on CPU#1, iperf/552, 9f9aade4 [<80030ca4>] (unwind_backtrace+0x0/0xdc) from [<801835ac>] (do_raw_spin_lock+0x14c/0x168) [<801835ac>] (do_raw_spin_lock+0x14c/0x168) from [<802e47c0>] (_raw_spin_lock_irqsave+0x10/0x18) [<802e47c0>] (_raw_spin_lock_irqsave+0x10/0x18) from [<7f17218c>] (hif_usb_send+0x34/0x26c [ath9k_htc]) [<7f17218c>] (hif_usb_send+0x34/0x26c [ath9k_htc]) from [<7f17153c>] (htc_issue_send+0x64/0x6c [ath9k_htc]) [<7f17153c>] (htc_issue_send+0x64/0x6c [ath9k_htc]) from [<7f171564>] (htc_send+0x20/0x24 [ath9k_htc]) [<7f171564>] (htc_send+0x20/0x24 [ath9k_htc]) from [<7f1746d4>] (ath9k_htc_tx_start+0x23c/0x244 [ath9k_htc]) [<7f1746d4>] (ath9k_htc_tx_start+0x23c/0x244 [ath9k_htc]) from [<7f1751c8>] (ath9k_htc_tx+0x7c/0xcc [ath9k_htc]) [<7f1751c8>] (ath9k_htc_tx+0x7c/0xcc [ath9k_htc]) from [<7f0c50d4>] (__ieee80211_tx+0x124/0x194 [mac80211]) [<7f0c50d4>] (__ieee80211_tx+0x124/0x194 [mac80211]) from [<7f0c51e4>] (ieee80211_tx+0xa0/0x1e0 [mac80211]) [<7f0c51e4>] (ieee80211_tx+0xa0/0x1e0 [mac80211]) from [<7f0c6590>] (ieee80211_subif_start_xmit+0x6c0/0x6f8 [mac80211]) [<7f0c6590>] (ieee80211_subif_start_xmit+0x6c0/0x6f8 [mac80211]) from [<80269220>] (dev_hard_start_xmit+0x1f8/0x2e0) [<80269220>] (dev_hard_start_xmit+0x1f8/0x2e0) from [<8027878c>] (sch_direct_xmit+0x70/0x1c8) [<8027878c>] (sch_direct_xmit+0x70/0x1c8) from [<802696e0>] (dev_queue_xmit+0x290/0x428) [<802696e0>] (dev_queue_xmit+0x290/0x428) from [<80287320>] (ip_finish_output+0x250/0x2a8) [<80287320>] (ip_finish_output+0x250/0x2a8) from [<80285178>] (ip_local_out+0x24/0x28) [<80285178>] (ip_local_out+0x24/0x28) from [<80286cac>] (ip_queue_xmit+0x2f4/0x35c) [<80286cac>] (ip_queue_xmit+0x2f4/0x35c) from [<80299010>] (tcp_transmit_skb+0x74c/0x7b8) [<80299010>] (tcp_transmit_skb+0x74c/0x7b8) from [<8029b5dc>] (tcp_write_xmit+0x860/0x978) [<8029b5dc>] (tcp_write_xmit+0x860/0x978) from [<8029b730>] (tcp_push_one+0x3c/0x48) [<8029b730>] (tcp_push_one+0x3c/0x48) from [<8028f840>] (tcp_sendmsg+0x864/0xaa4) [<8028f840>] (tcp_sendmsg+0x864/0xaa4) from [<80258ecc>] (sock_aio_write+0xe0/0xe8) [<80258ecc>] (sock_aio_write+0xe0/0xe8) from [<800bba20>] (do_sync_write+0x94/0xe0) [<800bba20>] (do_sync_write+0x94/0xe0) from [<800bc460>] (vfs_write+0xc4/0x154) [<800bc460>] (vfs_write+0xc4/0x154) from [<800bc59c>] (sys_write+0x3c/0x68) [<800bc59c>] (sys_write+0x3c/0x68) from [<8002a220>] (ret_fast_syscall+0x0/0x2c) ======================================================================= An environment of AR9271's host is as follows. [Host Environment] ======================================================================= CPU : ARM11MP Kernel : 2.6.33 (SMP enabled) Distribution: Zoran Quatro inferno ======================================================================= As long as I see, this panic happens under the following conditions. (1) When sending a data frame When AR9271 performs as an iperf server, this panic appears less frequently than as a client. (1) When transmission throughput is relatively high For example, this panic never seems to appear when Ping communication is performed. (2) When multi processor mode is enabled When SMP option of the kernel is disabled (CONFIG_SMP=m), this panic doesn't occur. I've not duplicated the same on a x86 environment yet. I suspect that spinlock usage in Tx routines of ath9k/hif_usb.c must have something to do with this panic. Have anyone come across the similar crash as this? Best Regards, Takashi Kawamoto ================================================== Takashi Kawamoto (E-Mail : tkawamoto@silex.jp) silex technology,Inc. Software Engineering Division Phone:+81-774-98-3877 FAX:+81-774-98-3678 ==================================================