[ath9k-devel] ath9k and kernel versions

[ath9k-devel] ath9k and kernel versions

[Jack Howarth]

    Does anyone know if the current ath9k drivers will work
against either the tip linux kernel or the current 2.6.26-git12
stable linux kernel? I have been able to generate an ath9k
patch against the tip kernel git which applies cleanly to both
and builds the ath9k driver. I've only tested the ath9k driver
under the tip kernel so far using...

alias ath0 ath9k
alias wifi0 ath9k

in /etc/modprobe.conf which gives the following ath9k kernel messages
in dmesg...

ath9k: 0.1
ath9k 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
phy0: Selected rate control algorithm 'ath9k_rate_control'
udev: renamed network interface wlan0 to ath0
device-mapper: multipath: version 1.0.5 loaded
ADDRCONF(NETDEV_UP): ath0: link is not ready
ath9k/1009 is trying to acquire lock:
3 locks held by ath9k/1009:
Pid: 1009, comm: ath9k Not tainted 2.6.27-0.159.rc0.git11.fc9.x86_64 #1
 [<ffffffffa010542a>] ? ath_set_channel+0x20d/0x225 [ath9k]
Modules linked in: bridge stp bnep rfcomm l2cap bluetooth fuse sunrpc ipt_REJECT
 nf_conntrack_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_i
pv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables cpufreq_ondemand a
cpi_cpufreq freq_table dm_mirror dm_log dm_multipath dm_mod ipv6 snd_seq_dummy s
nd_hda_intel snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss s
nd_mixer_oss snd_pcm joydev arc4 snd_timer i2c_i801 firewire_ohci sr_mod snd_pag
e_alloc i2c_core ecb iTCO_wdt iTCO_vendor_support pcspkr firewire_core cdrom snd
_hwdep crypto_blkcipher snd crc_itu_t ath9k video mac80211 cfg80211 battery soun
dcore sky2 output appletouch ac pata_acpi ata_generic ata_piix ext3 jbd mbcache 
uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode]
Pid: 1009, comm: ath9k Not tainted 2.6.27-0.159.rc0.git11.fc9.x86_64 #1
 [<ffffffff810407d4>] warn_on_slowpath+0x65/0x8c
ath0: authenticate with AP 00:13:f7:05:e8:92
ath0: authenticated
ath0: associate with AP 00:13:f7:05:e8:92
ath0: associate with AP 00:13:f7:05:e8:92
ath0: associate with AP 00:13:f7:05:e8:92
ath0: association with AP 00:13:f7:05:e8:92 timed out
Modules linked in: bridge stp bnep rfcomm l2cap bluetooth fuse sunrpc ipt_REJECT
 nf_conntrack_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_i
pv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables cpufreq_ondemand a
cpi_cpufreq freq_table dm_mirror dm_log dm_multipath dm_mod ipv6 snd_seq_dummy s
nd_hda_intel snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss s
nd_mixer_oss snd_pcm joydev arc4 snd_timer i2c_i801 firewire_ohci sr_mod snd_pag
e_alloc i2c_core ecb iTCO_wdt iTCO_vendor_support pcspkr firewire_core cdrom snd
_hwdep crypto_blkcipher snd crc_itu_t ath9k video mac80211 cfg80211 battery soun
dcore sky2 output appletouch ac pata_acpi ata_generic ata_piix ext3 jbd mbcache 
uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode]
 [<ffffffff8100c2da>] system_call_fastpath+0x16/0x1b
Modules linked in: bridge stp bnep rfcomm l2cap bluetooth fuse sunrpc ipt_REJECT
 nf_conntrack_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_i
pv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables cpufreq_ondemand a
cpi_cpufreq freq_table dm_mirror dm_log dm_multipath dm_mod ipv6 snd_seq_dummy s
nd_hda_intel snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss s
nd_mixer_oss snd_pcm joydev arc4 snd_timer i2c_i801 firewire_ohci sr_mod snd_pag
e_alloc i2c_core ecb iTCO_wdt iTCO_vendor_support pcspkr firewire_core cdrom snd
_hwdep crypto_blkcipher snd crc_itu_t ath9k video mac80211 cfg80211 battery soun
dcore sky2 output appletouch ac pata_acpi ata_generic ata_piix ext3 jbd mbcache 
uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode]
 [<ffffffff8100c2da>] system_call_fastpath+0x16/0x1b
