headers
Zhu Yi | 1 Sep 10:24
Picon
Favicon

Re: frequent iwl3945 microcode errors

On Sat, 2008-08-30 at 10:32 +0200, Brian Crowley wrote:
> 
> Getting a bunch of microcode errors, every few minutes, sometimes
> leading to a hung system.  Seems to begin with psmouse failed resync..
> noticed resync problem happens when the network card is doing
> something like scanning or reestablishing link and am quite certain is
> related.. no resync failures when wireless card turned off. Here two
> iterations that ended up with a hang, ultimately degrading and forcing
> me to do a hard restart:

We have just released a new uCode for 3945 today. Maybe you want to try
it. Also, please load the module with debug=0x43fff when you attach the
dmesg. It dumps more uCode debug info.
http://intellinuxwireless.org/index.php?n=Downloads

Thanks,
-yi

--
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
Senthil Balasubramanian | 1 Sep 16:15
Favicon

[PATCH] ath9k: Incorrect key used when group and pairwise ciphers are different.

Updating sc_keytype multiple times when groupwise and pairwise
ciphers are different results in incorrect pairwise key type
assumed for TX control and normal ping fails. This works fine
for cases where both groupwise and pairwise ciphers are same.

Also use mac80211 provided enums for key length calculation.

Signed-off-by: Senthil Balasubramanian <senthilkumar@...>
---
 drivers/net/wireless/ath9k/hw.c   |    8 ++++----
 drivers/net/wireless/ath9k/main.c |    6 ++++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath9k/hw.c b/drivers/net/wireless/ath9k/hw.c
index 2578411..4ccbbc0 100644
--- a/drivers/net/wireless/ath9k/hw.c
+++ b/drivers/net/wireless/ath9k/hw.c
@@ -7236,15 +7236,15 @@ ath9k_hw_set_keycache_entry(struct ath_hal *ah, u16 entry,
 		}
 		break;
 	case ATH9K_CIPHER_WEP:
