Re: iwn(4) hangs after r257133

Yes. So one of the.. unfortunately broken things in iwn is the ampdu tx
code doesn't do retransmits. So if amrr picks a rate that fails to transmit
everything, the driver doesn't retransmit them. It frees them.

Now when amrr is enabled the hardware will retry at lower rates until
something succeeds. But it still doesn't retransmit things. I believe it
should be.

So yes its more broken with Mrr disabled. But enabling mrr doesn't fix it.
It just makes it less broken. Someone needs to implement ampdu retransmit.

The latest iwn code in head at least tells the rate selection code that a
total ampdu tx failure occured. This BTW is one of the hangs I fixed - if
you hit a point where you never successfully transmitted an ampdu at a rate
the rate would never be decreased.

Now to be clear. I won't be in implementing ampdu retransmit. I'll maybe
fix last multi rate retry once the new hardware support is in. I would
really appreciate help here with these. Everyone with iwn hardware will
appreciate it :)

Thanks,

Adrian

Adrian
On Nov 10, 2013 11:34 AM, "Stefan Farfeleder" <stefanf_at_freebsd.org> wrote:

> On Sun, Nov 10, 2013 at 10:48:48AM -0800, Adrian Chadd wrote:
> > Right near the end there you have 'status 83' which means 'transmit
> > failed, long retry hit' (the status codes are in if_iwnreg.h
> > somewhere.) The retry count hit 16, which is the max set for the
> > frame.
> >
> > rate=80 (hex) is MCS0. So, you're seeing retransmits and failures at
> > MCS0, which is a bad sign.
> >
> > But, notice how AMRR increased it to MCS2 at a couple stages, and that
> > _always_ fails. But AMRR waits for 10 frame transmits before it
> > adjusts the rate up or down.
> >
> > So yes, we do need to enable MRR again on iwn for things to behave
> > better. There are other issues when you start doing larger amounts of
> > traffic but I'll cover those later.what?
> >
> > If someone wants to take a crack at correctly implementing the link
> > quality table stuff again then please let me know. As I said before,
> > the link quality table setup code is mostly sane. The problem is
> > actually correctly setting 'linkq' to start at the selected rate, as
> > linkq is an index into that table, not the initial rate.
>
> Hi,
>
> after some trial and error I found out that disabling AMPDU makes my
> iwn0 usable again. Now I actually see the rate as reported by `list sta'
> going up and down (mostly between 54M and 121M). Before it was always
> fixed at 135M.
>
> Could this be related?
>
> Stefan
>