headers
Rafael J. Wysocki | 1 Feb 01:18
Picon
Gravatar

2.6.33-rc6: Reported regressions from 2.6.32

This message contains a list of some regressions from 2.6.32, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.32, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.

Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2010-02-01       85       26          21
  2010-01-24       75       29          23
  2010-01-10       55       33          21
  2009-12-29       36       34          27

Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15202
Subject		: lockdep warning during elevator_switch
Submitter	: Hugh Dickins <hugh.dickins@...>
Date		: 2010-01-31 23:55 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=126498212613051&w=4
(Continue reading)

Permalink | Reply | 75 comments |
headers
PAN Sunny S K | 1 Feb 05:06
Picon
Picon

Re: Building of compat-wireless-old in 2.6.25 BSP kernel for PowerPC architecture

Hi Pavel,

It is unfortunate that the ath_pci is dependent on ath. Moreover, after
some trial, found that the rfkill_backport and cfg80211 also have problem
in loading which is possibly due to the lacking of other symbolic link in
the current kernel or other modules.
Since other issues (iw, libnl... etc) makes the difficulties in
integrating ath9k into the current LTIB harder than using of OpenWrt with
the latest kernel  (although still have some problem in building of
OpenWrt for the platform). I've since moved the effort to building of
OpenWrt.
Anyhow, many thanks for the advice and below please find a snapshot of the
error output from the ath9k with kernel 2.6.25 from LTIB for your future
reference.

ath: Unknown symbol wiphy_apply_custom_regulatory

ath: Unknown symbol freq_reg_info

ath_pci: Unknown symbol ath_config_crypto_get

ath_pci: Unknown symbol ath_config_ioctl_getwscie

ath_pci: Unknown symbol ath_config_ioctl_addmac

ath_pci: Unknown symbol ath_config_ioctl_delkey

ath_pci: Unknown symbol ath_config_set_txmode

ath_pci: Unknown symbol ath_config_ioctl_getkey
(Continue reading)

Permalink | Reply | 4 comments |
headers
Gábor Stefanik | 1 Feb 05:14
Picon

Re: Building of compat-wireless-old in 2.6.25 BSP kernel for PowerPC architecture

On Mon, Feb 1, 2010 at 5:06 AM, PAN Sunny S K <sunnypan@...> wrote:
> Hi Pavel,
>
> It is unfortunate that the ath_pci is dependent on ath.

No, you shouldn't even try to load ath_pci - ath_pci is part of
Madwifi, you need to load ath9k instead.

BTW are you loading the modules using modprobe or insmod?

> Moreover, after
> some trial, found that the rfkill_backport and cfg80211 also have problem
> in loading which is possibly due to the lacking of other symbolic link in
> the current kernel or other modules.
> Since other issues (iw, libnl... etc) makes the difficulties in
> integrating ath9k into the current LTIB harder than using of OpenWrt with
> the latest kernel  (although still have some problem in building of
> OpenWrt for the platform). I've since moved the effort to building of
> OpenWrt.
> Anyhow, many thanks for the advice and below please find a snapshot of the
> error output from the ath9k with kernel 2.6.25 from LTIB for your future
> reference.
>
> ath: Unknown symbol wiphy_apply_custom_regulatory
>
> ath: Unknown symbol freq_reg_info
>
> ath_pci: Unknown symbol ath_config_crypto_get
>
> ath_pci: Unknown symbol ath_config_ioctl_getwscie
(Continue reading)

Permalink | Reply | 3 comments |
headers
PAN Sunny S K | 1 Feb 05:29
Picon
Picon

Re: Building of compat-wireless-old in 2.6.25 BSP kernel for PowerPC architecture

> On Mon, Feb 1, 2010 at 5:06 AM, PAN Sunny S K <sunnypan@...> wrote:
>> Hi Pavel,
>>
>> It is unfortunate that the ath_pci is dependent on ath.
>
> No, you shouldn't even try to load ath_pci - ath_pci is part of
> Madwifi, you need to load ath9k instead.
>
> BTW are you loading the modules using modprobe or insmod?
>

Thanks, both insmod and modprobe for ath produces the same result:

ath: Unknown symbol wiphy_apply_custom_regulatory
ath: Unknown symbol freq_reg_info

modprobe for rfkill_backport and cfg80211 even produce not found error and
only insmod will produce the provided snapshot.

>> Moreover, after
>> some trial, found that the rfkill_backport and cfg80211 also have
>> problem
>> in loading which is possibly due to the lacking of other symbolic link
>> in
>> the current kernel or other modules.
>> Since other issues (iw, libnl... etc) makes the difficulties in
>> integrating ath9k into the current LTIB harder than using of OpenWrt
>> with
>> the latest kernel  (although still have some problem in building of
>> OpenWrt for the platform). I've since moved the effort to building of
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sujith | 1 Feb 06:05
Favicon

[PATCH] ath9k: fix PAE frame handling