-		if (k->kv_len < 40 / NBBY) {
+		if (k->kv_len < LEN_WEP40) {
 			DPRINTF(ah->ah_sc, ATH_DBG_KEYCACHE,
 				 "%s: WEP key length %u too small\n",
 				 __func__, k->kv_len);
 			return false;
 		}
-		if (k->kv_len <= 40 / NBBY)
+		if (k->kv_len <= LEN_WEP40)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Senthil Balasubramanian | 1 Sep 16:28
Favicon

[PATCH] ath9: Fix ath_rx_flush_tid() for IRQs disabled kernel warning message.

This patch addresses an issue with the locking order. ath_rx_flush_tid()
uses spin_lock/unlock_bh when IRQs are disabled in sta_notify by mac80211.

As node clean up is still pending with ath9k and this problematic portion
of the code is expected to change anyway, thinking of a proper fix may not
be worthwhile. So having this interim fix helps the users to get rid of the
kernel warning message.

Pasted the kernel warning message for reference.

kernel: ath0: No ProbeResp from current AP 00:1b:11:60:7a:3d - assume out of range
kernel: ------------[ cut here ]------------
kernel: WARNING: at kernel/softirq.c:136 local_bh_enable+0x3c/0xab()
kernel: Pid: 1029, comm: ath9k Not tainted 2.6.27-rc4-wt-w1fi-wl
kernel:
kernel: Call Trace:
kernel:  [<ffffffff802278d8>] warn_on_slowpath+0x51/0x77
kernel:  [<ffffffff80224c51>] check_preempt_wakeup+0xf3/0x123
kernel:  [<ffffffff80239658>] autoremove_wake_function+0x9/0x2e
kernel:  [<ffffffff8022c281>] local_bh_enable+0x3c/0xab
kernel:  [<ffffffffa01ab75a>] ath_rx_node_cleanup+0x38/0x6e [ath9k]
kernel:  [<ffffffffa01b2280>] ath_node_detach+0x3b/0xb6 [ath9k]
kernel:  [<ffffffffa01ab09f>] ath9k_sta_notify+0x12b/0x165 [ath9k]
kernel:  [<ffffffff802366cf>] queue_work+0x1d/0x49
kernel:  [<ffffffffa018c3fc>] add_todo+0x70/0x99 [mac80211]
kernel:  [<ffffffffa017de76>] __sta_info_unlink+0x16b/0x19e [mac80211]
kernel:  [<ffffffffa017e6ed>] sta_info_unlink+0x18/0x43 [mac80211]
kernel:  [<ffffffffa0182732>] ieee80211_associated+0xaa/0x16d [mac80211]
kernel:  [<ffffffffa0184a1a>] ieee80211_sta_work+0x4fb/0x6b4 [mac80211]
kernel:  [<ffffffff80469c58>] thread_return+0x30/0xa9
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael S. Tsirkin | 1 Sep 18:07
Picon

new: regression iwl3945/mac80211 endless after suspend associate/deassociate loop

Starting with 2.6.27-rc5, my T60p sometimes fails to associate
with an access point after suspend to ram/resume.

This does not seem to ever happen on 2.6.27-rc4.

When this happens, I observe the following messages in dmesg:
(AP mac masked out with XX):

[16433.458084] iwl3945 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[16433.502490] PM: Adding info for No Bus:iwl-phy4:radio
[16433.502666] Registered led device: iwl-phy4:radio
[16433.502764] PM: Adding info for No Bus:iwl-phy4:assoc
[16433.502822] Registered led device: iwl-phy4:assoc
[16433.502870] PM: Adding info for No Bus:iwl-phy4:RX
[16433.503006] Registered led device: iwl-phy4:RX
[16433.503055] PM: Adding info for No Bus:iwl-phy4:TX
[16433.503111] Registered led device: iwl-phy4:TX
[16433.505268] eth1: authenticate with AP XX:XX:XX:XX:XX:XX
[16433.522344] ADDRCONF(NETDEV_UP): eth1: link is not ready
[16433.704125] eth1: authenticate with AP XX:XX:XX:XX:XX:XX
[16433.705986] eth1: authenticated
[16433.705997] eth1: associate with AP XX:XX:XX:XX:XX:XX
[16433.708406] eth1: RX AssocResp from XX:XX:XX:XX:XX:XX (capab=0x411 status=0 aid=1)
[16433.708412] eth1: associated
[16433.709659] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[16443.712280] eth1: disassociating by local choice (reason=3)
[16443.712902] eth1: disassociating by local choice (reason=3)
[16444.692059] eth1: no IPv6 routers present
[16445.997384] eth1: authenticate with AP XX:XX:XX:XX:XX:XX
[16445.999304] eth1: authenticated
(Continue reading)

Permalink | Reply | 0 comments |
headers
Karol Szkudlarek | 1 Sep 21:51
Picon

kernel crash during suspend using iwl3945 driver 1.2.26k on ubuntu hardy

Hello!

I'm using Ubuntu 8.04 with compiled 1.2.26k linux wireless driver for 
iwl3945 network card on my hp6710b laptop.
Script during suspend trying to remove the iwl3945 module and I receive 
kernel crash.
This is repeatable. I attached screenshot of kernel stack. Has somebody 
of iwl3945 developers can look on it?

Greets and regards,

--

-- 
Karol Szkudlarek
Mikronika
ul. Wykopy 2/4
60-001 POZNAÑ
tel. +48 61 6655600
fax +48 61 6655602
e-mail karol@...
Permalink | Reply | 10 comments |
headers
Christian Lamparter | 1 Sep 22:48
Picon

[PATCH 1/2] p54: enhance firmware parser to reduce memory waste

This patch greatly reduces one of biggest memory waste in the driver.

The firmware headers provides the right values for extra head-/tailroom
and mtu size which are usually much lower than the old hardcoded ones.

Signed-off-by: Christian Lamparter <chunkeey@...>
---
John,

this is another batch of patches for wireless-next ;-)
---
diff -Nurp a/drivers/net/wireless/p54/p54common.c b/drivers/net/wireless/p54/p54common.c
--- a/drivers/net/wireless/p54/p54common.c	2008-08-31 21:15:41.000000000 +0200
+++ b/drivers/net/wireless/p54/p54common.c	2008-09-01 21:33:22.000000000 +0200
@@ -66,8 +66,7 @@ static struct ieee80211_supported_band b
 	.n_bitrates = ARRAY_SIZE(p54_rates),
 };

