[Jaunty] Jockey doesn't display ath5k

Bug #323830 reported by Conrad Knauer on 2009-02-01
This bug affects 1 person
Affects Status Importance Assigned to Milestone
jockey (Ubuntu)
Martin Pitt
module-init-tools (Ubuntu)
Tim Gardner

Bug Description

Hardware: Acer Aspire One (A0A 110-1531)
Software: Installed Jaunty Alpha 3; updated current to repos as of Jan. 31

Problem: As per http://ubuntuforums.org/showthread.php?t=1042075 the Aspire One has trouble getting wireless working; as per Tim Gardner's comment in Bug #315056, one should be able to use Jockey to switch between the ath_pci and ath5k drivers when the kernel issues have been resolved (which they now are). However only ath_pci is visible ("This driver is not activated.").

Note: ath5k was visible in Jockey in Intrepid when using backports.

$ lsmod|grep ath
ath5k 107008 0
mac80211 217208 1 ath5k
led_class 12036 2 acer_wmi,ath5k
cfg80211 38800 2 ath5k,mac80211

$ sudo lshw|grep ath
                configuration: broadcast=yes driver=ath5k_pci latency=0 module=ath5k multicast=yes wireless=IEEE 802.11bg

$ dmesg|grep ath5k
[ 8.463308] ath5k_pci 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 8.463341] ath5k_pci 0000:03:00.0: setting latency timer to 64
[ 8.463464] ath5k_pci 0000:03:00.0: registered as 'phy0'
[ 10.942820] ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)

$ iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wmaster0 no wireless extensions.

wlan0 IEEE 802.11bg ESSID:""
          Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated
          Tx-Power=27 dBm
          Retry min limit:7 RTS thr:off Fragment thr=2352 B
          Power Management:off
          Link Quality:0 Signal level:0 Noise level:0
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

pan0 no wireless extensions.

Martin Pitt (pitti) wrote :

This is related to bug 290264.

Changed in jockey (Ubuntu):
assignee: nobody → pitti
status: New → Triaged
Martin Pitt (pitti) wrote :

Currently m-i-t blacklists it in the main /etc/modprobe.d/blacklist.conf. That's impractical, since if jockey would modify that conffile, we'd break automatic upgrades.

Ideally l-r-m or m-i-t would ship a separate modprobe.d/blacklist-ath_pci, which jockey can then fiddle with.

Changed in module-init-tools (Ubuntu):
assignee: nobody → timg-tpi
Martin Pitt (pitti) wrote :

Whoops, I meant /etc/modprobe.d/blacklist-ath_pci.conf . The .conf suffix matters now.

Discussing this with Tim on IRC, I think the easiest solution will be to just ship this in a separate conffile in m-i-t. This avoids introducing brittle code in m-i-t to maintain this as a non-conffile.

Tim Gardner (timg-tpi) wrote :

Uploaded module-init-tools_3.7~pre9-2

Changed in module-init-tools (Ubuntu):
importance: Undecided → Medium
milestone: none → ubuntu-9.04-beta
status: New → Fix Released
status: Fix Released → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package module-init-tools - 3.7~pre9-2

module-init-tools (3.7~pre9-2) jaunty; urgency=low

  * Moved ath_pci blacklist to /etc/modprobe.d/blacklist-ath_pci.conf
    for better jockey support.
    -LP: #323830

 -- Tim Gardner <email address hidden> Wed, 18 Mar 2009 15:45:43 +0000

Changed in module-init-tools:
status: Fix Committed → Fix Released
Martin Pitt (pitti) on 2009-03-18
Changed in jockey (Ubuntu):
status: Triaged → In Progress
Martin Pitt (pitti) wrote :

The handler I added to jockey won't display ath5k separately, but the madwifi handler points out that this is an alternative for the free ath5k. Enabling/disabling madwifi will disable/enable ath5k.

Changed in jockey (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package jockey - 0.5-0ubuntu5

jockey (0.5-0ubuntu5) jaunty; urgency=low

  * Add debian/watch.
  * Add bzr-builddeb configuration.
  * data/handlers/fglrx.py: Enable again, 2:8.600-0ubuntu1 works on Jaunty
  * Merge bug fixes from trunk:
    - Fix KernelModuleHandler.available() to return False when the handler
      package is not available. This fixes the situation that Jockey
      advertises e. g. the nvidia driver before apt-get update was run, or on
      "free software only" installs. (LP: #341647)
    - kde/jockey-kde.desktop.in: Do not run as root any more, PolicyKit-KDE
      exists now; update README.txt
    - kde/jockey-kde: Port to knotify4. UIF exception approval and original
      patch by Jonathan Riddell. Now properly i18n'ed and integrated into
      standard build system.
    - Update German translations.
  * debian/control: Add policykit-kde dependency to jockey-kde.
  * Add madwifi handler (merged from trunk). This now takes care of properly
    flipping the blacklisting between ath5k and ath_pci (LP: #323830), and
    fixes the description and freeness state (LP: #290264)
  * jockey/oslib.py: Overwrite apt.InstallProgress.fork() to capture the
    child's stdout/stderr into temporary files, and then send that to logging.
    Before this, apt/dpkg output was sent to oblivion, making it hard to
    remotely debug package installation problems. (LP: #280291)

 -- Martin Pitt <email address hidden> Wed, 18 Mar 2009 20:04:01 +0100

Changed in jockey:
status: Fix Committed → Fix Released

I'm in the process of searching bugs regarding this, but I think It may be relevant here:

In the process of upgrading, upon reboot, I had no wireless connectivity. (Making it a bit difficult to research a solution). After a bit of prodding it was obvious that ath_pci was not loaded for my adapter (Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)). Loading it by hand brings up the interface.

After a bit more digging it seems the culprit is the "/etc/modprobe.d/blacklist-ath_pci.conf". Clearly I don't understand the issue completely as I have no idea how any atheros adapters could be expected to work with their driver blacklisted.

Is it safe to just remove the ath_pci black listing? Is there a better work around? How are Atheros adapters expected to work?

It seems this bug may be related: (jockey and madwifi tools may be interfering with each other?)

"/etc/modprobe.d/madwifi.conf stops Atheros wifi modules from loading"

Martin Pitt (pitti) wrote :

You can enable madwifi in system -> admin -> hardware drivers again. Removing the blacklist file will work fine as well, of course.

Tim Gardner (timg-tpi) wrote :

Actually, you shouldn't just remove the blacklist since that will allow both drivers to be loaded. You should instead exchange module names in the blacklist file, either ath5k _or_ ath_pci, depending on which driver you want loaded.

I somehow managed to be ignorant that ath_pci was madwifi until now.

Is not loading a driver when one is available the intended behavior, or is it indeed a bug?

I would imagine that at the very least there is meant to be a notification that there is a proprietary driver available when the interface would otherwise not be brought up.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers