AR2424 on Samsung Q1 loads both ath_pci and ath5k modules

Bug #284354 reported by Oliver Grawert on 2008-10-16
12
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
High
Unassigned
linux (Ubuntu)
High
Unassigned
Intrepid
High
Unassigned
linux-lpia (Ubuntu)
High
Unassigned
Intrepid
High
Unassigned
ubuntu-meta (Ubuntu)
High
Unassigned
Intrepid
High
Unassigned

Bug Description

Samsung Q1 has an Atheros AR2424 chip.

Currently the chip only works with the madwifi ath_pci driver, by default ath5k gets loaded.

The PCI ID for the chip needs to be removed from the ath5k driver

Oliver Grawert (ogra) on 2008-10-16
Changed in linux:
importance: Undecided → High
milestone: none → ubuntu-8.10
Loïc Minier (lool) on 2008-10-16
Changed in linux-lpia:
importance: Undecided → High
Matt Zimmerman (mdz) on 2008-10-16
Changed in linux-lpia:
assignee: nobody → amitk
status: New → Triaged
Changed in linux:
assignee: nobody → amitk
status: New → Triaged
Matt Zimmerman (mdz) wrote :

Oliver: I expect you need to attach much more detailed information in order to permit this bug to be fixed. lspci -vvnn and dmesg at a minimum.

Oliver Grawert (ogra) wrote :

amit has the target hardware so lspci should not be necessary.
on IRC it was agreed that the PCI id for the specific device on this hardware will get disabled so ath5k doesnt get loaded and wont interfere with the madwifi ath_pci driver which works fine and currently gets loaded alongside.
sorry for the wrong wording above.

Amit Kucheria (amitk) wrote :

Just for the record, the PCI id of the Atheros AR2424 on the Q1 is 168c:001c

Krinn (kr86420) wrote :

Just for the record, the PCI id of the Atheros AR5007/AR2425 in the Eee PC 700/900 is also 168c:001c. That wireless chipset does work with ath5k, so it looks like we will need some additional info to distinguish these. See bug 182489.

Amit Kucheria (amitk) on 2008-10-21
description: updated
Amit Kucheria (amitk) wrote :

Krinn: Thanks for that comment. That makes it difficult to just comment out the PCI ID in the i386 kernel.

This seems to point to creation of a 'blacklist' file for the mobile image

Oliver Grawert (ogra) wrote :

which means that no user of any of the mobile images will be able to use ath5k though, no matter if his pci id works or not.

Amit Kucheria (amitk) wrote :

installing 'linux-backports-modules' seems to 'fix' this bug.

Can -mobile add that seed to their image builder?

Matt Zimmerman (mdz) wrote :

