Some Intrepid wireless testing results

[Tim Hawkins]

I can confirm the problems with the ath5k driver, i have been trying  
to use it
on an acer aspire one, and as TimG has pointed out it is very flakey.  
I have noticed
that it seems to create associations that are consistently reporting  
lower signal
strength and lower transfer rates than the madwifi driver.  And the  
random drop out
and stall behaviour makes the current driver unusable.

This situation is not just limited to ubuntu intrepid, I have also  
been testing Fedora 10
on the same hardware and it has the same problem with this driver,  
hardly surprising given
that they  have the same upstream source.

On 23 Oct 2008, at 03:04, Tim Gardner wrote:

> I've been doing some testing with some of the wireless devices that I
> have in my possession in an attempt to sort out which ones work. My
> tests are by no means exhaustive, but I wanted to be sure that these
> drivers would at least hook up and do _something_ in the usual use  
> case
> scenarios. The Access Point that I'm using is a dual band NetGear
> WNDR3300 that supports ABG/802.11n, and WPA/TKIP as well as WPA2/ 
> AES. So
> far I've worked through i4965, i3945, and Broadcom wl. Then I started
> testing Atheros 5K and ran into some serious problems. The ath5k  
> driver
> consistently fails under relatively light load and does not seem to
> recover. I thought I'd better share my thoughts before finishing tests
> on the rest of my wireless repertoire because my proposal with  
> regard to
> ath5k is going to require one more kernel upload before release.
>
> As much as it pains me to say this, I think the stock 2.6.27 kernel  
> does
> not have a functional ath5k driver and should be disabled in the  
> kernel
> build. Ultimately, this means support for Atheros wireless is the same
> in Intrepid as it was in Hardy.
>
> However, all is not lost. I've been backporting the wireless testing
> repository to the Intrepid linux-backports-modules package. Some folks
> have reported good success with that version of ath5k, though I have  
> yet
> to test it myself, nor have I done extensive testing on other wireless
> adapters. I expect that Atheros support will continue to improve,  
> and I
> will update LBM when it makes sense.
>
> The root of the problem is that all Atheros 5K adapters have but a few
> unique PCI identifiers. However, 2 adapters with the same PCI ID may
> have different RF backends. The newer RF2424 backends are not  
> supported
> by the released version of madwifi, yet the madwifi driver still gets
> loaded (because the PCI ID matches), fails to init the part, bails out
> with an error, and leaves the chipset in an inconsistent state such  
> that
> the ath5k adapter cannot init the part either, even though it may have
> been able to support the newer backend.
>
> In summary, if the kernel ath5k is not built in the kernel, then there
> will be no conflicts with madwifi. The LBM version of ath5k gets  
> loaded
> before madwifi, so there shouldn't be a conflict since the newer ath5k
> has better support for more RF backends then madwifi and should  
> complete
> the init successfully.
>
> Comments?
>
> rtg
> -- 
> Tim Gardner tim.gardner at canonical.com
>
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team