* Re: [PATCH 0/2] at76c50x-usb.c: Fix broken authentication process
From: Jason Andryuk @ 2010-06-28 0:38 UTC (permalink / raw)
To: Sebastian Smolorz; +Cc: kalle.valo, linux-wireless
In-Reply-To: <201006221651.24853.Sebastian.Smolorz@gmx.de>
On Tue, Jun 22, 2010 at 10:51 AM, Sebastian Smolorz
<Sebastian.Smolorz@gmx.de> wrote:
> Fix authentication process of wireless driver at76c50x-usb.c which was broken
> since kernel 2.6.31
Thanks for working on this, but unfortunately it does not work with my
Linksys WUSB11. Does it work for you?
[ 168.420082] usb 4-1: new full speed USB device using uhci_hcd and address 2
[ 168.719582] Atmel at76x USB Wireless LAN Driver 0.17 loading
[ 168.743011] usb 4-1: using firmware atmel_at76c503-i3861.bin
(version 0.90.0-44)
[ 168.746784] phy1: Selected rate control algorithm 'minstrel'
[ 168.747410] phy1: USB 4-1:1.0, MAC 00:06:25:00:6a:7a, firmware 0.90.0-2
[ 168.747413] phy1: regulatory domain 0x10: FCC (USA)
[ 168.747434] usbcore: registered new interface driver at76c50x-usb
[ 168.803980] udev: renamed network interface wlan0 to wlan3
[ 168.837883] ADDRCONF(NETDEV_UP): wlan3: link is not ready
[ 274.423484] wlan3: direct probe to 00:13:46:08:8a:6e (try 1)
[ 274.622558] wlan3: direct probe to 00:13:46:08:8a:6e (try 2)
[ 274.822600] wlan3: direct probe to 00:13:46:08:8a:6e (try 3)
[ 275.022557] wlan3: direct probe to 00:13:46:08:8a:6e timed out
[ 284.694487] wlan3: direct probe to 00:13:46:08:8a:6e (try 1)
[ 284.900075] wlan3: direct probe to 00:13:46:08:8a:6e (try 2)
[ 285.105548] wlan3: direct probe to 00:13:46:08:8a:6e (try 3)
[ 285.302565] wlan3: direct probe to 00:13:46:08:8a:6e timed out
[ 294.954450] wlan3: direct probe to 00:13:46:08:8a:6e (try 1)
[ 295.152564] wlan3: direct probe to 00:13:46:08:8a:6e (try 2)
[ 295.352559] wlan3: direct probe to 00:13:46:08:8a:6e (try 3)
[ 295.552556] wlan3: direct probe to 00:13:46:08:8a:6e timed out
> + /* The following code lines are important when the device is going to
> + * authenticate with a new bssid. The driver must send CMD_JOIN before
> + * an authentication frame is transmitted. For this to succeed, the
> + * correct bssid of the AP must be known. As mac80211 does not inform
> + * drivers about the bssid prior to the authentication process the
> + * following workaround is necessary. If the TX frame is an
> + * authentication frame extract the bssid and send the CMD_JOIN. */
> + if (mgmt->frame_control & cpu_to_le16(IEEE80211_STYPE_AUTH)) {
> + if (compare_ether_addr(priv->bssid, mgmt->bssid)) {
> + memcpy(priv->bssid, mgmt->bssid, ETH_ALEN);
> + ieee80211_queue_work(hw, &priv->work_join_bssid);
> + return NETDEV_TX_BUSY;
> + }
> + }
> +
The check for IEEE80211_STYPE_AUTH may be insufficient since direct
probe is sent with frame control IEEE80211_STYPE_PROBE_REQ. Maybe a
better check would be comparing struct ieee80211_work.type to
IEEE80211_WORK_DIRECT_PROBE or IEEE80211_WORK_AUTH? I am not sure if
that is accessible in the driver's tx function though.
With the frame_control check modified for either IEEE80211_STYPE_AUTH
or IEEE80211_STYPE_PROBE_REQ, it is still unsuccessful.
at76_work_join_bssid is called between the first and second direct
probe attempt. However, the CMD_JOIN command is not in the log.
Presumably that occurs because the BSSID pulled from the PROBE_REQ is
ff:ff:ff:ff:ff:ff which fails the is_valid_ether_addr(priv->bssid)
check in at76_work_join_bssid.
http://lxr.linux.no/#linux+v2.6.34/include/linux/etherdevice.h#L100
I'm glad someone is working on this.
Jason
^ permalink raw reply
* Re: ATH5k - Signal measurement reports wrong values - thanks for a fix
From: Bruno Randolf @ 2010-06-28 1:21 UTC (permalink / raw)
To: Jaroslav Fojtik; +Cc: linux-wireless
In-Reply-To: <4C26FD91.10140.F4D6B@jafojtik.seznam.cz>
On Sun June 27 2010 16:28:17 Jaroslav Fojtik wrote:
> Dear Bruno,
>
> > > I hope that this patch would not influence performance or any other
> > > functionality.
> >
> > no it just fixes a regression i have introduced in an earlier change.
> > thanks for reporting and testing this! i will send the patch for
> > inclusion on monday, then it might take some time (few days to weeks)
> > until it apperars in compat- wireless.
>
> Thank you for explanation.
> The patch surely improves signal strength measurement and I recomend it.
>
> Anyway, when you look at the magenta line here:
> http://78.108.103.11:11080/cgi-bin/rodga_1day_big.cgi
>
> There are big drops in measured signal. Did you fix all places?
>
> Before this patch there were short peeks from -78dB to -71dB.
> After patch there are short measurement drops from -62dB to -70dB.
>
> The week charting simply averages it:
> http://78.108.103.11:11080/cgi-bin/rodga_1week_big.cgi
i guess this must be the same situation as before, no?
how many antennas do you have attached to your device? it might be interesting
to check if you get more consistent signal measurements by disabling antenna
diversity, setting it to a fixed antenna. you can do this by using a debugfs
file "echo fixed-a > /sys/kernel/debug/ath5k/phy0/antenna" (or "fixed-b")...
btw: when the signal measurement was low, did you see any negative impact on
the thruput as well?
bruno
^ permalink raw reply
* [PATCH] ath5k: fix antenna div gc for <= AR5K_SREV_PHY_2413
From: Bruno Randolf @ 2010-06-28 2:01 UTC (permalink / raw)
To: linville; +Cc: ath5k-devel, linux-wireless
In commit 39d5b2c83ca8904b6826a0713263a4e5a9c0730a "ath5k: update
AR5K_PHY_RESTART_DIV_GC values to match masks" i introduced a regression on PHY
chips older than AR5K_SREV_PHY_5413, which caused signal values to be about
10dB less that before. This patch reverts the AR5K_PHY_RESTART_DIV_GC values to
the same values which were effectively used before (without the bitmask
mistake). This brings signal levels back to normal on these PHY chips.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
drivers/net/wireless/ath/ath5k/phy.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/phy.c b/drivers/net/wireless/ath/ath5k/phy.c
index 73c4fcd..6284c38 100644
--- a/drivers/net/wireless/ath/ath5k/phy.c
+++ b/drivers/net/wireless/ath/ath5k/phy.c
@@ -1768,7 +1768,7 @@ ath5k_hw_set_fast_div(struct ath5k_hw *ah, u8 ee_mode, bool enable)
if (enable) {
AR5K_REG_WRITE_BITS(ah, AR5K_PHY_RESTART,
- AR5K_PHY_RESTART_DIV_GC, 1);
+ AR5K_PHY_RESTART_DIV_GC, 4);
AR5K_REG_ENABLE_BITS(ah, AR5K_PHY_FAST_ANT_DIV,
AR5K_PHY_FAST_ANT_DIV_EN);
^ permalink raw reply related
* Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n
From: Björn Smedman @ 2010-06-28 10:20 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Derek Smithies, Benoit PAPILLAULT,
Luis R. Rodriguez, Christian Lamparter, Johannes Berg,
ath9k-devel
In-Reply-To: <4C27E8E8.8040606@openwrt.org>
2010/6/28 Felix Fietkau <nbd@openwrt.org>:
> On 2010-06-28 2:01 AM, Björn Smedman wrote:
[snip]
>> I guess the real solution is your rewrite... But in the mean time
>> perhaps we can memcpy the tx_info control from the last subframe to
>> the first before calling ath_buf_set_rate() in ath_tx_sched_aggr()?
>> Could that have any side effects? It could make the aggregate size go
>> over the 4 ms limit I guess... How bad is that?
> There's an easy solution which would take into account the 4ms frame
> limit properly, and which could work without any memcpy() hacks:
>
> I could just grab a pointer to the last buffer in the tid queue in the
> ath_tx_sched_aggr() function, then pass it to ath_lookup_rate() via
> ath_tx_form_aggr(), and also to ath_buf_set_rate(). Then I make those
> functions use this last buffer as reference for the rate lookup.
Sounds better to use the rate control from the last buffer in the tid
queue. But be careful if you don't memcpy it to the first frame of the
aggregate then the feedback calculated in ath_tx_rc_status() after tx
will be incorrect again, no?
> - Felix
/Björn
^ permalink raw reply
* Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n
From: Felix Fietkau @ 2010-06-28 10:27 UTC (permalink / raw)
To: Björn Smedman
Cc: linux-wireless, Derek Smithies, Benoit PAPILLAULT,
Luis R. Rodriguez, Christian Lamparter, Johannes Berg,
ath9k-devel
In-Reply-To: <AANLkTinoz66aXYBSlwVtTnJBs1u-4FfOCphHTZONHc4B@mail.gmail.com>
On 2010-06-28 12:20 PM, Björn Smedman wrote:
> 2010/6/28 Felix Fietkau <nbd@openwrt.org>:
>> On 2010-06-28 2:01 AM, Björn Smedman wrote:
> [snip]
>>> I guess the real solution is your rewrite... But in the mean time
>>> perhaps we can memcpy the tx_info control from the last subframe to
>>> the first before calling ath_buf_set_rate() in ath_tx_sched_aggr()?
>>> Could that have any side effects? It could make the aggregate size go
>>> over the 4 ms limit I guess... How bad is that?
>> There's an easy solution which would take into account the 4ms frame
>> limit properly, and which could work without any memcpy() hacks:
>>
>> I could just grab a pointer to the last buffer in the tid queue in the
>> ath_tx_sched_aggr() function, then pass it to ath_lookup_rate() via
>> ath_tx_form_aggr(), and also to ath_buf_set_rate(). Then I make those
>> functions use this last buffer as reference for the rate lookup.
>
> Sounds better to use the rate control from the last buffer in the tid
> queue. But be careful if you don't memcpy it to the first frame of the
> aggregate then the feedback calculated in ath_tx_rc_status() after tx
> will be incorrect again, no?
Right. I intend to let ath_buf_set_rate() set the rates array of the
first subframe accordingly.
- Felix
^ permalink raw reply
* Re: Compat-wireless release for 2010-06-26 is baked
From: Andrei Emeltchenko @ 2010-06-28 11:13 UTC (permalink / raw)
To: Compat-wireless cronjob account; +Cc: linux-wireless, linux-bluetooth
In-Reply-To: <20100626190240.648EA42E2C@repository3.orbit-lab.org>
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?
-- Andrei
>
> compat-wireless code metrics
>
> 494345 - Total upstream lines of code being pulled
> 1407 - backport code changes
> 1174 - backport code additions
> 233 - backport code deletions
> 5765 - backport from compat module
> 7172 - total backport code
> 1.4508 - % of code consists of backport work
> 1218 - Crap changes not yet posted
> 1179 - Crap additions not yet posted
> 39 - Crap deletions not yet posted
> 0.2464 - % of crap code
>
> Base tree: linux-next.git
> Base tree version: next-20100625
> compat-wireless release: compat-wireless-2010-06-17-6-g8a97897
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Fwd: mesh configuration information element is wrong?
From: Iuri Diniz @ 2010-06-28 12:48 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <20100626150800.GA20900@jm.kir.nu>
On Sat, Jun 26, 2010 at 12:08 PM, Jouni Malinen <j@w1.fi> wrote:
> Draft 3 is quite old..
>
Do you know if I buy Draft 6, it will be full (last complete reference
about 802.11s) or will only be only a "diff" to draft 5?
--
Iuri Diniz
^ permalink raw reply
* Re: [PATCH 0/2] at76c50x-usb.c: Fix broken authentication process
From: Sebastian Smolorz @ 2010-06-28 15:46 UTC (permalink / raw)
To: Jason Andryuk; +Cc: kalle.valo, linux-wireless
In-Reply-To: <AANLkTilsEl-smRtQEU8obOO6GDoWzKYHyFYQYO5Lfpps@mail.gmail.com>
Jason Andryuk wrote:
> On Tue, Jun 22, 2010 at 10:51 AM, Sebastian Smolorz
>
> <Sebastian.Smolorz@gmx.de> wrote:
> > Fix authentication process of wireless driver at76c50x-usb.c which was
> > broken since kernel 2.6.31
>
> Thanks for working on this, but unfortunately it does not work with my
> Linksys WUSB11.
Thanks for testing the patch.
> Does it work for you?
It does but I must admit that I did not test the direct probing, only the
authentication.
Which kernel version did you patch?
>
> [ 168.420082] usb 4-1: new full speed USB device using uhci_hcd and
> address 2 [ 168.719582] Atmel at76x USB Wireless LAN Driver 0.17
> loading
> [ 168.743011] usb 4-1: using firmware atmel_at76c503-i3861.bin
> (version 0.90.0-44)
> [ 168.746784] phy1: Selected rate control algorithm 'minstrel'
> [ 168.747410] phy1: USB 4-1:1.0, MAC 00:06:25:00:6a:7a, firmware
> 0.90.0-2 [ 168.747413] phy1: regulatory domain 0x10: FCC (USA)
> [ 168.747434] usbcore: registered new interface driver at76c50x-usb
> [ 168.803980] udev: renamed network interface wlan0 to wlan3
> [ 168.837883] ADDRCONF(NETDEV_UP): wlan3: link is not ready
> [ 274.423484] wlan3: direct probe to 00:13:46:08:8a:6e (try 1)
> [ 274.622558] wlan3: direct probe to 00:13:46:08:8a:6e (try 2)
> [ 274.822600] wlan3: direct probe to 00:13:46:08:8a:6e (try 3)
> [ 275.022557] wlan3: direct probe to 00:13:46:08:8a:6e timed out
> [ 284.694487] wlan3: direct probe to 00:13:46:08:8a:6e (try 1)
> [ 284.900075] wlan3: direct probe to 00:13:46:08:8a:6e (try 2)
> [ 285.105548] wlan3: direct probe to 00:13:46:08:8a:6e (try 3)
> [ 285.302565] wlan3: direct probe to 00:13:46:08:8a:6e timed out
> [ 294.954450] wlan3: direct probe to 00:13:46:08:8a:6e (try 1)
> [ 295.152564] wlan3: direct probe to 00:13:46:08:8a:6e (try 2)
> [ 295.352559] wlan3: direct probe to 00:13:46:08:8a:6e (try 3)
> [ 295.552556] wlan3: direct probe to 00:13:46:08:8a:6e timed out
>
> > + /* The following code lines are important when the device is
> > going to + * authenticate with a new bssid. The driver must
> > send CMD_JOIN before + * an authentication frame is
> > transmitted. For this to succeed, the + * correct bssid of the
> > AP must be known. As mac80211 does not inform + * drivers about
> > the bssid prior to the authentication process the + * following
> > workaround is necessary. If the TX frame is an + *
> > authentication frame extract the bssid and send the CMD_JOIN. */ +
> > if (mgmt->frame_control & cpu_to_le16(IEEE80211_STYPE_AUTH)) { +
> > if (compare_ether_addr(priv->bssid, mgmt->bssid)) { +
> > memcpy(priv->bssid, mgmt->bssid, ETH_ALEN); +
> > ieee80211_queue_work(hw, &priv->work_join_bssid); +
> > return NETDEV_TX_BUSY;
> > + }
> > + }
> > +
>
> The check for IEEE80211_STYPE_AUTH may be insufficient since direct
> probe is sent with frame control IEEE80211_STYPE_PROBE_REQ. Maybe a
> better check would be comparing struct ieee80211_work.type to
> IEEE80211_WORK_DIRECT_PROBE or IEEE80211_WORK_AUTH? I am not sure if
> that is accessible in the driver's tx function though.
No, it's not accessible by the driver.
>
> With the frame_control check modified for either IEEE80211_STYPE_AUTH
> or IEEE80211_STYPE_PROBE_REQ, it is still unsuccessful.
> at76_work_join_bssid is called between the first and second direct
> probe attempt. However, the CMD_JOIN command is not in the log.
> Presumably that occurs because the BSSID pulled from the PROBE_REQ is
> ff:ff:ff:ff:ff:ff which fails the is_valid_ether_addr(priv->bssid)
> check in at76_work_join_bssid.
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.
--
Sebastian
^ permalink raw reply
* Re: intel 5100/iwlagn bug in 2.6.35-rc2 during large file transfer
From: reinette chatre @ 2010-06-28 16:27 UTC (permalink / raw)
To: Richard Farina; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4C278704.5040604@gmail.com>
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 am very confused now.
Reinette
^ permalink raw reply
* 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
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