Friday, January 28, 2011

AR9280/AR9285 support now working

I managed to find and fix the AR9280 and AR9285 support.

Things that needed repairing:

  • Updating the AR9280 initvals to the Linux ath9k ones resolved the radio initialisation issues, making everything magically stable!
  • The v4k EEPROM code (for the AR9285/AR2427) needed some surgery to reflect what was really going on. In particular, the 8 bit radio bias values in the AR9280 (v14) EEPROM are actually lots of 4 bit values; so the bias values being written to the radio were woefully incorrect. This restored AR9285 stability and made the AR2427 function.
  • The AR9280 RF registers need an extra delay before being written to. I guess since the earlier radios are externally connected via single-bit IO (and thus shift registers are involved), the later radios are too. Without this delay, the AR9220 panics on my MIPS board and I would get occasional unexplained resets when I configured an AR9280 on my eeepc. This fix has resolved both those issues.
I have one more fix to integrate for the AR9220 init path so the Ubiquiti SR71-12 and SR71-15 work; then the AR9220 is supported.

The AR2427 baseband seems to hang after a few hours of use, requiring a complete cold (power off) restart. There's some more initialisation code I need to port from ath9k and there's a lot of AR9280/AR9285 calibration code which I need to port over. I hope porting these two over will fix the stability issues that I was seeing. There's also some noise floor calibration fixes from ath9k which I need to integrate into the FreeBSD-HEAD tree.

So, there's been quite a bit of progress! I've had reports from users that the AR9280, AR9285 and AR9220 support is now very stable; much more stable than before.

Friday, January 21, 2011

AR9220 support; why AR9280 is broken

I acquired a pair of shiny AR9220 minipci NICs last week - Ubiquiti SR71-12 and SR71-15. They're supposed to be like AR9280 but on PCI, not PCIe. Unfortunately they didn't work under FreeBSD. After some sleuthing (read: guessing), I stumbled across an ath9k commit which reworked some workaround for some AR9220's, which include the Ubiquiti SR71 versions.

https://patchwork.kernel.org/patch/90926/

There's also a bus error when reading a random register which is only referenced in a debug statement. That's a whole other bug to try and deal with.

But now I've verified that with both the AR9280 and the AR9220, the FreeBSD code is definitely tickling the radio wrong. Only one of the two radio chains is even active for the most part, and that chain seems to go deaf quite often, resulting in a baseband hang and chip reset. It also explains why I was getting absolutely shocking 11n performance out of it in my 11n branch.

Thursday, January 20, 2011

LUSCA ipv6 - almost there (again!)

I've managed to now get the Lusca IPv6 code to perform IPv6 lookups, open a socket to the remote host and then try an IPv6 connection.

But this doesn't work - the legacy Squid-2 comm code does this:
  • Create an AF_INET socket via comm_open();
  • Pass that socket to commConnectStart() with the relevant hostname or IPv4 address to connect to.
If the host is an IPv6 host, the IPv4 socket won't connect to it.

So now I'll have to change the comm API slightly to make commConnectStart() return a FD on completion, rather than taking a socket to connect to. This will also fix a long-standing hatred of mine - where Squid/Lusca opens up a socket that just sits there until DNS lookups succeed. Ew.

Sunday, January 16, 2011

Lusca and IPv6 - almost there

Today's task - tying together the bits of Lusca's IPv6 work to be able to do an IPv6 AAAA lookup, join it with an IPv4 A lookup, then try to connect to IPv6/IPv4 hosts.

The result:

IP Cache Contents:

Hostname Flg lstref TTL N
www.freebsd.org 4 21595 2( 1) [2001:4f8:fff6::22]-BAD 69.147.83.34-OK

So far, so good. I don't have it yet connecting to IPv6 destinations, but all the right bits are in play to be able to do so.

There's plenty of bits in the Squid-3 DNS code that work around potential bugs/gotchas in DNS vs EDNS handling when handling some of the larger IPv6 record replies seen in the real world. I'm going to commit what I have thus far and then look at leveraging what they've done.

Sunday, January 9, 2011

What am I going to do now?

For those who have been following my life elsewhere on the internet, I have struggled for a number of years to finish an undergraduate degree. I've been studying on and off since 2002 and I'm finally two units away from finishing this Bachelor of Arts.

Which now raises a question - what am I going to do next?

I'd like to spend more time studying - but after spending 9 years on and off at this undergraduate degree, I can't help but wonder if I'm doing it because I'm scared of not studying. On the flip side, I think now that I finally understand how to "be" a student and achieve excellent results, I should capitalise on this whilst I'm in that mindset.

I'll see if I get into Linguistics Honours and try to get into something which I can use my psychology and computing skills with as well as straight linguistics.

I'm enjoying creative writing - but I definitely need a lot more practice with that.

I'm still enjoying working on CDN and HTTP/proxy stuff in general; I'm getting a lot of enjoyment hacking on the FreeBSD 802.11 stack and making Atheros devices work a little better; I really like working on embedded hardware. The question is whether I can find some more work in that area whilst I'm in Perth.

Time will tell. I have 6 more months to mull over that whilst focusing primarily on finishing my degree. I'm going to try and finish it on a high note - High Distinctions if possible.