Hi All, As for the below Kernel Panic issue, just enabling kernel preemption option seems to be able to prevent the panic. [before] ----------------------------------------------------------------------- ... CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set ... ----------------------------------------------------------------------- [after] ----------------------------------------------------------------------- ... # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y ... ----------------------------------------------------------------------- I have no idea why this change could be effective... Does anyone have ideas? Best Regards, Takashi Kawamoto On Wed, 16 Feb 2011 14:17:07 +0900 Takashi Kawamoto <tkawamoto@xxxxxxxx> wrote: > 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@xxxxxxxx) > silex technology,Inc. > Software Engineering Division > Phone:+81-774-98-3877 FAX:+81-774-98-3678 > ================================================== ================================================== Takashi Kawamoto (E-Mail : tkawamoto@xxxxxxxx) silex technology,Inc. Software Engineering Division Phone:+81-774-98-3877 FAX:+81-774-98-3678 ================================================== -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
