ath5k/madwifi status on samsung q1

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

ath5k/madwifi status on samsung q1

Amit Kucheria-6
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/284354

Hi,

So the issue here is that -mobile team is upset that a newer ath5k
cannot be shipped in the default kernel. 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?]
- does not work with in-kernel ath5k
- works with ath5k from linux-backports-modules (LBM) [full
functionality including WPA]

Contention point ---> Mobile team would like ath5k from LBM to be
integrated into our kernel.

Why updating in-kernel ath5k is not so easy?
------------------------------------------------------

1. Here is a `git diff --stat --numstat` for the difference between
the two version of ath5k. As you can see [1] it is quite large.

2. And the above diff doesn't even compile with our kernel. Because it
needs updated headers like include/linux/mac80211.h
These headers have unfortunately modified fields in the core data
structures such as:
    struct ieee80211_tx_info
    struct ieee80211_bss_conf

3. So now, if we copy these headers over, every other wifi driver
except ath5k breaks.

4. Only way to fix (3) is to update every wireless driver in the
kernel to that in LBM. Then we probably enable some hardware and cause
regressions in others.

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

Any other possibilities that I might have missed?

Regards,
Amit


[1] Diffstat
 drivers/net/wireless/ath5k/Makefile   |   12 +-
 drivers/net/wireless/ath5k/ath5k.h    |  619 +++++++++++++--------
 drivers/net/wireless/ath5k/attach.c   |  359 ++++++++++++
 drivers/net/wireless/ath5k/base.c     |  581 ++++++++++----------
 drivers/net/wireless/ath5k/base.h     |   10 +-
 drivers/net/wireless/ath5k/caps.c     |  193 +++++++
 drivers/net/wireless/ath5k/debug.c    |    4 +-
 drivers/net/wireless/ath5k/desc.c     |  692 ++++++++++++++++++++++
 drivers/net/wireless/ath5k/desc.h     |  332 +++++++++++
 drivers/net/wireless/ath5k/dma.c      |  605 ++++++++++++++++++++
 drivers/net/wireless/ath5k/eeprom.c   |  466 +++++++++++++++
 drivers/net/wireless/ath5k/eeprom.h   |  215 +++++++
 drivers/net/wireless/ath5k/gpio.c     |  176 ++++++
 drivers/net/wireless/ath5k/initvals.c |   22 +-
 drivers/net/wireless/ath5k/pcu.c      | 1014 +++++++++++++++++++++++++++++++++
 drivers/net/wireless/ath5k/phy.c      |   12 +-
 drivers/net/wireless/ath5k/qcu.c      |  488 ++++++++++++++++
 drivers/net/wireless/ath5k/reg.h      |  679 +++++++++++++---------
 drivers/net/wireless/ath5k/reset.c    |  931 ++++++++++++++++++++++++++++++
 19 files changed, 6591 insertions(+), 819 deletions(-)

10      2       drivers/net/wireless/ath5k/Makefile
389     230     drivers/net/wireless/ath5k/ath5k.h
359     0       drivers/net/wireless/ath5k/attach.c
290     291     drivers/net/wireless/ath5k/base.c
3       7       drivers/net/wireless/ath5k/base.h
193     0       drivers/net/wireless/ath5k/caps.c
2       2       drivers/net/wireless/ath5k/debug.c
692     0       drivers/net/wireless/ath5k/desc.c
332     0       drivers/net/wireless/ath5k/desc.h
605     0       drivers/net/wireless/ath5k/dma.c
466     0       drivers/net/wireless/ath5k/eeprom.c
215     0       drivers/net/wireless/ath5k/eeprom.h
176     0       drivers/net/wireless/ath5k/gpio.c
9       13      drivers/net/wireless/ath5k/initvals.c
1014    0       drivers/net/wireless/ath5k/pcu.c
8       4       drivers/net/wireless/ath5k/phy.c
488     0       drivers/net/wireless/ath5k/qcu.c
409     270     drivers/net/wireless/ath5k/reg.h
931     0       drivers/net/wireless/ath5k/reset.c

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: ath5k/madwifi status on samsung q1

