followup: * 6205 works * 6230 works * 6200 works * 2230 works * 1030 works * 5100 works
What i haven't yet tested: * 4965, mostly because I'm scared to * Whichever NIC Eitan has, as he has it and I don't (2200?) * (and obviously whatever other NICs exist that I don't have) What doesn't work: * Centrino 100 - EEPROM read failure, then kernel hang * 6150, 6235, 6250 - all have a variant on firmware panic or failed calibration upload. So, the 6xxx NICs that don't work should be easy to solve - they should already have (somewhat) worked with -HEAD. The Centrino 100 is a bit more of a special case. If you have any of the above NICs that work or that I haven't yet tested, I'd really appreciate it if you could spin up the latest diff with the latest net80211 code. It should behave quite a bit better. Thanks! -adrian On 8 November 2013 23:46, Adrian Chadd <adr...@freebsd.org> wrote: > Argh, why am I still hacking on the iwn(4) driver. > > So, I saw a lot of broken stuff. This patch fixes some. > > http://people.freebsd.org/~adrian/iwn/20131108-iwn-update-works-full-5100-11.diff > > You have to update sys/net80211 and sys/dev/iwn to the latest version > in HEAD before you apply this diff. > > What's committed: > > * AMRR wasn't correctly initializing the initial rate, so it thought > it was starting at MCS15 but it was in fact starting at MCS0. This > caused hilarity. > > * AMRR should be selecting a "mostly ok" rate, not MCS15. So, this was > also fixed. > > What's in this patch: > > * EAPOL frames were going out at the normal data rate, rather than > going out at the management rate. Like ath(4), override this. Once I > fixed AMRR to set the initial rate from MCS0 to the "best initial > rate" it chose MCS15 and this failed. It showed up as the initial > association suceeding but the auth exchange failed, logging a > "pre-shared key may be incorrect" message. Sigh. So, like ath(4), > detect if it's EAPOL and if so override. > > * If an AMPDU frame TX failed the firmware doesn't send up a > compressed-BA notification as it doesn't receive one. > iwn_ampdu_tx_done() doesn't do any rate control notification - that is > left up to the compressed BA RX function. So, if an entire A-MPDU > transmit failed, there'd be no notification of such - and the rate > control code never got notified of said failures! Thus it would never > back off the rate. So, if the whole frame transmission failed, just > notify the rate control code so it correctly backs off the rate > selection. > > With this, things are .. more stable. The whole A-MPDU handling needs > a lot of work to make as correct as the ath(4) driver, but that is so > not in the scope of what I'm doing here. > > > > -adrian _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"