svn commit: r257133 - head/sys/dev/iwn

[Adrian Chadd]

I've filed a PR.

Please update to -HEAD and test.

Thanks!


-adrian


On 28 October 2013 15:05, Adrian Chadd <adrian at freebsd.org> wrote:
> Hi!
>
> Yup! So, the difference is in the rate being selected.
>
> It looks like the remote end is just plainly not ACKing the 11n
> management frame being sent; but it totally ACKs the 11b CCK frame
> being sent.
>
> So, thanks for pointing that out. I'll go and err, "fix" this mistake.
> The driver should be doing what the stack says. Bernhard figured out a
> couple years ago that doing 11n management frames to 11n devices is
> not guaranteed to work, so we "fixed" that. I will go and figure out
> why this is now broken for iwn.
>
> Thanks!
>
> Would you mind filing a PR with what we've gathered?
>
>
>
> -adrian
>
>
>
> On 28 October 2013 12:27, Stefan Farfeleder <stefanf at freebsd.org> wrote:
>> On Mon, Oct 28, 2013 at 12:07:17PM -0700, Adrian Chadd wrote:
>>> Yeah:
>>>
>>> Oct 28 19:43:43 mole kernel: iwn5000_tx_done: qid 3 idx 4 retries 7
>>> nkill 0 rate a902 duration 686 status 83
>>>
>>> status 0x83 is LONG_LIMIT, which meant it tried to transmit and it
>>> failed to get an ACK each time.
>>>
>>> The rate control says:
>>>
>>> 0x02: the rate in question
>>> bit 8: MCS
>>> bit 11: HT40
>>> bits 14+15: transmit antennas A+B
>>>
>>> .. and it's an association/management frame, which is odd as they're
>>> not supposed to be sent as 11n HT40 frames like this.
>>>
>>> can you do the same experiment but with the patch reverted? I'd like
>>> to see what the selected rate is.
>>
>> Ok, here's the output with r257155 and r257133 reverted:
>>
>> http://pastebin.com/CJzsTANv
>>
>> Stefan