On Wed, Oct 22, 2008 at 12:58 PM, Loïc Minier <[EMAIL PROTECTED]> wrote: > Hi > > On Wed, Oct 22, 2008, Amit Kucheria wrote: >> So the issue here is that -mobile team is upset that a newer ath5k >> cannot be shipped in the default kernel. > > Hmm no, we want working wifi; we don't want ath5k in particular. Newer > ath5k if it fixes wifi (which I'm told it does) is fine, but madwifi > has been working reliably for us too, and we would have been happy with > madwifi as well. > > bug #284354 is about the two drivers being loaded at the same time > which is completely wrong on its own.
As it has been pointed out in another thread, this problem cannot be solved due to Atheros using non-unique PCI ids. I have attached a comment to the bug. The only real option is to blacklist one of the drivers here. >> As the above bug points out, >> the AR2424 chip in the samsung is showing the following >> characteristics: >> - works with madwifi [only wep works since the wpasupplicant module >> for madwifi was removed?] > > No, WPA works fine. I have WPA TKIP at home, when I boot today's daily > mobile image it uses madwifi and connects to my wifi just fine. When I > suspend/resume, I end up with both ath5k and madwifi half loaded and > wifi doesn't work anymore. WPA2 doesn't work for me with madwifi > I understand that even if the madwifi backend of wpasupplicant was > removed, another backend works with madwifi modules. > >> - does not work with in-kernel ath5k > > Correct. > >> - works with ath5k from linux-backports-modules (LBM) [full >> functionality including WPA] > > (NB: didn't try this out, but this was confirmed by various people.) > >> Contention point ---> Mobile team would like ath5k from LBM to be >> integrated into our kernel. > > Not really; I've been recommending consistently to blacklist ath5k on > our PCI id. Until recently, I didn't see any other hardware working > with ath5k with the same PCI id, but this comment suggest that there > is some EeePC hardware with the same PCI id and working wifi with > ath5k: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/284354/comments/4 Now that you know the situation about the non-unique PCI ids for ath5k, would you still recommend blacklisting ath5k? It would basically force everyone to use madwifi, and that would break significantly more (newer) Atheros chips. >> Why updating in-kernel ath5k is not so easy? >> ------------------------------------------------------ >> 2. And the above diff doesn't even compile with our kernel. Because it >> needs updated headers like include/linux/mac80211.h > > Ok; so not an option; thanks for looking into it. > >> Solution for -mobile >> ----------------------- >> 1. Install LBM by default >> - risk of regression if kernel-team adds something else to LBM >> 2. Blacklist ath5k in the -mobile image >> - madwifi will work with WEP >> - mobile images will break for eee pc users > > This issue is not specific to mobile images/flavours; it affects all > flavours. Agreed. >> Any other possibilities that I might have missed? > > 1. One option I've recommended in the past is changing PCI ids; sadly: > * it's very late in the cycle; only one kernel upload remains > between RC and final (AIUI) > * we have contradictory reports with the same PCI ids that only > madwifi works (mobile team, Q1U), or that ath5k works (EeePC > comment above); these reports DO NOT mention the actual wifi > setup, and I've seen no report that madwifi is not working for > these EeePC users > * we don't have test hardware or testers to ensure testing in time > before release; we'd need to identify people and have testing be > done on time to ensure we don't regress wifi support further with > any change in PCI ids Again, not an option as outlined above. > 2. Shipping multiple versions of ath5k/mac80211 or of madwifi > * while technically feasible, would eat large amount of time > * would make maintenance of linux or lrm harder > * basically same issues with testing and timing as 1. LBM is providing an alternate version of ath5k that works. What needs to be agreed upon is how to ensure there are no regressions in LBM. > So, you've looked into updating ath5k before release, that's not > possible, I propose the following best effort measures: > - kernel team continues looking into fixing ath5k in linux for Q1U / > WPA as a SRU > - we document the issue in the release notes, with known workarounds > (either blacklisting madwifi or ath5k, or installing lbm's ath5k) > - we provide linux-backports-modules as an installable .deb on the > images, at least the mobile images, as to allow the release notes to > give an easy networkless recipe to get wifi working (sudo gdebi > /path/to/lbm.deb); this last idea is one by Oliver, thanks! I would instead like to focus on how to ensure that ath5k in LBM does not have any regressions. Since this is going to affect the whole distro, our efforts would be better spent there and solve the problem for the Q1 too. > I also highly recommend that the kernel team looks at preventing > multiple drivers for the same PCI id to be selected. Having ath5k and > madwifi claim the same PCI ids and racing to get loaded, or having both > of them loaded is completely broken and needs to be blocked ASAP. Covered above. Regards, Amit -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
