ath5k phy0: no further txbuf available, dropping packet

ath5k phy0: no further txbuf available, dropping packet

[David Srbecky]

I am getting this error as well.

I am using Atheros card as AP.

After a while I start getting the following message in syslog:
  ath5k phy0: no further txbuf available, dropping packet

The message repeats every 10 seconds and the wireless network is no
longer usabe until hostapd is restarted.

The timing seems quite random, but on average it occurs about once per
half an hour.  Transfering a lot of data over the wireless does not
seem to make it happen any sooner.

I currently have compat-wireless-2009-10-25 installed.
I am using hostap commit cca87731 (Thu Oct 22 11:17:05 2009 -0700).

[root@alix ~]# uname -a
Linux alix 2.6.30.8-64.fc11.i586 #1 SMP Fri Sep 25 04:30:19 EDT 2009
i586 i586 i386 GNU/Linux

[root@alix ~]# lspci -k | grep -A2 "Atheros"
00:0c.0 Ethernet controller: Atheros Communications Inc. AR2413
802.11bg NIC (rev 01)
        Subsystem: Atheros Communications Inc. Compex Wireless 802.11
b/g  MiniPCI Adapter, Rev A1 [WLM54G]
        Kernel driver in use: ath5k
        Kernel modules: ath5k

Re: ath5k phy0: no further txbuf available, dropping packet

[Michael Buesch]

On Monday 26 October 2009 21:52:39 David Srbecky wrote:
> I am getting this error as well.

Ok, I looked at the code a bit and this looks strange to me.
There's the TX status handler in base.c which basically looks like this:


	loop_over_queued_packets() {
		ret = sc->ah->ah_proc_rx_desc(sc->ah, ds, &rs);
		if (unlikely(ret == -EINPROGRESS))
			break;
		free_packet_and_return_bufferhead_to_pool();
	}

So the ah_proc_rx_desc callback looks like this:

	ah_proc_rx_..._desc()
	{
		...
		/* No frame has been send or error */
		if (unlikely(!(tx_status->tx_status_1 & AR5K_DESC_TX_STATUS1_DONE)))
			return -EINPROGRESS;
		...
	}

Notice the comment and how it says "or error". So does that mean that if the
hardware produces some kind of error on one frame, the driver will stop processing any TX status
reports (because the loop always breaks early)? This would result in a buffer queue underrun,
which is reported by the printk.

-- 
Greetings, Michael.

Re: ath5k phy0: no further txbuf available, dropping packet

[Michael Buesch]

On Monday 26 October 2009 22:30:55 Michael Buesch wrote:
> On Monday 26 October 2009 21:52:39 David Srbecky wrote:
> > I am getting this error as well.
> 
> Ok, I looked at the code a bit and this looks strange to me.
> There's the TX status handler in base.c which basically looks like this:
> 
> 
> 	loop_over_queued_packets() {
> 		ret = sc->ah->ah_proc_rx_desc(sc->ah, ds, &rs);

Typo. I meant ah_proc_tx_desc()

> 		if (unlikely(ret == -EINPROGRESS))
> 			break;
> 		free_packet_and_return_bufferhead_to_pool();
> 	}
> 
> So the ah_proc_rx_desc callback looks like this:
> 
> 	ah_proc_rx_..._desc()

same here

> 	{
> 		...
> 		/* No frame has been send or error */
> 		if (unlikely(!(tx_status->tx_status_1 & AR5K_DESC_TX_STATUS1_DONE)))
> 			return -EINPROGRESS;
> 		...
> 	}

-- 
Greetings, Michael.

Re: ath5k phy0: no further txbuf available, dropping packet

[Bob Copeland]

On Mon, Oct 26, 2009 at 10:30:55PM +0100, Michael Buesch wrote:
> 		/* No frame has been send or error */
> 		if (unlikely(!(tx_status->tx_status_1 & AR5K_DESC_TX_STATUS1_DONE)))
> 			return -EINPROGRESS;
> 		...
> 	}

> Notice the comment and how it says "or error".

Hmm, that does sound problematic.  But looking at the various bitfields:

#define AR5K_DESC_TX_STATUS1_DONE               0x00000001
#define AR5K_DESC_TX_STATUS1_SEQ_NUM            0x00001ffe
#define AR5K_DESC_TX_STATUS1_ACK_SIG_STRENGTH   0x001fe000
#define AR5K_DESC_TX_STATUS1_FINAL_TS_INDEX     0x00600000
#define AR5K_DESC_TX_STATUS1_COMP_SUCCESS       0x00800000
#define AR5K_DESC_TX_STATUS1_XMIT_ANTENNA       0x01000000

I would be led to believe that 'done' means 'completed or error' and
the comment is similarly ambiguous.  The status0 word contains things
like 'really did succeed, number of retries, timestamp' etc.

-- 
Bob Copeland %% www.bobcopeland.com

Re: ath5k phy0: no further txbuf available, dropping packet

[Michael Buesch]

On Tuesday 27 October 2009 11:09:26 Bob Copeland wrote:
> On Mon, Oct 26, 2009 at 10:30:55PM +0100, Michael Buesch wrote:
> > 		/* No frame has been send or error */
> > 		if (unlikely(!(tx_status->tx_status_1 & AR5K_DESC_TX_STATUS1_DONE)))
> > 			return -EINPROGRESS;
> > 		...
> > 	}
> 
> > Notice the comment and how it says "or error".
> 
> Hmm, that does sound problematic.  But looking at the various bitfields:
> 
> #define AR5K_DESC_TX_STATUS1_DONE               0x00000001
> #define AR5K_DESC_TX_STATUS1_SEQ_NUM            0x00001ffe
> #define AR5K_DESC_TX_STATUS1_ACK_SIG_STRENGTH   0x001fe000
> #define AR5K_DESC_TX_STATUS1_FINAL_TS_INDEX     0x00600000
> #define AR5K_DESC_TX_STATUS1_COMP_SUCCESS       0x00800000
> #define AR5K_DESC_TX_STATUS1_XMIT_ANTENNA       0x01000000
> 
> I would be led to believe that 'done' means 'completed or error' and
> the comment is similarly ambiguous.  The status0 word contains things
> like 'really did succeed, number of retries, timestamp' etc.

Hm, I looked through the whole status processing code and this is the only
place I can see that could trigger stalling of the buffer head queue.

If the lowlevel status handler is able to distinguish between "done", "error" and "not done yet",
the return codes should probably changed:

0 => Packet was properly processed.
     The upper status handler will free it
-INPROGRESS => Packet was not processed, yet.
               The upper status handler should bail out and wait.
ERROR => Packet failed.
         The upper status handler should drop the packet
         and go on processing the other frames.

If that's not the case, I don't really know what's happening.

-- 
Greetings, Michael.

Re: ath5k phy0: no further txbuf available, dropping packet

[David Srbecky]

Hi,

Is there any progress with trying to solve this problem?

Thanks a lot,
David

Re: ath5k phy0: no further txbuf available, dropping packet

[Bob Copeland]

On Sun, Nov 8, 2009 at 1:12 PM, David Srbecky <dsrbecky@gmail.com> wrote:
> Hi,
>
> Is there any progress with trying to solve this problem?

Yes, I believe the changes to the cab queue timing will fix it, but
I still need to do some testing on various queue settings before I
can send a patch.  In the meantime, we discussed the possibility of
simply continuing in the tx processing loop instead of bailing out for
incomplete descriptors; I don't forsee any problem with that approach.

-- 
Bob Copeland %% www.bobcopeland.com