ath0: authenticate with AP 00:18:f8:d7:ab:80
ath0: authenticated
ath0: associate with AP 00:18:f8:d7:ab:80
ath0: RX AssocResp from 00:18:f8:d7:ab:80 (capab=0x431 status=0 aid=1)
ath0: associated
ADDRCONF(NETDEV_CHANGE): ath0: link becomes ready
ath0: deauthenticated
ath0: authenticate with AP 00:18:f8:d7:ab:80
ath0: authenticated
ath0: associate with AP 00:18:f8:d7:ab:80
ath0: associate with AP 00:18:f8:d7:ab:80
ath0: associate with AP 00:18:f8:d7:ab:80
ath0: no IPv6 routers present
ath0: association with AP 00:18:f8:d7:ab:80 timed out
ath0: authenticate with AP 00:18:f8:d7:ab:80
ath0: authenticate with AP 00:18:f8:d7:ab:80
ath0: authenticated
ath0: associate with AP 00:18:f8:d7:ab:80
ath0: associate with AP 00:18:f8:d7:ab:80
ath0: associate with AP 00:18:f8:d7:ab:80
ath0: association with AP 00:18:f8:d7:ab:80 timed out
ath0: authenticate with AP 00:18:f8:d7:ab:80
ath0: authenticate with AP 00:18:f8:d7:ab:80
ath0: authenticated
ath0: associate with AP 00:18:f8:d7:ab:80
ath0: associate with AP 00:18:f8:d7:ab:80
ath0: associate with AP 00:18:f8:d7:ab:80
ath0: association with AP 00:18:f8:d7:ab:80 timed out

However the NetworkManager seems unable to get an address
from the AP. Since I have been using the madwifi drivers before
these kernels (built using the rawhide development srpm as
a framework), I have to remove...

options ath9k autocreate=sta

from modprobe.conf. I am wondering if my problems with the
AP not getting an ip address could be due to the absence of
some option for the ath9k driver which would set it in sta mode?
Also I am unclear if the ath5k/ath9k drivers would require more
careful configuration in the NetworkManager (since they don't have
the 'autocreate=sta' line in modprobe.conf)? Or is it likely that
I am missing some critical wireless patch in tip and/or the stable
kernel. I was hoping to be able to test this driver under at least
the linus-kernel git or the current stable git so that I can keep
using the rawhide srpm and associated patches for Fedora 9. Thanks
in advance for any advice as I am baffled as to why the driver
isn't working.
                  Jack
ps I am connecting to a WRT-150N configured for G wireless connections
only.

[ath9k-devel] ath9k and kernel versions

[Pavel Roskin]

On Fri, 2008-07-25 at 10:52 -0400, Jack Howarth wrote:
> Does anyone know if the current ath9k drivers will work
> against either the tip linux kernel or the current 2.6.26-git12
> stable linux kernel? I have been able to generate an ath9k
> patch against the tip kernel git which applies cleanly to both
> and builds the ath9k driver. I've only tested the ath9k driver
> under the tip kernel so far using...

The current tip kernel is known to have some problems with wireless
devices, which is discussed in linux-wireless.  I don't think it's a
good idea to use it for wireless work at this time.

ath9k is meant to be used with wireless-testing only:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
(master branch)

There is a repository based on wireless-testing with ath9k added:
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/my-wireless-testing.git
(ath9k branch)

> alias ath0 ath9k
> alias wifi0 ath9k
> 
> in /etc/modprobe.conf which gives the following ath9k kernel messages
> in dmesg...

Do you really need all that?  You must be using an ancient distro if the
modules for existing PCI devices are not loaded automatically.  Besides,
you can create a file under /etc/modprobe.d instead of modifying the
stock /etc/modprobe.conf

> ath0: authenticate with AP 00:13:f7:05:e8:92
> ath0: authenticated
> ath0: associate with AP 00:13:f7:05:e8:92
> ath0: associate with AP 00:13:f7:05:e8:92
> ath0: associate with AP 00:13:f7:05:e8:92
> ath0: association with AP 00:13:f7:05:e8:92 timed out

I believe that's the problem reported in the mainline git.  As for the
locking, there was a recent discussion in linux-wireless that may be
relevant.

> However the NetworkManager seems unable to get an address
> from the AP. Since I have been using the madwifi drivers before
> these kernels (built using the rawhide development srpm as
> a framework), I have to remove...
> 
> options ath9k autocreate=sta
> 
> from modprobe.conf.

Why was it there?  ath9k has never had that parameter in its short
lifetime.

>  I am wondering if my problems with the
> AP not getting an ip address could be due to the absence of
> some option for the ath9k driver which would set it in sta mode?

"modinfo ath9k" doesn't show any options at all.  Options are
discouraged in modern drivers.

> Also I am unclear if the ath5k/ath9k drivers would require more
> careful configuration in the NetworkManager (since they don't have
> the 'autocreate=sta' line in modprobe.conf)?

I don't know much about NetworkManager except that I tried it a while
ago.  I don't think anyone is trying to make your life hard and require
additional options, more careful configuration or anything like that.
Free software normally becomes easier to use over time, not harder.

>  Or is it likely that
> I am missing some critical wireless patch in tip and/or the stable
> kernel.

I'm afraid it's not only you who is missing that patch.  Somebody needs
to check what broke the mainline.

>  I was hoping to be able to test this driver under at least
> the linus-kernel git or the current stable git so that I can keep
> using the rawhide srpm and associated patches for Fedora 9. Thanks
> in advance for any advice as I am baffled as to why the driver
> isn't working.

You are lucky that it builds at all, because I tried it on RawHide a few
days ago and it didn't compile.

I believe something got mismerged in the mainline, perhaps some patches
were pulled from wireless testing in a wrong order.

