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 [off-list ref] 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@silex.jp)
 silex technology,Inc. 
 Software Engineering Division
 Phone:+81-774-98-3877 FAX:+81-774-98-3678
==================================================

==================================================
 Takashi Kawamoto (E-Mail : tkawamoto@silex.jp)
 silex technology,Inc. 
 Software Engineering Division
 Phone:+81-774-98-3877 FAX:+81-774-98-3678
==================================================