Loïc Minier-17
        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 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.

 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

> 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.

> 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

 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.


 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 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.

   Cheers,
--
Loïc Minier

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: ath5k/madwifi status on samsung q1

Loïc Minier-17
On Wed, Oct 22, 2008, Loïc Minier wrote:
> > Solution for -mobile
> > -----------------------
> > 1. Install LBM by default
> >     - risk of regression if kernel-team adds something else to LBM

 I need to add that this doesn't help the lpia / -mid image at all as it
 doesn't have any lbm and that any fix to linux as suggested below
 should also be applied to linux-lpia.

>  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 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.

--
Loïc Minier

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: ath5k/madwifi status on samsung q1

David Mandala
In reply to this post by Loïc Minier-17
Loïc Minier 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.
>
[snip]

>
>  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 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.
>
>    Cheers,

Given the timeframe remaining, this looks sane and sensible to me, Pete
and Amit, what are your thoughts?


Cheers,

David
--
David Mandala <davidm at canonical dot com>
http://www.canonical.com/ Public Key id: 45B2D952
Murphy TX, 75094 +1.214.774.2569 O +1.972.693.4007 C

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: ath5k/madwifi status on samsung q1

Pete Graner-2
David Mandala wrote:

> Loïc Minier 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.
>>
> [snip]
>>  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 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.
>>
>>    Cheers,
>
> Given the timeframe remaining, this looks sane and sensible to me, Pete
> and Amit, what are your thoughts?

After talking to Tim about the multiple driver loading. It might be
changeable if we could distinguish the various adapters based on
sub-vendor and sub-device ID. Currently all ath5K parts have the same
vendor and device ID. There is no way to tell until the HAL loads
whether the MAC is supported. The MAC is the RF section, usually AR2424
or AR2425, etc... Unfortunately we just can't do it.

Thanks

~pete

>
>
> Cheers,
>
> David


--
Pete Graner <[hidden email]>


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: ath5k/madwifi status on samsung q1

Amit Kucheria-3
In reply to this post by Loïc Minier-17
On Wed, Oct 22, 2008 at 12:58 PM, Loïc Minier <[hidden email]> 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

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Updates on ath5k/madwifi status on samsung q1

Loïc Minier-17
In reply to this post by Loïc Minier-17
        Hi folks,

 For those along following this thread, this is an attempt to summarize
 the actual bugs or abscence thereof around ath5k/madwifi on Q1U.

 First, wifi currently works with madwifi on the Q1U, even if you don't
 change anything, at least with WPA.  Not with WPA2 though as reported
 by Amit.  Better than installing lbm for everybody.  (I don't have WPA2
 nor do I think we can fix madwifi to support it before intrepid; if you
 care, you're welcome to file a bug, I don't have one handy for this.)

 Wifi works with lbm's ath5k which takes precedence over anything else.

 I don't think there is any race with ath5k; the madwifi module just
 plain doesn't like suspend/resume, even when ath5k isn't around.  Bug
 #275692.

 Concerning the two ath5k and madwifi getting loaded, this wont happen
 in jaunty because ath5k is already good enough in tip that we can drop
 madwifi, so we will get a single driver to support all PCI ids, and
 real hardware using these PCI ids.  Bug #284354.  Nothing to be done
 except release-noting the workaround.

 ath5k status in linux/linux-lpia: I didn't see ath5k working, rtg had
 issues with it and recommended removing it from linux/linux-lpia: I
 second that; it's high priority for intrepid, not critical I'd say but
 best to avoid half working wifi IMO; no idea how many affected people
 with working ath5k or half working.  We should recommend lbm or let
 these people try madwifi IMO.  Bug #288148.  For sample breakage, see
 <https://launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=ath5k>
 or #276508, #275423.

 Finally, concerning madwifi wpasupplicant backend, it's an orthogonal
 question; this backend is deprecated (madwifi's upstream recommends not
 using it), and the wext backend works at least for WEP and WPA with
 madwifi drivers.

   Cheers
--
Loïc Minier

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team