Unfortunately, ath9k is not the easiest driver to use for debugging that
issue, as it requires some of those patches.  There may be no route
between the mainline and wireless-testing that would be bisectable with
ath9k.

-- 
Regards,
Pavel Roskin

[ath9k-devel] ath9k and kernel versions

[Jack Howarth]

Pavel,
   I built a linux 2.6.26-git13 kernel tonight using the
current rawhide kernel srpm and the ath9k patch. To insure
that I have all of the my-wireless-testing patches, I did
a diff of that git against a stock 2.6.26 kernel tree.
The resulting patch when applied against my kernel build
shows that rawhide has all of the changes in my-wireless-testing
except for the changes to the files...

net/mac80211/wme.h
net/mac80211/wme.c

The code patched in those files seems to be completely
missing in 2.6.26-git13.
   I am seeing the following with ath9k now. If I delete
everything in /etc/modprobe.conf for ath9k, disable 
NetworkManager for ath0 and use the Network Control
panel to configure the wireless device. when I activate
it there is an error alert..

Error on wireless request "SetEncode" (8B2A): SET failed
on device ath0; Invalid argument.

The wireless network at this point briefly comes up
(and I can quickly access a web page) but then disconnects.
I'll look at using the command line wireless tools tomorrow
and see what errors those give.
           Jack



On Fri, Jul 25, 2008 at 09:48:30PM -0400, Pavel Roskin wrote:
> On Fri, 2008-07-25 at 10:52 -0400, Jack Howarth wrote:
> > Does anyone know if the current ath9k drivers will work
> > against either the tip linux kernel or the current 2.6.26-git12
> > stable linux kernel? I have been able to generate an ath9k
> > patch against the tip kernel git which applies cleanly to both
> > and builds the ath9k driver. I've only tested the ath9k driver
> > under the tip kernel so far using...
> 
> The current tip kernel is known to have some problems with wireless
> devices, which is discussed in linux-wireless.  I don't think it's a
> good idea to use it for wireless work at this time.
> 
> ath9k is meant to be used with wireless-testing only:
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
> (master branch)
> 
> There is a repository based on wireless-testing with ath9k added:
> git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/my-wireless-testing.git
> (ath9k branch)
> 
> > alias ath0 ath9k
> > alias wifi0 ath9k
> > 
> > in /etc/modprobe.conf which gives the following ath9k kernel messages
> > in dmesg...
> 
> Do you really need all that?  You must be using an ancient distro if the
> modules for existing PCI devices are not loaded automatically.  Besides,
> you can create a file under /etc/modprobe.d instead of modifying the
> stock /etc/modprobe.conf
> 
> > ath0: authenticate with AP 00:13:f7:05:e8:92
> > ath0: authenticated
> > ath0: associate with AP 00:13:f7:05:e8:92
> > ath0: associate with AP 00:13:f7:05:e8:92
> > ath0: associate with AP 00:13:f7:05:e8:92
> > ath0: association with AP 00:13:f7:05:e8:92 timed out
> 
> I believe that's the problem reported in the mainline git.  As for the
> locking, there was a recent discussion in linux-wireless that may be
> relevant.
> 
> > However the NetworkManager seems unable to get an address
> > from the AP. Since I have been using the madwifi drivers before
> > these kernels (built using the rawhide development srpm as
> > a framework), I have to remove...
> > 
> > options ath9k autocreate=sta
> > 
> > from modprobe.conf.
> 
> Why was it there?  ath9k has never had that parameter in its short
> lifetime.
> 
> >  I am wondering if my problems with the
> > AP not getting an ip address could be due to the absence of
> > some option for the ath9k driver which would set it in sta mode?
> 
> "modinfo ath9k" doesn't show any options at all.  Options are
> discouraged in modern drivers.
> 
> > Also I am unclear if the ath5k/ath9k drivers would require more
> > careful configuration in the NetworkManager (since they don't have
> > the 'autocreate=sta' line in modprobe.conf)?
> 
> I don't know much about NetworkManager except that I tried it a while
> ago.  I don't think anyone is trying to make your life hard and require
> additional options, more careful configuration or anything like that.
> Free software normally becomes easier to use over time, not harder.
> 
> >  Or is it likely that
> > I am missing some critical wireless patch in tip and/or the stable
> > kernel.
> 
> I'm afraid it's not only you who is missing that patch.  Somebody needs
> to check what broke the mainline.
> 
> >  I was hoping to be able to test this driver under at least
> > the linus-kernel git or the current stable git so that I can keep
> > using the rawhide srpm and associated patches for Fedora 9. Thanks
> > in advance for any advice as I am baffled as to why the driver
> > isn't working.
> 
> You are lucky that it builds at all, because I tried it on RawHide a few
> days ago and it didn't compile.
> 
> I believe something got mismerged in the mainline, perhaps some patches
> were pulled from wireless testing in a wrong order.
> 
> Unfortunately, ath9k is not the easiest driver to use for debugging that
> issue, as it requires some of those patches.  There may be no route
> between the mainline and wireless-testing that would be bisectable with
> ath9k.
> 
> -- 
> Regards,
> Pavel Roskin