Re: iwn(4) hangs after r257133

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 <adrian_at_freebsd.org> wrote:
> Sure, flip on 'wlandebug +rate' (assuming you compiled with IEEE80211_DEBUG)
>
>
> -a
>
> On 9 November 2013 21:08, Brandon Gooch <jamesbrandongooch_at_gmail.com> wrote:
>> On Sat, Nov 9, 2013 at 8:46 PM, Adrian Chadd <adrian_at_freebsd.org> wrote:
>>> Hi!
>>>
>>> On 9 November 2013 18:29, Brandon Gooch <jamesbrandongooch_at_gmail.com> 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 lookup, which seems to do something on
>>>> my hardware at least (I assume it's not the right thing based on
>>>> Adrian's analysis, but it works never-the-less).
>>>>
>>>> Has anyone else hit this with Intel WiFi hardware?
>>>>
>>>> Also, what needs to be done to have MRR working properly?
>>>
>>> So, it could be a fall out of how utterly crap AMRR is at 11n rates.
>>>
>>> Please compile with IWN_DEBUG, then do this before you associate:
>>>
>>> sysctl dev.iwn.0.debug=0x1
>>>
>>> (that's IWN_DEBUG_XMIT in sys/dev/iwn/if_iwn_debug.h)
>>>
>>> You can do the same on a kernel with and without the MRR stuff enabled.
>>>
>>> I'd like to see what the actual rate selection looks like and what the
>>> final rate selection is. We may have to patch the kernel to print out
>>> the contents of 'rate' and 'tx->rate' in iwn_tx_data() to get that.
>>
>> I've attached the log output, both with and without MRR.
>>
>> The output looks very much the same within iwn_tx_data(); in
>> iwn5000_tx_done() things are
>> clearly different.
>>
>> If I'm reading the rate conversion bits correctly, I see anywhere from
>> 6 Mbps to 60 Mbps, with the
>> the non-MRR module "getting stuck" -- I really don't know what has
>> happened when it does this.
>>
>> Is there any further debugging output that would be helpful?
>>
>> -Brandon
>>
>>> The MRR stuff is a bit special. I don't know how the link table works
>>> in great depth yet. I know it's broken for 11n; it's plainly using the
>>> wrong indexes now. That's why I disabled it. It shouldn't take that
>>> much work to get it in the tree again; it'll just be fiddly. The easy
>>> bit is populating the table. The hard bit is knowing which index to
>>> set linkq to when transmitting a frame.
>>>
>>>
>>>
>>> -adrian