-
-void p54_parse_firmware(struct ieee80211_hw *dev, const struct firmware *fw)
+int p54_parse_firmware(struct ieee80211_hw *dev, const struct firmware *fw)
 {
 	struct p54_common *priv = dev->priv;
 	struct bootrec_exp_if *exp_if;
@@ -79,7 +78,7 @@ void p54_parse_firmware(struct ieee80211
 	int i;

 	if (priv->rx_start)
-		return;
+		return 0;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Lamparter | 1 Sep 22:48
Picon

[PATCH 2/2] p54: move eeprom code into common library

Both p54pci and p54usb uses a good chunk of device specific code to
get the data from the device's eeprom into the drivers memory.

So, this patch reduces the code size and will it make life easier if
someone wants to implement ethtool eeprom dumping features. 

Signed-off-by: Christian Lamparter <chunkeey@...>
---
diff -Nurp a/drivers/net/wireless/p54/p54common.c b/drivers/net/wireless/p54/p54common.c
--- a/drivers/net/wireless/p54/p54common.c	2008-09-01 21:33:22.000000000 +0200
+++ b/drivers/net/wireless/p54/p54common.c	2008-09-01 22:23:17.000000000 +0200
@@ -249,6 +249,9 @@ static int p54_convert_rev1(struct ieee8
 	return 0;
 }

+const char* p54_rf_chips[] = { "NULL", "Indigo?", "Duette",
+                              "Frisbee", "Xbow", "Longbow" };
+
 int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
 {
 	struct p54_common *priv = dev->priv;
@@ -258,6 +261,7 @@ int p54_parse_eeprom(struct ieee80211_hw
 	void *tmp;
 	int err;
 	u8 *end = (u8 *)eeprom + len;
+	DECLARE_MAC_BUF(mac);

 	wrap = (struct eeprom_pda_wrap *) eeprom;
 	entry = (void *)wrap->data + le16_to_cpu(wrap->len);
@@ -339,7 +343,7 @@ int p54_parse_eeprom(struct ieee80211_hw
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nadav Kavalerchik | 1 Sep 22:49
Picon
Gravatar

BMC4310 support (03f0:171d)

i just got a new HP tx2520ej tablet laptop with a BCM4310 wlan
it is identified as Vendor : 03f0  , Product : 171d

any chance i can try a development version that might work ?

:-)
--
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 | 1 comment |
headers
Michael Buesch | 1 Sep 23:33
Picon
Favicon

Re: BMC4310 support (03f0:171d)

On Monday 01 September 2008 22:49:20 Nadav Kavalerchik wrote:
> i just got a new HP tx2520ej tablet laptop with a BCM4310 wlan
> it is identified as Vendor : 03f0  , Product : 171d
> 
> any chance i can try a development version that might work ?

no

--

-- 
Greetings Michael.
--
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
Andrew Morton | 2 Sep 02:18

Re: [Bugme-new] [Bug 11476] New: failure to associate after resume from suspend to ram


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Mon,  1 Sep 2008 13:33:47 -0700 (PDT)
bugme-daemon@... wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=11476
> 
>            Summary: failure to associate after resume from suspend to ram
>            Product: Networking
>            Version: 2.5
>      KernelVersion: 2.6.25-rc5
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Wireless
>         AssignedTo: networking_wireless@...
>         ReportedBy: m.s.tsirkin@...
> 
> 
> Latest working kernel version: 2.6.25-rc4
> Earliest failing kernel version: 2.6.25-rc5

A very recent regression.

> Distribution: ubuntu gutsy
(Continue reading)

Permalink | Reply | 1 comment |

Gmane