Felix Fietkau wrote:
> ath9k's tx handling code contains a special case for PAE frames, which
> looks like it was intended to be improving reliability by excluding
> them from aggregates.
> What it actually did is the opposite: By assigning a faulty sequence
> number, yet still keeping it as a qos-frame, it caused bogus packet
> reordering, which broke WPA rekeying.
> The special case handling is completely unnecessary, so this patch
> removes it.

Sending PAE frames as part of an aggregate broke crypto with several APs.
Assigning the correct seq. number should work, no ?

Something like the patch below. Can you check if it fixes your issue ?
Though, removing the seq. number mess in the driver would be great. :D

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index a6893cf..cb6d982 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1610,7 +1610,7 @@ static int ath_tx_setup_buffer(struct ieee80211_hw *hw, struct ath_buf *bf,
 		bf->bf_frmlen -= padsize;
 	}

-	if (conf_is_ht(&hw->conf) && !is_pae(skb))
+	if (conf_is_ht(&hw->conf))
 		bf->bf_state.bf_type |= BUF_HT;

 	bf->bf_flags = setup_tx_flags(sc, skb, txctl->txq);
@@ -1696,7 +1696,7 @@ static void ath_tx_start_dma(struct ath_softc *sc, struct ath_buf *bf,
(Continue reading)

Permalink | Reply | 7 comments |
headers
Felix Fietkau | 1 Feb 06:16

Re: [PATCH] ath9k: fix PAE frame handling

On 2010-02-01 6:05 AM, Sujith wrote:
> Felix Fietkau wrote:
>> ath9k's tx handling code contains a special case for PAE frames, which
>> looks like it was intended to be improving reliability by excluding
>> them from aggregates.
>> What it actually did is the opposite: By assigning a faulty sequence
>> number, yet still keeping it as a qos-frame, it caused bogus packet
>> reordering, which broke WPA rekeying.
>> The special case handling is completely unnecessary, so this patch
>> removes it.
> 
> Sending PAE frames as part of an aggregate broke crypto with several APs.
> Assigning the correct seq. number should work, no ?
> 
> Something like the patch below. Can you check if it fixes your issue ?
> Though, removing the seq. number mess in the driver would be great. :D
Works for me. Tested it with a really short rekey interval, and I'm
getting no packet loss or connection interruption.

- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Holger Schurig | 1 Feb 08:47
Picon

Re: Multiple SSID on same phy

> Hmmm, I would put the odds at that happening about 100,000:1
> (if not more) 

That's described as a standard setup for Cisco APs, e.g. one with 
WEP or even open on one VLAN, which gives you just an internet 
connection. And another with WPA2-PSK or WPA-Enterprise to 
connect to the company network.

And I've seen this setup in "real life" quite a few times.

--

-- 
http://www.holgerschurig.de
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
fengzeheng | 1 Feb 10:09
Picon

time-out for authentication

hi, All
    our project import marvell sd8686 chipset , and we meet some
problems about authentication and connect to a D-Link AP.  first the
marvell wireless card authentication(open auth) to D-Link AP, and if
D-Link AP send authentication packet to marvell card after 1 seconds ,
then marvell wireless card doesn't send any associate message to
D-Link. and if D-Link AP response this authentication message very
quickly in mini-seconds,  then marvell wireless card will send
associate message and connect to AP. so how long  will marvell
wireless card  wait for the AP's authentication response ?
    thanks
--
Best Regards
Feng zeheng
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Vasanthakumar Thiagarajan | 1 Feb 14:19
Favicon

[PATCH] mac80211: Don't call rate control when HW handles it

From: Vasanthakumar <vasanth@...>

Rate control should not be called to update the tx status
when HW does the RC.

Signed-off-by: Vasanthakumar <vasanth@...>
---
 net/mac80211/rate.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/net/mac80211/rate.h b/net/mac80211/rate.h
index 669dddd..998cf7a 100644
--- a/net/mac80211/rate.h
+++ b/net/mac80211/rate.h
@@ -44,6 +44,10 @@ static inline void rate_control_tx_status(struct ieee80211_local *local,
 	struct rate_control_ref *ref = local->rate_ctrl;
 	struct ieee80211_sta *ista = &sta->sta;
 	void *priv_sta = sta->rate_ctrl_priv;
+
+	if (!ref)
+		return;
+
 	ref->ops->tx_status(ref->priv, sband, ista, priv_sta, skb);
 }

--

-- 
1.6.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernhard Reiter | 1 Feb 16:52
Picon
Gravatar

ath9k/PCI 168C:002C

hi,

i'm currently setting up karmic (64bit) an asus eeepc 1005p, and i've
found the following in the debian wiki:
http://wiki.debian.org/DebianEeePC/Model/1005P
i'm giving this laptop to another person on wednesday, but until then, i
might try to compile the ath9k module with the suggested addition of
that PCI id.

unfortunately, i haven't really found anything on how to do this (in a
least-invasive fashion). i've looked
into /usr/src/linux-headers-2.6.31-17/drivers/net/wireless/ath/ath9k,
but there's only a Kconfig and a Makefile, but no sources.

can you people help me modify, compile and test this module?

bernhard reiter
ps please cc, i'm not a list subscriber

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 5 comments |

Gmane