* Re: Compat-wireless release for 2010-06-26 is baked
From: Luis R. Rodriguez @ 2010-06-28 16:38 UTC (permalink / raw)
To: Andrei Emeltchenko
Cc: Compat-wireless cronjob account, linux-wireless, linux-bluetooth
In-Reply-To: <AANLkTinJS2MXv3VF_m5IF67mCIXWQN9TmaAlKi771i6d@mail.gmail.com>
On Mon, Jun 28, 2010 at 4:13 AM, Andrei Emeltchenko
<andrei.emeltchenko.news@gmail.com> wrote:
> Hi
>
> On Sat, Jun 26, 2010 at 10:02 PM, Compat-wireless cronjob account
> <compat@orbit-lab.org> wrote:
>
> Looks like the mail is sent to wrong ML?
Its for BT too.
Luis
^ permalink raw reply
* Re: intel 5100/iwlagn bug in 2.6.35-rc2 during large file transfer
From: Richard Farina @ 2010-06-28 17:01 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1277742425.13673.1376.camel@rchatre-DESK>
reinette chatre wrote:
> On Sun, 2010-06-27 at 10:14 -0700, Richard Farina wrote:
>
>>> ---
>>> drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 5 +++--
>>> drivers/net/wireless/iwlwifi/iwl-fh.h | 2 +-
>>> 2 files changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
>>> index 0f292a2..2815ee7 100644
>>> --- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
>>> +++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
>>> @@ -613,7 +613,8 @@ void iwlagn_rx_allocate(struct iwl_priv *priv, gfp_t priority)
>>> }
>>> spin_unlock_irqrestore(&rxq->lock, flags);
>>>
>>> - if (rxq->free_count > RX_LOW_WATERMARK)
>>> + if ((priority == GFP_ATOMIC) ||
>>> + (rxq->free_count > RX_LOW_WATERMARK / 4))
>>> gfp_mask |= __GFP_NOWARN;
>>>
>>>
>
> Here I set the allocation mask to not print _any_ warnings when
> allocation is atomic ...
>
>
>
>> [180257.090410] swapper: page allocation failure. order:1, mode:0x4020
>> [180257.090414] Pid: 0, comm: swapper Not tainted 2.6.34-pentoo-r2 #2
>> [180257.090416] Call Trace:
>>
>
> ... clearly this is an allocation warning ...
>
>
>> [180257.090418] <IRQ> [<ffffffff810984c0>]
>> __alloc_pages_nodemask+0x571/0x5b9
>> [180257.090437] [<ffffffffa05162f3>] iwlagn_rx_allocate+0x98/0x2e0 [iwlagn]
>> [180257.090445] [<ffffffffa051668c>] iwlagn_rx_replenish_now+0x16/0x23
>> [iwlagn]
>>
>
> ... but it is an atomic one, which after the patch should not be
> printing _any_ warning ...
>
>
I dunno, I really don't. but I did just verify the patch and it is
correct and applied.
Thanks,
Rick
> I am very confused now.
>
> Reinette
>
>
>
>
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions 2.6.33 -> 2.6.34
From: Tim Gardner @ 2010-06-28 18:22 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Pavel Roskin, linux-wireless, Rafael J. Wysocki, j
In-Reply-To: <4C2110BA.3020801@canonical.com>
On 06/22/2010 01:36 PM, Tim Gardner wrote:
> On 06/21/2010 06:26 PM, Luis R. Rodriguez wrote:
>> On Mon, Jun 21, 2010 at 5:14 PM, Tim
>> Gardner<tim.gardner@canonical.com> wrote:
>>> On 06/21/2010 04:18 PM, Luis R. Rodriguez wrote:
>>>>
>>>> On Mon, Jun 21, 2010 at 3:01 PM, Pavel Roskin<proski@gnu.org>
>>>> wrote:
>>>>>
>>>>> On Mon, 2010-06-21 at 11:32 -0700, Luis R. Rodriguez wrote:
>>>>>
>>>>>>> Bug-Entry :
>>>>>>> http://bugzilla.kernel.org/show_bug.cgi?id=16111 Subject
>>>>>>> : hostap_pci: infinite registered netdevice wifi0
>>>>>>> Submitter : Petr Pisar<petr.pisar@atlas.cz> Date :
>>>>>>> 2010-06-02 20:55 (19 days old)
>>>>>>
>>>>>> The last entry on this one says we are not sure how to fix
>>>>>> this...
>>>>>
>>>>> That was a patch posted for that by Tim Gardner:
>>>>> https://patchwork.kernel.org/patch/105008/
>>>>>
>>>>> The patch is applied to wireless-testing
>>>>> (d6a574ff6bfb842bdb98065da053881ff527be46)
>>>>>
>>>>> $ git describe d6a574ff6bfb842bdb98065da053881ff527be46
>>>>> v2.6.34-4694-gd6a574f
>>>>>
>>>>> I understand it was applied after 2.6.34, so it should be
>>>>> backported to 2.6.34 and whatever older kernels are
>>>>> affected.
>>>>
>>>> Tim can this be sent for stable?
>>>>
>>>> Luis, a stable whore
>>>>
>>>
>>> Luis,
>>>
>>> The patch that I sent John is already Cc stable@kernel.org,
>>> though it may not now apply after
>>> 56bf882230d2266a2e07b7f404dc96d157a65daa 'Revert "wireless:
>>> hostap, fix oops due to early probing interrupt"'. I'll check in
>>> the morning and craft a backported patch if necessary.
>>
>> Sweet thanks for the heads up!
>>
>> Luis
>>
>
> Hmm, looks like I'm gonna have to write some backport patches. I'll
> wait until this appears in Linus' tree so I can feed stable the right
> SHA1 info.
>
> rtg
I sent 4 backport patches (from commit
d6a574ff6bfb842bdb98065da053881ff527be46) to stable@kernel.org;
2.6.27.y, 2.6.32.y, 2.6.33.y, and 2.6.34.y. Unfortunately they all
required unique patches in order to cleanly apply since there seemed to
be some fiddling around with driver specific card services macros from
version to version.
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* Compat-wireless release for 2010-06-28 is baked
From: Compat-wireless cronjob account @ 2010-06-28 19:03 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
138f35f..b698fdf history -> origin/history
+ c3116ae...6dc1a02 master -> origin/master (forced update)
7e27d6e..b4322e7 stable -> origin/stable
* [new tag] next-20100628 -> next-20100628
compat-wireless code metrics
494347 - Total upstream lines of code being pulled
^ permalink raw reply
* Re: intel 5100/iwlagn bug in 2.6.35-rc2 during large file transfer
From: reinette chatre @ 2010-06-28 20:39 UTC (permalink / raw)
To: Richard Farina; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4C28D552.30000@gmail.com>
On Mon, 2010-06-28 at 10:01 -0700, Richard Farina wrote:
> reinette chatre wrote:
> > On Sun, 2010-06-27 at 10:14 -0700, Richard Farina wrote:
> >
> >>> ---
> >>> drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 5 +++--
> >>> drivers/net/wireless/iwlwifi/iwl-fh.h | 2 +-
> >>> 2 files changed, 4 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> >>> index 0f292a2..2815ee7 100644
> >>> --- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> >>> +++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> >>> @@ -613,7 +613,8 @@ void iwlagn_rx_allocate(struct iwl_priv *priv, gfp_t priority)
> >>> }
> >>> spin_unlock_irqrestore(&rxq->lock, flags);
> >>>
> >>> - if (rxq->free_count > RX_LOW_WATERMARK)
> >>> + if ((priority == GFP_ATOMIC) ||
> >>> + (rxq->free_count > RX_LOW_WATERMARK / 4))
> >>> gfp_mask |= __GFP_NOWARN;
> >>>
> >>>
> >
> > Here I set the allocation mask to not print _any_ warnings when
> > allocation is atomic ...
> >
> >
> >
> >> [180257.090410] swapper: page allocation failure. order:1, mode:0x4020
> >> [180257.090414] Pid: 0, comm: swapper Not tainted 2.6.34-pentoo-r2 #2
> >> [180257.090416] Call Trace:
> >>
> >
> > ... clearly this is an allocation warning ...
> >
> >
> >> [180257.090418] <IRQ> [<ffffffff810984c0>]
> >> __alloc_pages_nodemask+0x571/0x5b9
> >> [180257.090437] [<ffffffffa05162f3>] iwlagn_rx_allocate+0x98/0x2e0 [iwlagn]
> >> [180257.090445] [<ffffffffa051668c>] iwlagn_rx_replenish_now+0x16/0x23
> >> [iwlagn]
> >>
> >
> > ... but it is an atomic one, which after the patch should not be
> > printing _any_ warning ...
> >
> >
> I dunno, I really don't. but I did just verify the patch and it is
> correct and applied.
Could you please verify that it is the patch below and not an earlier
patch I sent? Apart from what I mention above there is another strange
thing in the logs you provide. In your logs you have the message:
iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 40 free buffers remaining.
while the code is:
»-------»-------»-------if ((rxq->free_count <= RX_LOW_WATERMARK / 4) &&
»-------»-------»------- net_ratelimit())
»-------»-------»-------»-------IWL_CRIT(priv, "Failed to alloc_pages with %s. Only %u free buffers remaining.\n",
»-------»-------»-------»-------»------- priority == GFP_ATOMIC ? "GFP_ATOMIC" : "GFP_KERNEL",
»-------»-------»-------»-------»------- rxq->free_count);
with :
#define RX_LOW_WATERMARK 128
The message in your log should thus not be there since it should only
print the message if the free_count less than or equal to 32.
>From 65c459c35332c7039cc84a980e6e04118ba81c04 Mon Sep 17 00:00:00 2001
From: Reinette Chatre <reinette.chatre@intel.com>
Date: Thu, 24 Jun 2010 10:48:59 -0700
Subject: [PATCH] increase low watermark
---
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 5 +++--
drivers/net/wireless/iwlwifi/iwl-fh.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index 0f292a2..2815ee7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -613,7 +613,8 @@ void iwlagn_rx_allocate(struct iwl_priv *priv, gfp_t priority)
}
spin_unlock_irqrestore(&rxq->lock, flags);
- if (rxq->free_count > RX_LOW_WATERMARK)
+ if ((priority == GFP_ATOMIC) ||
+ (rxq->free_count > RX_LOW_WATERMARK / 4))
gfp_mask |= __GFP_NOWARN;
if (priv->hw_params.rx_page_order > 0)
@@ -627,7 +628,7 @@ void iwlagn_rx_allocate(struct iwl_priv *priv, gfp_t priority)
"order: %d\n",
priv->hw_params.rx_page_order);
- if ((rxq->free_count <= RX_LOW_WATERMARK) &&
+ if ((rxq->free_count <= RX_LOW_WATERMARK / 4) &&
net_ratelimit())
IWL_CRIT(priv, "Failed to alloc_pages with %s. Only %u free buffers remaining.\n",
priority == GFP_ATOMIC ? "GFP_ATOMIC" : "GFP_KERNEL",
diff --git a/drivers/net/wireless/iwlwifi/iwl-fh.h b/drivers/net/wireless/iwlwifi/iwl-fh.h
index 113c366..431bc58 100644
--- a/drivers/net/wireless/iwlwifi/iwl-fh.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fh.h
@@ -426,7 +426,7 @@
* RX related structures and functions
*/
#define RX_FREE_BUFFERS 64
-#define RX_LOW_WATERMARK 8
+#define RX_LOW_WATERMARK 128
/* Size of one Rx buffer in host DRAM */
#define IWL_RX_BUF_SIZE_3K (3 * 1000) /* 3945 only */
--
1.7.0.4
^ permalink raw reply related
* ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Björn Smedman @ 2010-06-28 22:31 UTC (permalink / raw)
To: linux-wireless, ath9k-devel
Hi all,
I'm getting weird values from the debugfs file ieee80211/phy0/tsf: the
value goes up and down rather randomly and only the lower 24 bits or
so seem to ever be used (see below for details).
The only thing running on phy0 is a single ap interface (and the
monitor companion that hostapd sets up). I was expecting tsf to
increase monotonically until all 64 bits had been used.
root@OpenWrt:/debug/ieee80211/phy0# dmesg | grep phy0
phy0: Selected rate control algorithm 'minstrel_ht'
phy0: Atheros AR9100 MAC/BB Rev:0 AR2133 RF Rev:a2 mem=0xb80c0000, irq=2
root@OpenWrt:/debug/ieee80211/phy0# while sleep 1; do cat tsf; done
0x0000000000059d9b
0x0000000000038fa2
0x00000000000ee67e
0x000000000008121e
0x000000000017752d
0x000000000006438b
0x000000000015a771
0x00000000000d5ea0
0x0000000000085b43
0x0000000000037806
0x000000000001f562
0x0000000000115b03
0x000000000020be55
^C
If you poll tsf really fast it looks a bit like it's running correctly
but being reset very often:
root@OpenWrt:/debug/ieee80211/phy0# while true; do cat tsf; done
...
0x00000000004b2319
0x00000000004b33f2
0x00000000004b46dc
0x00000000004b578c
0x00000000004b6a89
0x0000000000014435
0x00000000000154a0
0x00000000000167ce
0x000000000001785d
...
^C
For a moment I thought it might be the kernel snprintf (on mips)
playing a trick on me so I tried the following patch. But the result
is the same.
diff -urN a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -63,7 +63,8 @@
tsf = drv_get_tsf(local);
- snprintf(buf, sizeof(buf), "0x%016llx\n", (unsigned long long) tsf);
+ snprintf(buf, sizeof(buf), "0x%08lx%08lx\n",
+ (unsigned long)(tsf >> 32), (unsigned long)tsf);
return simple_read_from_buffer(user_buf, count, ppos, buf, 19);
}
What could be causing this? Because it's not supposed to do this,
right? Any insight much appreciated!
/Björn
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Felix Fietkau @ 2010-06-28 22:55 UTC (permalink / raw)
To: Björn Smedman; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <AANLkTilG4qxjX0e5u_BGp0YcPoVBbsqd6Hlb8E0j_S8S@mail.gmail.com>
On 2010-06-29 12:31 AM, Björn Smedman wrote:
> Hi all,
>
> I'm getting weird values from the debugfs file ieee80211/phy0/tsf: the
> value goes up and down rather randomly and only the lower 24 bits or
> so seem to ever be used (see below for details).
>
> The only thing running on phy0 is a single ap interface (and the
> monitor companion that hostapd sets up). I was expecting tsf to
> increase monotonically until all 64 bits had been used.
>
> For a moment I thought it might be the kernel snprintf (on mips)
> playing a trick on me so I tried the following patch. But the result
> is the same.
IMHO the most likely problem source is stuck beacons. Please compile the
driver with the debug option enabled and load it with
insmod ath9k debug=0x00000100
- Felix
^ permalink raw reply
* Re: [PATCH 0/2] at76c50x-usb.c: Fix broken authentication process
From: Jason Andryuk @ 2010-06-29 0:55 UTC (permalink / raw)
To: Sebastian Smolorz; +Cc: kalle.valo, linux-wireless
In-Reply-To: <201006281747.00128.Sebastian.Smolorz@gmx.de>
On Mon, Jun 28, 2010 at 11:46 AM, Sebastian Smolorz
<Sebastian.Smolorz@gmx.de> wrote:
> Jason Andryuk wrote:
>> On Tue, Jun 22, 2010 at 10:51 AM, Sebastian Smolorz
> It does but I must admit that I did not test the direct probing, only the
> authentication.
>
> Which kernel version did you patch?
I used John Linville's wireless-testing tag master-2010-06-24
(2.6.35-rc3). Your patches were included in the tree.
> The problem is that when probed directly, no (real) bssid is coded in the
> frame, only the multicast address. So with a frame of type
> IEEE80211_STYPE_PROBE_REQ we have no chance to decode the bssid because
> mac80211 doesn't give us the needed information. I think in the case of
> direct probing we are lost, only the authentication works with the patch I
> sent. Another solution would be to change mac80211 but that would be a
> special solution for just one driver. It's questionable if this is a viable
> way. On the other hand it would be great to have a working driver again.
How do you bypass the direct probe and go immediately to
authentication? NetworkManager/mac80211 tries the direct probe before
authentication. Without a probe response, mac80211 does not progress
to the actual authentication.
Jason
^ permalink raw reply
* Re: intel 5100/iwlagn bug in 2.6.35-rc2 during large file transfer
From: Richard Farina @ 2010-06-29 3:57 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1277757563.4197.11.camel@rchatre-DESK>
reinette chatre wrote:
> On Mon, 2010-06-28 at 10:01 -0700, Richard Farina wrote:
>
>> reinette chatre wrote:
>>
>>> On Sun, 2010-06-27 at 10:14 -0700, Richard Farina wrote:
>>>
>>>
>>>>> ---
>>>>> drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 5 +++--
>>>>> drivers/net/wireless/iwlwifi/iwl-fh.h | 2 +-
>>>>> 2 files changed, 4 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
>>>>> index 0f292a2..2815ee7 100644
>>>>> --- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
>>>>> +++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
>>>>> @@ -613,7 +613,8 @@ void iwlagn_rx_allocate(struct iwl_priv *priv, gfp_t priority)
>>>>> }
>>>>> spin_unlock_irqrestore(&rxq->lock, flags);
>>>>>
>>>>> - if (rxq->free_count > RX_LOW_WATERMARK)
>>>>> + if ((priority == GFP_ATOMIC) ||
>>>>> + (rxq->free_count > RX_LOW_WATERMARK / 4))
>>>>> gfp_mask |= __GFP_NOWARN;
>>>>>
>>>>>
>>>>>
>>> Here I set the allocation mask to not print _any_ warnings when
>>> allocation is atomic ...
>>>
>>>
>>>
>>>
>>>> [180257.090410] swapper: page allocation failure. order:1, mode:0x4020
>>>> [180257.090414] Pid: 0, comm: swapper Not tainted 2.6.34-pentoo-r2 #2
>>>> [180257.090416] Call Trace:
>>>>
>>>>
>>> ... clearly this is an allocation warning ...
>>>
>>>
>>>
>>>> [180257.090418] <IRQ> [<ffffffff810984c0>]
>>>> __alloc_pages_nodemask+0x571/0x5b9
>>>> [180257.090437] [<ffffffffa05162f3>] iwlagn_rx_allocate+0x98/0x2e0 [iwlagn]
>>>> [180257.090445] [<ffffffffa051668c>] iwlagn_rx_replenish_now+0x16/0x23
>>>> [iwlagn]
>>>>
>>>>
>>> ... but it is an atomic one, which after the patch should not be
>>> printing _any_ warning ...
>>>
>>>
>>>
>> I dunno, I really don't. but I did just verify the patch and it is
>> correct and applied.
>>
>
> Could you please verify that it is the patch below and not an earlier
> patch I sent? Apart from what I mention above there is another strange
> thing in the logs you provide. In your logs you have the message:
>
> iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 40 free buffers remaining.
>
> while the code is:
>
> »-------»-------»-------if ((rxq->free_count <= RX_LOW_WATERMARK / 4) &&
> »-------»-------»------- net_ratelimit())
> »-------»-------»-------»-------IWL_CRIT(priv, "Failed to alloc_pages with %s. Only %u free buffers remaining.\n",
> »-------»-------»-------»-------»------- priority == GFP_ATOMIC ? "GFP_ATOMIC" : "GFP_KERNEL",
> »-------»-------»-------»-------»------- rxq->free_count);
>
> with :
> #define RX_LOW_WATERMARK 128
>
> The message in your log should thus not be there since it should only
> print the message if the free_count less than or equal to 32.
>
>
I verified that I applied the correct patch (for the third time), sad
part is, now it is different... I guess I messed up the first three
times. Anyway, no oops yet but:
[ 3091.463559] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 21 free buffers remaining.
[ 3091.534626] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 0 free buffers remaining.
[ 3593.179843] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 1 free buffers remaining.
[ 3593.307837] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 26 free buffers remaining.
[ 4091.542698] net_ratelimit: 34 callbacks suppressed
[ 4091.542702] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 25 free buffers remaining.
[ 4091.542724] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 3 free buffers remaining.
[ 4091.555285] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 26 free buffers remaining.
[ 4091.555305] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 0 free buffers remaining.
[ 4258.724351] net_ratelimit: 2073 callbacks suppressed
[ 4258.724372] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 0 free buffers remaining.
[ 4258.753286] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 31 free buffers remaining.
[ 4258.753309] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 2 free buffers remaining.
[ 4258.774133] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 28 free buffers remaining.
[ 5165.260524] net_ratelimit: 21 callbacks suppressed
[ 5166.400305] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 4 free buffers remaining.
[ 5167.126059] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 13 free buffers remaining.
[ 5454.561708] net_ratelimit: 4 callbacks suppressed
[ 5455.245019] iwlagn 0000:02:00.0: Failed to alloc_pages with
GFP_ATOMIC. Only 1 free buffers remaining.
I'd certainly list it as improved as it hardly freezes and those aren't
kernel oops. However it should be noted that this test didn't seem to
have nearly the same speed as the previous test (which may well be due
to my internet connection or any number of things having nothing to do
with this patch). Point is, I'd definately like to get a faster test it
to see if it explodes. Assuming it doesn't, how can I help you find out
why it keeps running out of buffers? I'm guessing this isn't expected
behavior...
Thanks,
Rick Farina
> >From 65c459c35332c7039cc84a980e6e04118ba81c04 Mon Sep 17 00:00:00 2001
> From: Reinette Chatre <reinette.chatre@intel.com>
> Date: Thu, 24 Jun 2010 10:48:59 -0700
> Subject: [PATCH] increase low watermark
>
> ---
> drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 5 +++--
> drivers/net/wireless/iwlwifi/iwl-fh.h | 2 +-
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> index 0f292a2..2815ee7 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> @@ -613,7 +613,8 @@ void iwlagn_rx_allocate(struct iwl_priv *priv, gfp_t priority)
> }
> spin_unlock_irqrestore(&rxq->lock, flags);
>
> - if (rxq->free_count > RX_LOW_WATERMARK)
> + if ((priority == GFP_ATOMIC) ||
> + (rxq->free_count > RX_LOW_WATERMARK / 4))
> gfp_mask |= __GFP_NOWARN;
>
> if (priv->hw_params.rx_page_order > 0)
> @@ -627,7 +628,7 @@ void iwlagn_rx_allocate(struct iwl_priv *priv, gfp_t priority)
> "order: %d\n",
> priv->hw_params.rx_page_order);
>
> - if ((rxq->free_count <= RX_LOW_WATERMARK) &&
> + if ((rxq->free_count <= RX_LOW_WATERMARK / 4) &&
> net_ratelimit())
> IWL_CRIT(priv, "Failed to alloc_pages with %s. Only %u free buffers remaining.\n",
> priority == GFP_ATOMIC ? "GFP_ATOMIC" : "GFP_KERNEL",
> diff --git a/drivers/net/wireless/iwlwifi/iwl-fh.h b/drivers/net/wireless/iwlwifi/iwl-fh.h
> index 113c366..431bc58 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-fh.h
> +++ b/drivers/net/wireless/iwlwifi/iwl-fh.h
> @@ -426,7 +426,7 @@
> * RX related structures and functions
> */
> #define RX_FREE_BUFFERS 64
> -#define RX_LOW_WATERMARK 8
> +#define RX_LOW_WATERMARK 128
>
> /* Size of one Rx buffer in host DRAM */
> #define IWL_RX_BUF_SIZE_3K (3 * 1000) /* 3945 only */
>
^ permalink raw reply
* Re: [ath9k-devel] ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Benoit Papillault @ 2010-06-29 6:08 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Björn Smedman, ath9k-devel, linux-wireless
In-Reply-To: <4C29284C.5050707@openwrt.org>
Le 29/06/2010 00:55, Felix Fietkau a écrit :
> On 2010-06-29 12:31 AM, Björn Smedman wrote:
>> Hi all,
>>
>> I'm getting weird values from the debugfs file ieee80211/phy0/tsf: the
>> value goes up and down rather randomly and only the lower 24 bits or
>> so seem to ever be used (see below for details).
>>
>> The only thing running on phy0 is a single ap interface (and the
>> monitor companion that hostapd sets up). I was expecting tsf to
>> increase monotonically until all 64 bits had been used.
>>
>> For a moment I thought it might be the kernel snprintf (on mips)
>> playing a trick on me so I tried the following patch. But the result
>> is the same.
> IMHO the most likely problem source is stuck beacons. Please compile the
> driver with the debug option enabled and load it with
> insmod ath9k debug=0x00000100
>
> - Felix
Humm... I observed a similar behavior a while ago because only the 15
lower bits of rstamp were used when being extended (but rstamp is 32
bits in fact). If so, it has been fixed by Felix in the following commit :
commit a6d2055b02dde1067075795274672720baadd3ca
Author: Felix Fietkau <nbd@openwrt.org>
Date: Sat Jun 12 00:33:54 2010 -0400
ath9k: fix extending the rx timestamp with the hardware TSF
Regards,
Benoit
^ permalink raw reply
* [PATCH] compat: Fix panic caused by NULL pointer derefence in rtnl_fill_ifinfo
From: Rajkumar Manoharan @ 2010-06-29 6:38 UTC (permalink / raw)
To: mcgrof; +Cc: linux-wireless, linux-bluetooth, Rajkumar Manoharan
get stats netdev ops is blindy called for older kernels (< 2.6.29) and
so assigning a NULL pointer from netdev_attach_ops causes a NULL pointer
dereference.
By default, netdev alloc provides an internal stats reference. So fill
this only if ndo_get_stats is defined.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
---
compat/compat-2.6.29.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/compat/compat-2.6.29.c b/compat/compat-2.6.29.c
index f94aed8..2e7e623 100644
--- a/compat/compat-2.6.29.c
+++ b/compat/compat-2.6.29.c
@@ -35,7 +35,8 @@ void netdev_attach_ops(struct net_device *dev,
dev->change_mtu = ops->ndo_change_mtu;
dev->set_mac_address = ops->ndo_set_mac_address;
dev->tx_timeout = ops->ndo_tx_timeout;
- dev->get_stats = ops->ndo_get_stats;
+ if (ops->ndo_get_stats)
+ dev->get_stats = ops->ndo_get_stats;
dev->vlan_rx_register = ops->ndo_vlan_rx_register;
dev->vlan_rx_add_vid = ops->ndo_vlan_rx_add_vid;
dev->vlan_rx_kill_vid = ops->ndo_vlan_rx_kill_vid;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 0/2] at76c50x-usb.c: Fix broken authentication process
From: Sebastian Smolorz @ 2010-06-29 9:17 UTC (permalink / raw)
To: Jason Andryuk; +Cc: kalle.valo, linux-wireless
In-Reply-To: <AANLkTilyntO2L8LPOd_1BO73PLiDQBNbOv3e10gXI0N8@mail.gmail.com>
Jason Andryuk wrote:
> On Mon, Jun 28, 2010 at 11:46 AM, Sebastian Smolorz
>
> <Sebastian.Smolorz@gmx.de> wrote:
> > Jason Andryuk wrote:
> >> On Tue, Jun 22, 2010 at 10:51 AM, Sebastian Smolorz
> >
> > It does but I must admit that I did not test the direct probing, only
> > the authentication.
> >
> > Which kernel version did you patch?
>
> I used John Linville's wireless-testing tag master-2010-06-24
> (2.6.35-rc3). Your patches were included in the tree.
OK.
> > The problem is that when probed directly, no (real) bssid is coded in
> > the frame, only the multicast address. So with a frame of type
> > IEEE80211_STYPE_PROBE_REQ we have no chance to decode the bssid because
> > mac80211 doesn't give us the needed information. I think in the case of
> > direct probing we are lost, only the authentication works with the
> > patch I sent. Another solution would be to change mac80211 but that
> > would be a special solution for just one driver. It's questionable if
> > this is a viable way. On the other hand it would be great to have a
> > working driver again.
>
> How do you bypass the direct probe and go immediately to
> authentication? NetworkManager/mac80211 tries the direct probe before
> authentication. Without a probe response, mac80211 does not progress
> to the actual authentication.
I have one computer on which authentication is always processed without any
preliminary direct probe. I tried that several times and with another
wireless stick, too. On my laptop, the direct probe is processed first but I
use the following workaround:
modprobe at76c50x-usb
iwconfig wlan0 essid <ESSID>
ifconfig wlan0 <IP>
ifconfig wlan0 down
ifconfig wlan0 <IP>
ifconfig wlan0 down
ifconfig wlan0 <IP>
So for me it's necessary to set the IP three times before the interface
works. After the first time the direct probe is processed and fails. After
the second time authentication is tried - but now the direct probe
responses. After the third time, finally, the authentication is successful.
I know, this is very ugly, but maybe a feasible workaround for you, too.
--
Sebastian
^ permalink raw reply
* [RFC 2/3] nl80211: Fix memory leaks
From: Yuri Ershov @ 2010-06-29 11:08 UTC (permalink / raw)
To: johannes; +Cc: ext-yuri.kululin, linux-wireless
In-Reply-To: <cover.1277808543.git.ext-yuri.ershov@nokia.com>
In case of errors during message composing msg should be freed after canceling.
Signed-off-by: Yuri Kululin <ext-yuri.kululin@nokia.com>
Signed-off-by: Yuri Ershov <ext-yuri.ershov@nokia.com>
---
net/wireless/nl80211.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index a999fc1..c6bff6b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2769,6 +2769,7 @@ static int nl80211_get_mesh_params(struct sk_buff *skb,
nla_put_failure:
genlmsg_cancel(msg, hdr);
+ nlmsg_free(msg);
err = -EMSGSIZE;
out:
/* Cleanup */
@@ -2960,6 +2961,7 @@ static int nl80211_get_reg(struct sk_buff *skb, struct genl_info *info)
nla_put_failure:
genlmsg_cancel(msg, hdr);
+ nlmsg_free(msg);
err = -EMSGSIZE;
out:
mutex_unlock(&cfg80211_mutex);
--
1.7.0.4
^ permalink raw reply related
* [RFC 1/3] mac80211: Put some code under MESH macro
From: Yuri Ershov @ 2010-06-29 11:08 UTC (permalink / raw)
To: johannes; +Cc: ext-yuri.kululin, linux-wireless
In-Reply-To: <cover.1277808543.git.ext-yuri.ershov@nokia.com>
In the function ieee80211_subif_start_xmit the logic related with
meshdrlen is under CONFIG_MAC80211_MESH macro, but in one place it isn't.
This is some update for this
Signed-off-by: Yuri Ershov <ext-yuri.ershov@nokia.com>
---
---
net/mac80211/tx.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 698d471..007b76a 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1942,11 +1942,13 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
h_pos += encaps_len;
}
+#ifdef CONFIG_MAC80211_MESH
if (meshhdrlen > 0) {
memcpy(skb_push(skb, meshhdrlen), &mesh_hdr, meshhdrlen);
nh_pos += meshhdrlen;
h_pos += meshhdrlen;
}
+#endif
if (ieee80211_is_data_qos(fc)) {
__le16 *qos_control;
--
1.7.0.4
^ permalink raw reply related
* [RFC 3/3] cfg80211: Update of regulatory request initiator handling
From: Yuri Ershov @ 2010-06-29 11:08 UTC (permalink / raw)
To: johannes; +Cc: ext-yuri.kululin, linux-wireless
In-Reply-To: <cover.1277808543.git.ext-yuri.ershov@nokia.com>
In some cases there could be possible dereferencing freed pointer. The
update is intended to avoid this issue.
Signed-off-by: Yuri Ershov <ext-yuri.ershov@nokia.com>
---
net/wireless/reg.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 1ac2bdd..9ee2be9 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1831,6 +1831,7 @@ static void reg_process_hint(struct regulatory_request *reg_request)
{
int r = 0;
struct wiphy *wiphy = NULL;
+ enum nl80211_reg_initiator initiator = reg_request->initiator;
BUG_ON(!reg_request->alpha2);
@@ -1850,7 +1851,7 @@ static void reg_process_hint(struct regulatory_request *reg_request)
/* This is required so that the orig_* parameters are saved */
if (r == -EALREADY && wiphy &&
wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY)
- wiphy_update_regulatory(wiphy, reg_request->initiator);
+ wiphy_update_regulatory(wiphy, initiator);
out:
mutex_unlock(®_mutex);
mutex_unlock(&cfg80211_mutex);
--
1.7.0.4
^ permalink raw reply related
* [RFC 0/3] Update for some defects
From: Yuri Ershov @ 2010-06-29 11:08 UTC (permalink / raw)
To: johannes; +Cc: ext-yuri.kululin, linux-wireless
Hello,
These are some proposals for wireless code minor defects.
Yuri Ershov (3):
mac80211: Put some code under MESH macro
nl80211: Fix memory leaks
cfg80211: Update of regulatory request initiator handling
net/mac80211/tx.c | 2 ++
net/wireless/nl80211.c | 2 ++
net/wireless/reg.c | 3 ++-
3 files changed, 6 insertions(+), 1 deletions(-)
^ permalink raw reply
* Re: [ath9k-devel] ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Felix Fietkau @ 2010-06-29 11:45 UTC (permalink / raw)
To: Benoit Papillault; +Cc: Björn Smedman, ath9k-devel, linux-wireless
In-Reply-To: <4C298DD2.8010704@free.fr>
On 2010-06-29 8:08 AM, Benoit Papillault wrote:
> Le 29/06/2010 00:55, Felix Fietkau a écrit :
>> On 2010-06-29 12:31 AM, Björn Smedman wrote:
>>> Hi all,
>>>
>>> I'm getting weird values from the debugfs file ieee80211/phy0/tsf: the
>>> value goes up and down rather randomly and only the lower 24 bits or
>>> so seem to ever be used (see below for details).
>>>
>>> The only thing running on phy0 is a single ap interface (and the
>>> monitor companion that hostapd sets up). I was expecting tsf to
>>> increase monotonically until all 64 bits had been used.
>>>
>>> For a moment I thought it might be the kernel snprintf (on mips)
>>> playing a trick on me so I tried the following patch. But the result
>>> is the same.
>> IMHO the most likely problem source is stuck beacons. Please compile the
>> driver with the debug option enabled and load it with
>> insmod ath9k debug=0x00000100
>>
>> - Felix
>
> Humm... I observed a similar behavior a while ago because only the 15
> lower bits of rstamp were used when being extended (but rstamp is 32
> bits in fact). If so, it has been fixed by Felix in the following commit :
Nope, different issue. The TSF extending applies only to rx timestamps,
however Björn has been observing weird TSF values from the hw register.
The Rx TSF timestamp is pretty much irrelevant in AP mode.
- Felix
^ permalink raw reply
* Re: Compat-wireless release for 2010-06-26 is baked
From: Andrei Emeltchenko @ 2010-06-29 12:31 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Compat-wireless cronjob account, linux-wireless, linux-bluetooth
In-Reply-To: <AANLkTin1ZRFgTCylXOYW0HtkOjhXYWmPNZUGrqjMqhKL@mail.gmail.com>
Hi,
On Mon, Jun 28, 2010 at 7:38 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Mon, Jun 28, 2010 at 4:13 AM, Andrei Emeltchenko
> <andrei.emeltchenko.news@gmail.com> wrote:
>> Hi
>>
>> On Sat, Jun 26, 2010 at 10:02 PM, Compat-wireless cronjob account
>> <compat@orbit-lab.org> wrote:
>>
>> Looks like the mail is sent to wrong ML?
>
> Its for BT too.
I think those cron mails are not interesting to BT developers.
-- Andrei
^ permalink raw reply
* Problem with firmware load on ipw2200
From: Larry Finger @ 2010-06-29 13:37 UTC (permalink / raw)
To: wireless
I'm trying to help an ipw2200 user on the openSUSE Wireless Forum and I'm
stuck. The system is failing to load the firmware with error -2 (File or
directory not found). The difficulty is that the required files are
present with the correct permissions.
What system component might be missing and/or borked to get this symptom?
Thanks,
Larry
^ permalink raw reply
* Re: Problem with firmware load on ipw2200
From: John W. Linville @ 2010-06-29 13:49 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
In-Reply-To: <4C29F711.1090306@lwfinger.net>
On Tue, Jun 29, 2010 at 08:37:21AM -0500, Larry Finger wrote:
> I'm trying to help an ipw2200 user on the openSUSE Wireless Forum and I'm
> stuck. The system is failing to load the firmware with error -2 (File or
> directory not found). The difficulty is that the required files are
> present with the correct permissions.
>
> What system component might be missing and/or borked to get this symptom?
selinux?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [RFC 0/3] Update for some defects
From: John W. Linville @ 2010-06-29 13:48 UTC (permalink / raw)
To: Yuri Ershov; +Cc: johannes, ext-yuri.kululin, linux-wireless
In-Reply-To: <cover.1277808543.git.ext-yuri.ershov@nokia.com>
On Tue, Jun 29, 2010 at 03:08:05PM +0400, Yuri Ershov wrote:
> Yuri Ershov (3):
> mac80211: Put some code under MESH macro
> nl80211: Fix memory leaks
> cfg80211: Update of regulatory request initiator handling
These all seem fine to me.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Compat-wireless release for 2010-06-26 is baked
From: Luis R. Rodriguez @ 2010-06-29 15:16 UTC (permalink / raw)
To: Andrei Emeltchenko
Cc: Compat-wireless cronjob account, linux-wireless, linux-bluetooth
In-Reply-To: <AANLkTilbJICU22JK-EMasnDWw-z-vWF3W72VnPtOY5Py@mail.gmail.com>
On Tue, Jun 29, 2010 at 5:31 AM, Andrei Emeltchenko
<andrei.emeltchenko.news@gmail.com> wrote:
> Hi,
>
> On Mon, Jun 28, 2010 at 7:38 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Mon, Jun 28, 2010 at 4:13 AM, Andrei Emeltchenko
>> <andrei.emeltchenko.news@gmail.com> wrote:
>>> Hi
>>>
>>> On Sat, Jun 26, 2010 at 10:02 PM, Compat-wireless cronjob account
>>> <compat@orbit-lab.org> wrote:
>>>
>>> Looks like the mail is sent to wrong ML?
>>
>> Its for BT too.
>
> I think those cron mails are not interesting to BT developers.
OK removed linux-bluetooth from the job.
Luis
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Björn Smedman @ 2010-06-29 15:20 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <4C29284C.5050707@openwrt.org>
2010/6/29 Felix Fietkau <nbd@openwrt.org>:
> IMHO the most likely problem source is stuck beacons. Please compile the
> driver with the debug option enabled and load it with
> insmod ath9k debug=0x00000100
It looks like it could be:
...
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 2 [tsf 1986567
tsftu 1940 intval 100] vif (null)
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 1 [tsf 2012168
tsftu 1965 intval 100] vif (null)
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 0 [tsf 2037767
tsftu 1990 intval 100] vif 80945e70
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 0 [tsf 79033
tsftu 77 intval 100] vif 80945e70
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: missed 1 consecutive beacons
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: resume beacon xmit
after 1 misses
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 3 [tsf 117790
tsftu 115 intval 100] vif (null)
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 2 [tsf 143368
tsftu 140 intval 100] vif (null)
Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 1 [tsf 168967
tsftu 165 intval 100] vif (null)
...
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 1 [tsf 14197768
tsftu 13865 intval 100] vif (null)
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 0 [tsf 14223368
tsftu 13890 intval 100] vif 80945e70
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 3 [tsf 14248967
tsftu 13915 intval 100] vif (null)
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 0 [tsf 79180
tsftu 77 intval 100] vif 80945e70
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: missed 1 consecutive beacons
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: resume beacon xmit
after 1 misses
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 3 [tsf 117791
tsftu 115 intval 100] vif (null)
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 2 [tsf 143366
tsftu 140 intval 100] vif (null)
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 1 [tsf 168967
tsftu 165 intval 100] vif (null)
Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 0 [tsf 194567
tsftu 190 intval 100] vif 80945e70
...
What can cause a missed beacon? Are they just a "fact of life"?
In any case I can't find any code that resets the tsf in this (single
missed beacon) case. Will the hardware reset the tsf automatically
whenever a single beacon is missed? Isn't that a bit overkill? Will it
not cause problems for clients?
> - Felix
/Björn
^ permalink raw reply
* Re: [PATCH] compat: Fix panic caused by NULL pointer derefence in rtnl_fill_ifinfo
From: Luis R. Rodriguez @ 2010-06-29 15:21 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: mcgrof, linux-wireless, linux-bluetooth
In-Reply-To: <1277793487-9071-1-git-send-email-rmanoharan@atheros.com>
On Mon, Jun 28, 2010 at 11:38 PM, Rajkumar Manoharan
<rmanoharan@atheros.com> wrote:
> get stats netdev ops is blindy called for older kernels (< 2.6.29) and
> so assigning a NULL pointer from netdev_attach_ops causes a NULL pointer
> dereference.
>
> By default, netdev alloc provides an internal stats reference. So fill
> this only if ndo_get_stats is defined.
>
> Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
> ---
> compat/compat-2.6.29.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/compat/compat-2.6.29.c b/compat/compat-2.6.29.c
> index f94aed8..2e7e623 100644
> --- a/compat/compat-2.6.29.c
> +++ b/compat/compat-2.6.29.c
> @@ -35,7 +35,8 @@ void netdev_attach_ops(struct net_device *dev,
> dev->change_mtu = ops->ndo_change_mtu;
> dev->set_mac_address = ops->ndo_set_mac_address;
> dev->tx_timeout = ops->ndo_tx_timeout;
> - dev->get_stats = ops->ndo_get_stats;
> + if (ops->ndo_get_stats)
> + dev->get_stats = ops->ndo_get_stats;
If ops->ndo_get_stats is NULL then dev->get_stats will be set to NULL.
Do you know for sure this fixes something? If so can you explain how?
I used to have a macro that checked for not NULL and if true set the
callback but then later realized after Johannes poked me that this is
silly given that if the op is NULL you are just setting it to NULL.
I don't see the potential crash here.
Luis
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Felix Fietkau @ 2010-06-29 15:55 UTC (permalink / raw)
To: Björn Smedman; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <AANLkTint2L1xSMughBA5aHCFMRB5KMC8EfwcxJJU5XYW@mail.gmail.com>
On 2010-06-29 5:20 PM, Björn Smedman wrote:
> 2010/6/29 Felix Fietkau <nbd@openwrt.org>:
>> IMHO the most likely problem source is stuck beacons. Please compile the
>> driver with the debug option enabled and load it with
>> insmod ath9k debug=0x00000100
>
> It looks like it could be:
>
> ...
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 2 [tsf 1986567
> tsftu 1940 intval 100] vif (null)
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 1 [tsf 2012168
> tsftu 1965 intval 100] vif (null)
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 0 [tsf 2037767
> tsftu 1990 intval 100] vif 80945e70
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 0 [tsf 79033
> tsftu 77 intval 100] vif 80945e70
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: missed 1 consecutive beacons
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: resume beacon xmit
> after 1 misses
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 3 [tsf 117790
> tsftu 115 intval 100] vif (null)
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 2 [tsf 143368
> tsftu 140 intval 100] vif (null)
> Jan 1 00:06:21 OpenWrt user.debug kernel: ath: slot 1 [tsf 168967
> tsftu 165 intval 100] vif (null)
> ...
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 1 [tsf 14197768
> tsftu 13865 intval 100] vif (null)
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 0 [tsf 14223368
> tsftu 13890 intval 100] vif 80945e70
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 3 [tsf 14248967
> tsftu 13915 intval 100] vif (null)
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 0 [tsf 79180
> tsftu 77 intval 100] vif 80945e70
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: missed 1 consecutive beacons
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: resume beacon xmit
> after 1 misses
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 3 [tsf 117791
> tsftu 115 intval 100] vif (null)
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 2 [tsf 143366
> tsftu 140 intval 100] vif (null)
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 1 [tsf 168967
> tsftu 165 intval 100] vif (null)
> Jan 1 00:09:08 OpenWrt user.debug kernel: ath: slot 0 [tsf 194567
> tsftu 190 intval 100] vif 80945e70
> ...
>
> What can cause a missed beacon? Are they just a "fact of life"?
>
> In any case I can't find any code that resets the tsf in this (single
> missed beacon) case. Will the hardware reset the tsf automatically
> whenever a single beacon is missed? Isn't that a bit overkill? Will it
> not cause problems for clients?
One beacon miss should never cause a TSF reset. Only a lot of
consecutive beacon misses trigger a hardware reset, which then resets
the TSF. Looking at your log, it appears that the beacon miss is a
symptom rather than a cause of the TSF jumps.
Can you add a debug statement to the hw reset function to see if it's
called before the TSF jumps?
- Felix
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox