I've filed a PR. Please update to -HEAD and test.
Thanks! -adrian On 28 October 2013 15:05, Adrian Chadd <adr...@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 <stef...@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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
