[Jaunty] Jockey doesn't display ath5k

This is related to bug 290264.

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.

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.

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

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

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.

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

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"
https://bugs.launchpad.net/ubuntu/+source/madwifi-tools/+bug/359820

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

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.