Arrived at non-free entry in the non-full queue 2

Live forum: http://rt2x00.serialmonkey.com/viewtopic.php?t=4790

monnier

12-05-2008 20:59:15

I recently upgraded my machine from 2.6.23 (+ Debian testing version of rt2x00) to 2.6.25 (with bundled rt2x00). I use the rt73usb module.
It seems to work better than the one I used with 2.6.23 in the sense that I can now hibernate, so I'm pretty happy about it. But it just crashed on me

First my wireless connection froze, then processes started to freeze as well, and at some point the whole machine appeared frozen, so I rebooted it.
The logs have megabytes and megabytes of repeated messages which just end with the messages from the next reboot

...
May 12 163442 pastel kernel [171992.161499] phy2 -> rt2x00usb_write_tx_data Error - Arrived at non-free entry in the non-full queue 2.
May 12 163442 pastel kernel [171992.161499] Please file bug report to http//rt2x00.serialmonkey.com.
May 12 163442 pastel kernel [171992.161730] phy2 -> rt2x00usb_write_tx_data Error - Arrived at non-free entry in the non-full queue 2.
May 12 163442 pastel kernel [171992.161730] Please file bug report to http//rt2x00.serialmonkey.com.
May 12 163442 pastel kernel [171992.161960] phy2 -> rt2x00usb_write_tx_data Error - Arrived at non-free entry in the non-full queue 2.
May 12 163442 pastel kernel [171992.161960] Please file bug report to http//rt2x00.serialmonkey.com.
May 12 163610 pastel syslog-ng[3787] syslog-ng starting up; version='2.0.9'
May 12 163610 pastel kernel 0000002 00000001
...

Any idea what might have gone wrong, and what I could do to address it?

IvD

12-05-2008 21:01:57

That is a known bug for kernels 2.6.24 and 2.6.25, the solution however was quite complex which made it impossible to be merged into those kernels. However 2.6.26 will contain the fix, so you could either use 2.6.26-rcx as vanilla kernel from kernel.org or rt2x00.git.

kompletebastard

03-08-2008 09:29:43

I am running 2.6.26-wl and have experienced this problem.

I can therefore confirm that this problem is NOT corrected in the 2.6.26 kernel with the latest git rt73usb driver.

I also had the following stack dump output

WARNING at net/mac80211/tx.c1238 ieee80211_master_start_xmit+0x270/0x2fc [mac80211]()
Modules linked in rt73usb rt2x00usb rt2x00lib led_class mac80211 cfg80211 w1_ds2433 iptable_nat iptable_filter nf_nat_ftp ipt_MASQUERADE nf_nat nf_conntrack_ipv4 nf_conntrack_ftp nf_conntrack ip_tables x_tables mmc_spi msm82c54 mmc_core 8250 crc7 crc_itu_t spi_flash ep93xx_spi ad7414 rfcomm hci_uart w1_smem wire ohci_hcd
[<c002de44>] (dump_stack+0x0/0x14) from [<c0040f18>] (warn_on_slowpath+0x4c/0x84)
[<c0040ecc>] (warn_on_slowpath+0x0/0x84) from [<bf08ea48>] (ieee80211_master_start_xmit+0x270/0x2fc [mac80211])
r6cd5e6000 r5cd457800 r4bf099544
[<bf08e7d8>] (ieee80211_master_start_xmit+0x0/0x2fc [mac80211]) from [<c01d0010>] (dev_hard_start_xmit+0x1c8/0x264)
r8cd72a000 r7cd616000 r6c03202b0 r5cd457800 r400000000
[<c01cfe48>] (dev_hard_start_xmit+0x0/0x264) from [<c01df4ec>] (__qdisc_run+0x94/0x19c)
r700000800 r600000000 r5cd457800 r4cd616000
[<c01df458>] (__qdisc_run+0x0/0x19c) from [<c01d2b18>] (dev_queue_xmit+0x158/0x264)
[<c01d29c0>] (dev_queue_xmit+0x0/0x264) from [<bf08e4e0>] (ieee80211_subif_start_xmit+0x4c0/0x4fc [mac80211])
r700000800 r6cd457800 r5bf090d62 r4cd457820
[<bf08e020>] (ieee80211_subif_start_xmit+0x0/0x4fc [mac80211]) from [<c01d0010>] (dev_hard_start_xmit+0x1c8/0x264)
[<c01cfe48>] (dev_hard_start_xmit+0x0/0x264) from [<c01df4ec>] (__qdisc_run+0x94/0x19c)
r7cd709da0 r600000000 r5cd457800 r4cd5e6000
[<c01df458>] (__qdisc_run+0x0/0x19c) from [<c01d2b18>] (dev_queue_xmit+0x158/0x264)
[<c01d29c0>] (dev_queue_xmit+0x0/0x264) from [<c01d892c>] (neigh_resolve_output+0x224/0x264)
r7cd709da0 r6cd7bc7c0 r5cd457800 r40000000e
[<c01d8708>] (neigh_resolve_output+0x0/0x264) from [<c01ee3a0>] (ip_finish_output+0x230/0x280)
[<c01ee170>] (ip_finish_output+0x0/0x280) from [<c01ee73c>] (ip_output+0xa8/0xbc)
r8cd457800 r7cd457800 r600000000 r5c032068c r4cd457800
[<c01ee694>] (ip_output+0x0/0xbc) from [<c01eddbc>] (ip_local_out+0x30/0x3c)
r5cd7fc480 r4cd457800
[<c01edd8c>] (ip_local_out+0x0/0x3c) from [<c01eeab4>] (ip_queue_xmit+0x2a8/0x2f8)
r4cd543aa0
[<c01ee80c>] (ip_queue_xmit+0x0/0x2f8) from [<c01ff4c4>] (tcp_transmit_skb+0x754/0x7c8)
[<c01fed70>] (tcp_transmit_skb+0x0/0x7c8) from [<c01ff69c>] (tcp_send_ack+0xd4/0xdc)
[<c01ff5c8>] (tcp_send_ack+0x0/0xdc) from [<c01fc934>] (__tcp_ack_snd_check+0x7c/0x9c)
r500000001 r4cd7fc480
[<c01fc8b8>] (__tcp_ack_snd_check+0x0/0x9c) from [<c01fe2a8>] (tcp_rcv_established+0x700/0x780)
r5cd7cfda0 r4cd7fc480
[<c01fdba8>] (tcp_rcv_established+0x0/0x780) from [<c0203ad8>] (tcp_v4_do_rcv+0x30/0x1b4)
[<c0203aa8>] (tcp_v4_do_rcv+0x0/0x1b4) from [<c01f3b60>] (tcp_prequeue_process+0x74/0x8c)
r7cd72bf38 r600001000 r5cd4a63a0 r4cd7fc480
[<c01f3aec>] (tcp_prequeue_process+0x0/0x8c) from [<c01f6060>] (tcp_recvmsg+0x3b8/0x800)
r4cd7fc480
[<c01f5ca8>] (tcp_recvmsg+0x0/0x800) from [<c01c5a84>] (sock_common_recvmsg+0x4c/0x60)
[<c01c5a38>] (sock_common_recvmsg+0x0/0x60) from [<c01c35d8>] (sock_aio_read+0xf0/0xf8)
r5cd28c1e0 r4c0262df0
[<c01c34ec>] (sock_aio_read+0x4/0xf8) from [<c008760c>] (do_sync_read+0xc0/0x114)
r8c0029c64 r7cd72bf80 r6cd72bf80 r5cd71c1e0 r4cd72beb4
[<c008754c>] (do_sync_read+0x0/0x114) from [<c0087f44>] (vfs_read+0xd0/0x134)
r600001000 r5000311c0 r4cd71c1e0
[<c0087e74>] (vfs_read+0x0/0x134) from [<c008836c>] (sys_read+0x4c/0x7c)
r700000003 r6cd71c1e0 r500000000 r400000000
[<c0088320>] (sys_read+0x0/0x7c) from [<c0029ac0>] (ret_fast_syscall+0x0/0x2c)
r60002727c r5000005a8 r4000005a8
---[ end trace 128bc8d59d79138a ]---

IvD

03-08-2008 09:46:19

I am running 2.6.26-wl and have experienced this problem.
I can therefore confirm that this problem is NOT corrected in the 2.6.26 kernel with the latest git rt73usb driver.

[/quote2t7ro0af]

2.6.26-wl is post-2.6.25 but pre-2.6.26 so how is 2.6.26 vanilla working?


I also had the following stack dump output

WARNING at net/mac80211/tx.c1238 ieee80211_master_start_xmit+0x270/0x2fc [mac80211]()[/quote2t7ro0af]

This problem should be fixed in latest version.

blackh

08-08-2008 11:28:51

Yesterday I fixed three bugs in the rt2x00 driver, and I've attached them here. This is against the git of about a week ago, so my apologies if any of these are already fixed.

The three bugs are

Bug 1. hostapd does not work properly if the success status for transmitted packets is returned as TXDONE_UNKNOWN (this is done in at least one USB driver). It treats it as a failure. Whether this is the correct place to fix the bug I am not sure. Perhaps the fix belongs in mac80211 or in hostapd. The symptom is that hostapd outputs

[code208gx58p]wlan0: STA 00:1c:bf:5e:a6:a3 IEEE 802.11: did not acknowledge association response[/code208gx58p]

Bug 2. This output

[code208gx58p]------------[ cut here ]------------
WARNING: at net/mac80211/tx.c:1238 ieee80211_master_start_xmit+0x270/0x2fc [mac80211]()[/code208gx58p]

followed by a stall of the driver. The bug was a race condition in rt2x00queue_write_tx_frame().

3. This output

[code208gx58p]phy8 -> rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 0.
phy8 -> rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 0.
phy8 -> rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 0.[/code208gx58p]

followed by a stall of the driver. The bug was due to non-atomic versions of set_bit/clear_bit/etc where atomic ones were needed.


Steve

IvD

08-08-2008 18:14:40

I'll reply on the mailinglist. No need to have the same discussion on 2 locations.