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 : [email protected])
silex technology,Inc.
Software Engineering Division
Phone:+81-774-98-3877 FAX:+81-774-98-3678
==================================================
Dear John,
Thanks for your comment.
I also tried to duplicate this on x86 environment, but I've never seen
this yet. So this might perhaps have somthing to do with an
ARM-specific implementation in the kernel.
> All
Have you ever experienced something like a crash like this on ARM-based
platform when you use AR9271?
Best Regards,
Takashi Kawamoto
On Wed, 16 Feb 2011 09:52:01 -0500
"John W. Linville" <[email protected]> wrote:
> On Wed, Feb 16, 2011 at 02:17:07PM +0900, Takashi Kawamoto 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)
> > =======================================================================
>
> My guess would be that somehow you are leaking hif_dev->tx.tx_lock,
> and then hanging when trying to retake it in hif_usb_send_tx.
> Unfortunately, it is not obvious to me how that might happen...
>
> > 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 : [email protected])
> > 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 [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> --
> John W. Linville Someday the world will need a hero, and you
> [email protected] might be all we have. Be ready.
==================================================
Takashi Kawamoto (E-Mail : [email protected])
silex technology,Inc.
Software Engineering Division
Phone:+81-774-98-3877 FAX:+81-774-98-3678
==================================================
John W. Linville wrote:
> My guess would be that somehow you are leaking hif_dev->tx.tx_lock,
> and then hanging when trying to retake it in hif_usb_send_tx.
> Unfortunately, it is not obvious to me how that might happen...
This seems to happen only on the specified ARM platform.
We haven't had a report of such a bug on x86 till now.
Not sure how this lockup could happen, though.
Sujith
Dear Stanislaw,
Thank you.
On Thu, 17 Feb 2011 13:23:26 +0100
Stanislaw Gruszka <[email protected]> wrote:
> On Wed, Feb 16, 2011 at 09:52:01AM -0500, John W. Linville wrote:
> > On Wed, Feb 16, 2011 at 02:17:07PM +0900, Takashi Kawamoto wrote:
> [snip]
> > My guess would be that somehow you are leaking hif_dev->tx.tx_lock,
> > and then hanging when trying to retake it in hif_usb_send_tx.
> > Unfortunately, it is not obvious to me how that might happen...
> Perhaps CONFIG_LOCKDEP could give some more info.
I see. I'll try it.
>
> > > CPU : ARM11MP
> > > Kernel : 2.6.33 (SMP enabled)
> What about newer kernels .35 , .37, .38-rcX ?
I've not tried to use those.
>
> > > (2) When multi processor mode is enabled
> > > When SMP option of the kernel is disabled (CONFIG_SMP=m), this
> > > panic doesn't occur.
> For CONFIG_PREEMPT=n and CONFIG_SMP=n spin locks are compiled out from
> kernel, they are simply not needed.
The same goes on CONFIG_PREEMPT=n and CONFIG_SMP=y ?
I want to avoid this crash with SMP enabled.
Best Regards,
Takashi Kawamoto
>
> Stanislaw
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
==================================================
Takashi Kawamoto (E-Mail : [email protected])
silex technology,Inc.
Software Engineering Division
Phone:+81-774-98-3877 FAX:+81-774-98-3678
==================================================
On Wed, Feb 16, 2011 at 09:52:01AM -0500, John W. Linville wrote:
> On Wed, Feb 16, 2011 at 02:17:07PM +0900, Takashi Kawamoto wrote:
[snip]
> My guess would be that somehow you are leaking hif_dev->tx.tx_lock,
> and then hanging when trying to retake it in hif_usb_send_tx.
> Unfortunately, it is not obvious to me how that might happen...
Perhaps CONFIG_LOCKDEP could give some more info.
> > CPU : ARM11MP
> > Kernel : 2.6.33 (SMP enabled)
What about newer kernels .35 , .37, .38-rcX ?
> > (2) When multi processor mode is enabled
> > When SMP option of the kernel is disabled (CONFIG_SMP=m), this
> > panic doesn't occur.
For CONFIG_PREEMPT=n and CONFIG_SMP=n spin locks are compiled out from
kernel, they are simply not needed.
Stanislaw
On Wed, Feb 16, 2011 at 02:17:07PM +0900, Takashi Kawamoto 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)
> =======================================================================
My guess would be that somehow you are leaking hif_dev->tx.tx_lock,
and then hanging when trying to retake it in hif_usb_send_tx.
Unfortunately, it is not obvious to me how that might happen...
> 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 : [email protected])
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
Hi
On Thu, Feb 17, 2011 at 09:53:18PM +0900, Takashi Kawamoto wrote:
> > What about newer kernels .35 , .37, .38-rcX ?
>
> I've not tried to use those.
I think you should try at least .37 to see if bug is not
fixed there by chance. If it is, finding fix for .33
would be easier.
> > > > (2) When multi processor mode is enabled
> > > > When SMP option of the kernel is disabled (CONFIG_SMP=m), this
> > > > panic doesn't occur.
> > For CONFIG_PREEMPT=n and CONFIG_SMP=n spin locks are compiled out from
> > kernel, they are simply not needed.
>
> The same goes on CONFIG_PREEMPT=n and CONFIG_SMP=y ?
No, spin locks are wiped out only with both disabled.
Cheers
Stanislaw
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 <[email protected]> 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 : [email protected])
> silex technology,Inc.
> Software Engineering Division
> Phone:+81-774-98-3877 FAX:+81-774-98-3678
> ==================================================
==================================================
Takashi Kawamoto (E-Mail : [email protected])
silex technology,Inc.
Software Engineering Division
Phone:+81-774-98-3877 FAX:+81-774-98-3678
==================================================