Am 11.11.2013 09:18, schrieb Stefan Farfeleder:
On Sun, Nov 10, 2013 at 02:01:12PM -0800, Adrian Chadd wrote:
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 retra
On Sun, Nov 10, 2013 at 02:01:12PM -0800, Adrian Chadd wrote:
> 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 i
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 succeed
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.
And for reference, here's the paper:
http://hal.inria.fr/docs/00/07/07/84/PDF/RR-5208.pdf
-adrian
On 10 November 2013 10:48, 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.)
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.
On Sun, Nov 10, 2013 at 05:14:58AM -0800, Adrian Chadd wrote:
> yup, same info as brandon. :)
http://pastebin.com/MwfL06z7
Stefan
> On 10 November 2013 04:17, Stefan Farfeleder wrote:
> > On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote:
> >> Turns out that not enabling MRR causes
yup, same info as brandon. :)
-a
On 10 November 2013 04:17, Stefan Farfeleder wrote:
> On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote:
>> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link
>> 5300 to hang after only a few moments of use.
>>
>> For now, I've just
On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote:
> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link
> 5300 to hang after only a few moments of use.
>
> For now, I've just reverted only those aspects of r257133, enabling
> MRR and keeping the rate index lookup, whi
Oh, and you need to print out the tx->rate field using "0x%04x",
rather than %d. The completion value is in hex.
-adrian
On 9 November 2013 22:18, Adrian Chadd wrote:
> Sure, flip on 'wlandebug +rate' (assuming you compiled with IEEE80211_DEBUG)
>
>
> -a
>
> On 9 November 2013 21:08, Brandon Go
Sure, flip on 'wlandebug +rate' (assuming you compiled with IEEE80211_DEBUG)
-a
On 9 November 2013 21:08, Brandon Gooch wrote:
> On Sat, Nov 9, 2013 at 8:46 PM, Adrian Chadd wrote:
>> Hi!
>>
>> On 9 November 2013 18:29, Brandon Gooch wrote:
>>> Turns out that not enabling MRR causes my Intel
On Sat, Nov 9, 2013 at 8:46 PM, Adrian Chadd wrote:
> Hi!
>
> On 9 November 2013 18:29, Brandon Gooch wrote:
>> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link
>> 5300 to hang after only a few moments of use.
>
> That's .. odd. Ok.
>
>> For now, I've just reverted only those
Hi!
On 9 November 2013 18:29, Brandon Gooch wrote:
> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link
> 5300 to hang after only a few moments of use.
That's .. odd. Ok.
> For now, I've just reverted only those aspects of r257133, enabling
> MRR and keeping the rate index loo
13 matches
Mail list logo
