ath5k: no further txbuf available, dropping packet

ath5k: no further txbuf available, dropping packet

[Michael Buesch]

ath5k breaks in AP mode after some operation time and keeps throwing
this message:

[2096249.446071] ath5k phy0: no further txbuf available, dropping packet

Driver is yesterday's compat-wireless on 2.6.31.1

-- 
Greetings, Michael.

Re: ath5k: no further txbuf available, dropping packet

[Bob Copeland]

On Fri, Oct 23, 2009 at 10:08 AM, Michael Buesch <mb@bu3sch.de> wrote:
> ath5k breaks in AP mode after some operation time and keeps throwing
> this message:
>
> [2096249.446071] ath5k phy0: no further txbuf available, dropping packet
>
> Driver is yesterday's compat-wireless on 2.6.31.1

Thanks, I think there's a buffer leak.  Also I believe the
queues are stopped in this case and never re-enabled.

-- 
Bob Copeland %% www.bobcopeland.com

Re: ath5k: no further txbuf available, dropping packet

[Bob Copeland]

On Fri, Oct 23, 2009 at 04:08:16PM +0200, Michael Buesch wrote:
> ath5k breaks in AP mode after some operation time and keeps throwing
> this message:
> 
> [2096249.446071] ath5k phy0: no further txbuf available, dropping packet
> 
> Driver is yesterday's compat-wireless on 2.6.31.1

Ok looked a bit more at this.  I don't see a leak, but I think the
txbufs aren't getting reaped.  Otherwise, we should reenable the queues
when we get back 40 TX completion interrupts.

I'm a bit short on time to track it down, but one thing to try is
commenting out the following from ath5k_beacon_send (will break buffering
but you can test non-ps clients):

        skb = ieee80211_get_buffered_bc(sc->hw, sc->vif);
        while (skb) {
                ath5k_tx_queue(sc->hw, skb, sc->cabq);
                skb = ieee80211_get_buffered_bc(sc->hw, sc->vif);
        }

-- 
Bob Copeland %% www.bobcopeland.com

Re: ath5k: no further txbuf available, dropping packet

[Michael Buesch]

On Saturday 24 October 2009 15:19:29 Bob Copeland wrote:
> On Fri, Oct 23, 2009 at 04:08:16PM +0200, Michael Buesch wrote:
> > ath5k breaks in AP mode after some operation time and keeps throwing
> > this message:
> > 
> > [2096249.446071] ath5k phy0: no further txbuf available, dropping packet
> > 
> > Driver is yesterday's compat-wireless on 2.6.31.1
> 
> Ok looked a bit more at this.  I don't see a leak, but I think the
> txbufs aren't getting reaped.  Otherwise, we should reenable the queues
> when we get back 40 TX completion interrupts.
> 
> I'm a bit short on time to track it down, but one thing to try is
> commenting out the following from ath5k_beacon_send (will break buffering
> but you can test non-ps clients):
> 
>         skb = ieee80211_get_buffered_bc(sc->hw, sc->vif);
>         while (skb) {
>                 ath5k_tx_queue(sc->hw, skb, sc->cabq);
>                 skb = ieee80211_get_buffered_bc(sc->hw, sc->vif);
>         }
> 

I didn't try this, yet, but PS buffering seems to be broken anyway.
If I connect the n810 (which does PS) to the ath5k AP, I cannot ping
the n810 unless I also transfer (ping) _from_ the n810 simultaneously.
I did not monitor the traffic, yet, but to me it seems the AP is unable
to notify that the PS device should wake up (TIM problems?). By pinging from
the n810, I frequently force-wakeup the device, so traffic to the device
also works (more or less).

-- 
Greetings, Michael.

Re: ath5k: no further txbuf available, dropping packet

[Michael Buesch]

On Saturday 24 October 2009 17:05:37 Michael Buesch wrote:
> On Saturday 24 October 2009 15:19:29 Bob Copeland wrote:
> > On Fri, Oct 23, 2009 at 04:08:16PM +0200, Michael Buesch wrote:
> > > ath5k breaks in AP mode after some operation time and keeps throwing
> > > this message:
> > > 
> > > [2096249.446071] ath5k phy0: no further txbuf available, dropping packet
> > > 
> > > Driver is yesterday's compat-wireless on 2.6.31.1
> > 
> > Ok looked a bit more at this.  I don't see a leak, but I think the
> > txbufs aren't getting reaped.  Otherwise, we should reenable the queues
> > when we get back 40 TX completion interrupts.
> > 
> > I'm a bit short on time to track it down, but one thing to try is
> > commenting out the following from ath5k_beacon_send (will break buffering
> > but you can test non-ps clients):
> > 
> >         skb = ieee80211_get_buffered_bc(sc->hw, sc->vif);
> >         while (skb) {
> >                 ath5k_tx_queue(sc->hw, skb, sc->cabq);
> >                 skb = ieee80211_get_buffered_bc(sc->hw, sc->vif);
> >         }
> > 
> 
> I didn't try this, yet, but PS buffering seems to be broken anyway.
> If I connect the n810 (which does PS) to the ath5k AP, I cannot ping
> the n810 unless I also transfer (ping) _from_ the n810 simultaneously.
> I did not monitor the traffic, yet, but to me it seems the AP is unable
> to notify that the PS device should wake up (TIM problems?). By pinging from
> the n810, I frequently force-wakeup the device, so traffic to the device
> also works (more or less).
> 

Ok on the monitor log it looks like the ath5k AP simply sends data while
the STA is in PS, instead of buffering it and updating the TIM.
So if I ping the STA, it keeps sending packets and doesn't set the TIM,
but don't get any repsonse of course, because the STA is power saving.
If I simultaneously ping from the STA, the buffering and TIM handling suddenly
seems to start working. The AP indicates traffic via TIM and the STA sends PS polls.

-- 
Greetings, Michael.

Re: ath5k: no further txbuf available, dropping packet

[Fabio Rossi]

On Friday 23 October 2009 16:08:16 Michael Buesch wrote:

> ath5k breaks in AP mode after some operation time and keeps throwing
> this message:
> 
> [2096249.446071] ath5k phy0: no further txbuf available, dropping packet
> 
> Driver is yesterday's compat-wireless on 2.6.31.1

I got the same message but in managed mode with the latest git wireless 
testing (v2.6.32-rc5-40584-g9b469da)