In Intrepid, the madwifi backend was removed from wpasupplicant (bug 235463, see https://lists.ubuntu.com/archives/ubuntu-devel/2008-June/025516.html). This introduced regressions, documented in bug 259157, which it was hoped could be addressed in Network Manager or the kernel. That bug is still open, because there are unfixed regressions when using the madwifi driver.

At the same time, the ath5k driver was added, but doesn't work properly with AR2424 according to Oliver. Oliver, what is the bug number for the issue that ath5k doesn't work with this chip?

There are also a variety of other regressions with ath5k relative to madwifi (the default in 8.04): https://edge.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=ath5k

Thus it seems that neither driver is particularly suitable for this device at present and would need to be fixed. The options would seem to be:

- Move ahead to a newer ath5k, which seems to work but has surely not been well tested
- Provide updated userland workarounds for madwifi (bug 259157)
- Fix madwifi (maybe impossible due to the nature of the driver)

Oliver Grawert (ogra) wrote :

the original bug was bug 274832 in which we thought that ath5k was a plain drop in replacement for madwifi, the team only got aware that NM dropped madwifi support completely very recently (sorry, none of our Q1 testers seem to use WPA) so we aimed for just switching back to it until now and our worst case plan here was to have a /etc/modprobe.d/blacklist-ath file in our -settings packages.

testing the ath5k driver from the current lbm package seems to work well now, but for obvious reasons we dont want to seed that package by default in the mobile seeds.

what still makes me curious is the fact that its apparently possible to load two concurrent modules at the same time for one hardware which seems to additionally point to a flaw in the module loading mechanism of the kernel (and produces massive races with the pm-utils scripts that unload/load the drivers on suspend/resume in no particular order).

what makes me upset is that we obviously jump on a fedora "freedom over everything, ignore the user" attitude with the whole thing here, i.e. i dont see us shipping the nuveau driver by default for nvidia cards and the ath5k situation in 2.6.27 was known beforehand apparently. what did justify the complete dropping of madwifi support ?

Loïc Minier (lool) wrote :

With today's mobile image, on a Q1U, madwifi gets loaded and I can connect with nm-applet to a WPA TKIP wifi.

If I suspend/resume, ath5k gets loaded but some ath_* madwifi modules remain loaded; can't associate to same wifi.

Loïc Minier (lool) wrote :

I don't know what dropping madwifi support from wpasupplicant implies, but it obvioulsy works in the current state with my current hardware and latest NM/wpasupplicant/madwifi. I guess it must be using another wpasupplicant backend.

Loïc Minier (lool) wrote :

Matt, I can think of other alternatives, albeit we're late in the cycle now:
- add a new madwifi-compat or madwifi-someharware flavour of madwifi
- use madwifi for some PCI ids

Loïc Minier (lool) wrote :

I feel we lack data on whether madwifi versus ath5k works on PCI ids *AND* wifi setups. We have had mixed reports on the support of misc PCI ids with ath5k and madwifi, but with little information on wifi setups.

On Wed, Oct 22, 2008 at 09:07:56AM -0000, Oliver Grawert wrote:
> what still makes me curious is the fact that its apparently possible to
> load two concurrent modules at the same time for one hardware which
> seems to additionally point to a flaw in the module loading mechanism of
> the kernel (and produces massive races with the pm-utils scripts that
> unload/load the drivers on suspend/resume in no particular order).

I don't think we should be unloading and loading random modules during
suspend. Most drivers probably handle this fine now, and we should consider
changing this after 8.10.

It's perfectly reasonable for multiple modules to get loaded for a device,
so long as only one actually binds to it.

> what makes me upset is that we obviously jump on a fedora "freedom over
> everything, ignore the user" attitude with the whole thing here, i.e. i
> dont see us shipping the nuveau driver by default for nvidia cards and
> the ath5k situation in 2.6.27 was known beforehand apparently. what did
> justify the complete dropping of madwifi support ?

It was broadcast that madwifi was no longer properly supported; this has
been on the Intrepid targeted bug list since August. The original decision
to drop the wpasupplicant madwifi backend was discussed on ubuntu-devel back
in June with detailed rationale which had nothing to do with "freedom over
everything".

Let's stay calm and focus on the problem at hand.

--
 - mdz

Loïc Minier (lool) wrote :

I've sent a summary at https://lists.ubuntu.com/archives/ubuntu-mobile/2008-October/002228.html in response to the proposed plan by Amit.

Loïc Minier (lool) wrote :

I did some additional testing with today's ubuntu live CD for i386; installed on my Q1U.

I'm using WPA TKIP on my wifi network.

By default, ath5k and madwifi would get loaded; madwifi is being used and works (which driver is in use is easy to spot as wifi interfaces provided by madwifi are named ath*), but ath5k is loaded.

I removed ath5k (from /lib/modules), updated initramfs, rebooted, madwifi worked fine, but couldn't associate anymore after suspend/resume. Unloading and reloading ath_* modules fixes that.

I removed ath_* drivers, and readded stock ath5k, rebooted, no wifi despite wifi interfaces being present: scanning doesn't return any results.

I installed linux-backports-modules, modprobe -r'ed ath5k, mac80211, and cfg80211, modprobed ath5k, and got wifi working. Suspend/resume, wifi still worked fine. Wifi worked upon reboot as well (despite the renamed *80211 modules in lbm).

I readded the madwifi modules, rebooted and lbm's ath5k took precedence; wifi worked. I suspend/resumed and wifi would still work. lsmod only showed lbm's ath5k and 80211 drivers, no madwifi, no stock ath5k/80211 drivers.

This means that:
- stock ath5k definitely doesn't work on Q1U, even when madwifi is removed
- current madwifi works on Q1U even with WPA TKIP
- lbm's ath5k works fine when madwifi is removed (with WPA TKIP and across suspend / resume)
-

Loïc Minier (lool) wrote :

Sorry, last line truncated:
- lbm's ath5k takes precedence and works when madwifi is still present (with WPA TKIP and across suspend / resume); madwifi isn't loaded at all

Oliver Grawert (ogra) wrote :

from the 20081022.2 image on the image contains a /debs directory carrying the linux-backports-modules package, users can now install teh l-b-m package throuh gdebi from that directory if needed, no network connection is needed for this. more detailed instructions will follow later.

For reference the process outlined in comment 18 also fixes the same issue on the Asus EEE 900 which has the same problem and chipset.

0168c:001c

Amit Kucheria (amitk) wrote :

Quoting Tim here regarding the 'two modules loading' problem:

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

So this can't really be solved without blacklisting one or the other module.

Colin Watson (cjwatson) wrote :

The outcome of discussion on #ubuntu-release today appears to be as follows:

 * We will remove ath5k from the kernel configuration for 8.10 to avoid the race. (This upload needs to happen today, and involve as few other changes as possible.)
 * We will include linux-backports-modules on the CD so that people can install it without a network connection if they need to.
 * We will add a release notes item to state that newer Atheros devices may not work, and that Atheros devices in general may or may not work with WPA; this item will include instructions on installing linux-backports-modules from the CD as a workaround.

Changed in ubuntu-meta:
importance: Undecided → High
milestone: none → ubuntu-8.10
status: New → Triaged
Changed in ubuntu-release-notes:
importance: Undecided → High
status: New → Triaged
Dave Morley (davmor2) wrote :

Also affects Acer Aspire One's

Loïc Minier (lool) wrote :

I'm marking this bug as wontfix (be it for jaunty or intrepid):
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.

Concerning intrepid, it happens because the driver needs to init the device enough to know whether it supports it or not; so ath5k might load, init the device, realize it wont support it, and then madwifi picks it up.

It is not a problem in itself.

Various other issues have sidetracked discussions, but basically madwifi works on Q1U as expected; ath5k is loaded by as no effect (see comment #16), even across suspend/resume.

ath5k is however broken and should probably be removed from linux/linux-lpia, see bug #288148.

Changed in linux:
assignee: amitk → nobody
milestone: ubuntu-8.10 → none
status: Triaged → Won't Fix
Changed in linux-lpia:
assignee: amitk → nobody
status: Triaged → Won't Fix
Changed in linux:
assignee: amitk → nobody
status: Triaged → Won't Fix
Changed in linux-lpia:
assignee: amitk → nobody
status: Triaged → Won't Fix
Loïc Minier (lool) wrote :

Including lbm was suggested at some point; we can hint people at its usage, but including it by default is out of the question, especially as this affects all flavors of Ubuntu.

Changed in ubuntu-meta:
milestone: ubuntu-8.10 → none
status: Triaged → Invalid
Loïc Minier (lool) wrote :

This bug is now only about release-noting ath5k issues to point at lbm and madwifi.

Oliver Grawert (ogra) wrote :

linux-restricted-modules needs to ship:
/etc/pm/config.d/madwifi

with the following line:
SUSPEND_MODULES="ath_pci"

this will make sure the module gets properly unloaded in suspend/resume cycles which doesnt happen by default and thus results in a broke wlan connection after a resume.

George McLachlan (gmclachl) wrote :

My wireless is still dead even with l-b-m, and I am not the only one. The modules seem to load ok. This is a bit of regression so close to release.

ath9k 260024 0
ath5k 106496 0
lbm_cw_mac80211 210728 2 ath9k,ath5k
lbm_cw_cfg80211 39696 2 ath5k,lbm_cw_mac80211
led_class 12164 2 ath9k,ath5k
ath_pci 99096 0
wlan 211952 1 ath_pci
ath_hal 198864 1 ath_pci

Steve Langasek (vorlon) wrote :
Changed in ubuntu-release-notes:
status: Triaged → Fix Released
Albert Bicchi (bicchi) wrote :

Perhaps this can help others loosing their wireless on Samsung Q1 after returning from suspend or hibernate.

https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/272300/comments/16
The idea is to run "sudo iwconfig wifi0 up" when returning from suspend.

Another solution that worked for me is this one:

https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/272300/comments/23
That just adds: SUSPEND_MODULES="ath_pci"
to the file: /etc/pm/config.d/madwifi

Michael S. (jellicle) wrote :

Just a random note: ath5k seems not to be disabled by default as the last few comments in this thread imply happened for Intrepid's release. I have not previously used used ath5k, and yet after I upgraded to Intrepid, it was now loaded and breaking my working ath_pci setup. (Atheros AR2414 chip, using wpa_supplicant).

For Ubuntu upgraders who have a suddenly broken wireless connection with Atheros hardware:

-Do a "lsmod | grep ath" and see if both ath5k and ath_pci are loaded.

-If they are, do "rmmod ath5k", "rmmod ath_pci", "modprobe ath_pci" and then try to bring your wireless connection up, perhaps by "ifconfig ath0 up".

-you can see what's happening with "cat /var/log/kern.log" and "dmesg | grep ath"

Steve Langasek (vorlon) wrote :

Michael, that's simply not true. The linux-image packages included in Intrepid do not contain the ath5k driver, at all; the only way this driver is present is if you install the corresponding linux-backports-modules package, which is not installed by default, or if you're running the -rt kernel flavor which has not kept pace with the kernel config changes in the main kernel packages (and which is also not installed by default).

Michael S. (jellicle) wrote :

I reported my experience. ath_pci was being loaded and working fine; I upgraded to Intrepid and 2.6.27, and wireless stopped working, and I traced the problem to ath5k being loaded as well as ath_pci. I don't believe I had the linux-backports-modules package installed, although I do now; but even if I did, well, the comments above say the problem should be fixed if linux-backports-modules is installed (because ath5k will work) and if it isn't (because ath5k won't be loaded and therefore won't conflict). My experience is different: it is certainly possible to upgrade as of a couple days ago and have one's Atheros wireless stop working, and judging by the numerous bugs filed and still being filed and forum posts and everything else on this subject, I'm hardly the only one saying so.

Steve Langasek (vorlon) wrote :

if you are having problems with the ath5k driver in linux-backports-modules-2.6.27, please file a separate bug report against that package.

tags: added: iso-testing
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers