Johannes,
I do see one oddity with the current ath9k git, 2.6.26-rc1
(which appears to have all of the changes in the mywireless-testing
git, your skb->cb fix and my attempt at the same patch for ath9k.
The ath9k driver seems to work okay but I see the following in
the messages log...
Jul 30 08:19:39 localhost kernel:
Jul 30 08:19:39 localhost kernel: =============================================
Jul 30 08:19:39 localhost kernel: [ INFO: possible recursive locking detected ]
Jul 30 08:19:39 localhost kernel: 2.6.27-0.186.rc1.fc9.x86_64 #1
Jul 30 08:19:39 localhost kernel: ---------------------------------------------
Jul 30 08:19:39 localhost kernel: ath9k/1379 is trying to acquire lock:
Jul 30 08:19:39 localhost kernel: (_xmit_IEEE80211#2){-...}, at: [<ffffffffa00f5
c46>] ieee80211_scan_completed+0x142/0x2e2 [mac80211]
Jul 30 08:19:39 localhost kernel:
Jul 30 08:19:39 localhost kernel: but task is already holding lock:
Jul 30 08:19:39 localhost kernel: (_xmit_IEEE80211#2){-...}, at: [<ffffffffa00f5
c46>] ieee80211_scan_completed+0x142/0x2e2 [mac80211]
Jul 30 08:19:39 localhost kernel:
Jul 30 08:19:39 localhost kernel: other info that might help us debug this:
Jul 30 08:19:39 localhost kernel: 3 locks held by ath9k/1379:
Jul 30 08:19:39 localhost kernel: #0: ((name)){--..}, at: [<ffffffff81053f56>]
run_workqueue+0xb6/0x207
Jul 30 08:19:39 localhost kernel: #1: (&(&local->scan_work)->work){--..}, at: [
<ffffffff81053f56>] run_workqueue+0xb6/0x207
Jul 30 08:19:39 localhost kernel: #2: (_xmit_IEEE80211#2){-...}, at: [<ffffffff
a00f5c46>] ieee80211_scan_completed+0x142/0x2e2 [mac80211]
Jul 30 08:19:39 localhost kernel:
Jul 30 08:19:39 localhost kernel: stack backtrace:
Jul 30 08:19:39 localhost kernel: Pid: 1379, comm: ath9k Not tainted 2.6.27-0.18
6.rc1.fc9.x86_64 #1
Jul 30 08:19:39 localhost kernel:
Jul 30 08:19:39 localhost kernel: Call Trace:
Jul 30 08:19:39 localhost kernel: [<ffffffff8106625e>] __lock_acquire+0x790/0xaa
7
Jul 30 08:19:39 localhost kernel: [<ffffffffa00f5c46>] ? ieee80211_scan_complete
d+0x142/0x2e2 [mac80211]
Jul 30 08:19:39 localhost kernel: [<ffffffff8106660b>] lock_acquire+0x96/0xc3
Jul 30 08:19:39 localhost kernel: [<ffffffffa00f5c46>] ? ieee80211_scan_complete
d+0x142/0x2e2 [mac80211]
Jul 30 08:19:39 localhost kernel: [<ffffffff81309838>] _spin_lock+0x2b/0x58
Jul 30 08:19:39 localhost kernel: [<ffffffffa00f5c46>] ieee80211_scan_completed+
0x142/0x2e2 [mac80211]
Jul 30 08:19:39 localhost kernel: [<ffffffff81053f56>] ? run_workqueue+0xb6/0x20
7
Jul 30 08:19:39 localhost kernel: [<ffffffffa00f6097>] ieee80211_sta_scan_work+0
xb4/0x1ad [mac80211]
Jul 30 08:19:39 localhost kernel: [<ffffffff81053fa0>] run_workqueue+0x100/0x207
Jul 30 08:19:39 localhost kernel: [<ffffffffa00f5fe3>] ? ieee80211_sta_scan_work
+0x0/0x1ad [mac80211]
Jul 30 08:19:39 localhost kernel: [<ffffffff810541a4>] worker_thread+0xfd/0x111
Jul 30 08:19:39 localhost kernel: [<ffffffff81057ee1>] ? autoremove_wake_functio
n+0x0/0x3d
Jul 30 08:19:39 localhost kernel: [<ffffffff810540a7>] ? worker_thread+0x0/0x111
Jul 30 08:19:39 localhost kernel: [<ffffffff81057b64>] kthread+0x4e/0x7b
Jul 30 08:19:39 localhost kernel: [<ffffffff81011849>] child_rip+0xa/0x11
Jul 30 08:19:39 localhost kernel: [<ffffffff81010b5e>] ? restore_args+0x0/0x30
Jul 30 08:19:39 localhost kernel: [<ffffffff81057b16>] ? kthread+0x0/0x7b
Jul 30 08:19:39 localhost kernel: [<ffffffff8101183f>] ? child_rip+0x0/0x11
Jul 30 08:19:39 localhost kernel:
Jul 30 08:19:39 localhost kernel: ADDRCONF(NETDEV_CHANGE): ath0: link becomes re
ady
Is this a known issue or perhaps due to may skb->cb patch for ath9k?
Jack
On Wed, Jul 30, 2008 at 09:16:50AM +0200, Johannes Berg wrote:
> On Tue, 2008-07-29 at 20:10 -0400, Jack Howarth wrote:
> > Johannes,
> > FYI, does this following patch look okay for ath9k?
> >
> > --- drivers/net/wireless/ath9k/xmit.c.orig 2008-07-29 19:32:26.000000000 -0400
> > +++ drivers/net/wireless/ath9k/xmit.c 2008-07-29 20:04:09.000000000 -0400
> > @@ -37,6 +37,10 @@
> >
> > #define OFDM_SIFS_TIME 16
> >
> > +#ifndef ETH_P_PAE
> > +#define ETH_P_PAE 0x888E /* Port Access Entity (IEEE 802.1X) */
> > +#endif /* ETH_P_PAE */
> > +
> > static u_int32_t bits_per_symbol[][2] = {
>
> I guess that should finally be moved to a more appropriate place as the
> todo-list on wireless.kernel.org mentions.
>
> johannes
Johannes,
One other question. Does the mac80211 based drivers like
ath5k and ath9k support any form of proc output? I am assuming
that the NetworkManager wireless menu item reports zero signal
due to the absence of a /proc/net/wireless under ath9k. Is that
a TODO as well or should file a bug report against the Fedora
NetworkManager concerning that. I am assuming it uses the proc
to get the signal level and that is why it reports zero. If
I use iwconfig there appears to be a signal level reported for
ath9k.
Jack
On Wed, Jul 30, 2008 at 03:52:14PM +0200, Johannes Berg wrote:
>
> I think that's the false positive due to the tx mq changes that people
> were talking about all the time. Please ignore.
>
> > Is this a known issue or perhaps due to may skb->cb patch for ath9k?
>
> Yeah it's a known issue, nothing with your patch, except for the PAE
> placement your patch is fine. And I don't understand that part of ath9k,
> it shouldn't need to look at that but rather ask the RC algorithm to do
> that job.
>
> johannes
On Wed, 2008-07-30 at 09:28 -0400, Jack Howarth wrote:
> Jul 30 08:19:39 localhost kernel: =============================================
> Jul 30 08:19:39 localhost kernel: [ INFO: possible recursive locking detected ]
> Jul 30 08:19:39 localhost kernel: 2.6.27-0.186.rc1.fc9.x86_64 #1
> Jul 30 08:19:39 localhost kernel: ---------------------------------------------
> Jul 30 08:19:39 localhost kernel: ath9k/1379 is trying to acquire lock:
> Jul 30 08:19:39 localhost kernel: (_xmit_IEEE80211#2){-...}, at: [<ffffffffa00f5
> c46>] ieee80211_scan_completed+0x142/0x2e2 [mac80211]
> Jul 30 08:19:39 localhost kernel:
> Jul 30 08:19:39 localhost kernel: but task is already holding lock:
> Jul 30 08:19:39 localhost kernel: (_xmit_IEEE80211#2){-...}, at: [<ffffffffa00f5
> c46>] ieee80211_scan_completed+0x142/0x2e2 [mac80211]
I think that's the false positive due to the tx mq changes that people
were talking about all the time. Please ignore.
> Is this a known issue or perhaps due to may skb->cb patch for ath9k?
Yeah it's a known issue, nothing with your patch, except for the PAE
placement your patch is fine. And I don't understand that part of ath9k,
it shouldn't need to look at that but rather ask the RC algorithm to do
that job.
johannes