* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: v4mp @ 2011-10-15 14:22 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4E91B400.1020305@lwfinger.net>
i've tried also kernel 3.1-rc9 with latest compat wireless 14-10-2011 and still
don't work...it was recognized but no APs can be detected..the led of the alfa
is off..seems that it is power off..
i don't know about firmware, i see that there are .bin on lib/firmware/rtlwifi..
how can i update them?
thx
^ permalink raw reply
* Re: Ath9k, single antenna on ar9280
From: Felix Fietkau @ 2011-10-15 14:22 UTC (permalink / raw)
To: Stanislav Demakov; +Cc: linux-wireless
In-Reply-To: <CAN=pzdJgba-mdJHLDC+_LpgSiMwff4vbB-oUp2VDwYsSouedPA@mail.gmail.com>
On 2011-10-15 3:41 PM, Stanislav Demakov wrote:
> And the last question...
> Can you confirm that after setting antenna configuration to 1x1 I can
> safely detach 2nd physical connector from the adapter? I mean is there
> a guarantees that device will only use the 1st antenna.
Changing the antenna configuration will alter the chainmask accordingly,
so it should be safe to disconnect the second physical connector.
- Felix
^ permalink raw reply
* Re: 3.1-rc9 wifi problem
From: Arend van Spriel @ 2011-10-15 18:38 UTC (permalink / raw)
To: werner; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <web-626864831@zbackend1.aha.ru>
On 10/15/2011 08:07 PM, werner wrote:
> A laptop of a friend, which worked always with wifi until
> 3.0.4 , stopped to work when installing 3.1-rc9 , after
> re-installing 3.0.4 wifi returned to work. I think it was
> a packard-bell laptop. I can't test this better because
> he gone with his laptop; perhaps next week he'll visit me
> again. Since 2.6.38 his laptop worked with my wifi.
>
> This can be a regression in the wifi drivers, or because
> of a slightly changed config. Anyway the diff of config is
> enclosed.
>
> w.landgraf
> ---
> Professional hosting for everyone - http://www.host.ru
Another thing. As this seems a wireless issue it may be better to send
this thread to the linux-wireless list.
Gr. AvS
^ permalink raw reply
* Compat-wireless release for 2011-10-15 is baked
From: Compat-wireless cronjob account @ 2011-10-15 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
814119 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3535 - % of code consists of backport work
^ permalink raw reply
* Re: 3.1-rc9 wifi problem
From: David Täht @ 2011-10-15 19:21 UTC (permalink / raw)
To: Arend van Spriel; +Cc: werner, linux-wireless@vger.kernel.org
In-Reply-To: <4E99D30A.1030108@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
On 10/15/2011 08:38 PM, Arend van Spriel wrote:
> On 10/15/2011 08:07 PM, werner wrote:
>> A laptop of a friend, which worked always with wifi until
>> 3.0.4 , stopped to work when installing 3.1-rc9 , after
>> re-installing 3.0.4 wifi returned to work. I think it was
>> a packard-bell laptop. I can't test this better because
>> he gone with his laptop; perhaps next week he'll visit me
>> again. Since 2.6.38 his laptop worked with my wifi.
>>
>> This can be a regression in the wifi drivers, or because
>> of a slightly changed config. Anyway the diff of config is
>> enclosed.
>>
>> w.landgraf
>> ---
>> Professional hosting for everyone - http://www.host.ru
> Another thing. As this seems a wireless issue it may be better to send
> this thread to the linux-wireless list.
>
In my case, with 3.1-rc9, an atheros SR71 card stopped apparently
negotiating N - as it would not connect faster than 54Mbit on the 5ghz
channel either in HT20 or HT40+ mode, according to sampling iwconfig.
> Gr. AvS
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Täht
[-- Attachment #2: dave_taht.vcf --]
[-- Type: text/x-vcard, Size: 214 bytes --]
begin:vcard
fn;quoted-printable:Dave T=C3=A4ht
n;quoted-printable:T=C3=A4ht;Dave
email;internet:dave.taht@gmail.com
tel;home:1-239-829-5608
tel;cell:0638645374
x-mozilla-html:FALSE
version:2.1
end:vcard
^ permalink raw reply
* [PATCH] wl12xx: set scan probe requests rate according to the no_cck flag
From: Guy Eilam @ 2011-10-15 20:23 UTC (permalink / raw)
To: coelho; +Cc: linux-wireless
Set the TX rate of probe requests during scanning according to the
no_cck flag in the scan request struct.
Signed-off-by: Guy Eilam <guy@wizery.com>
---
drivers/net/wireless/wl12xx/scan.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/scan.c b/drivers/net/wireless/wl12xx/scan.c
index 5a6ae29..9a6bba4 100644
--- a/drivers/net/wireless/wl12xx/scan.c
+++ b/drivers/net/wireless/wl12xx/scan.c
@@ -184,7 +184,6 @@ static int wl1271_scan_send(struct wl1271 *wl, enum ieee80211_band band,
cmd->params.tx_rate = cpu_to_le32(basic_rate);
cmd->params.n_probe_reqs = wl->conf.scan.num_probe_reqs;
- cmd->params.tx_rate = cpu_to_le32(basic_rate);
cmd->params.tid_trigger = 0;
cmd->params.scan_tag = WL1271_SCAN_DEFAULT_TAG;
@@ -243,7 +242,12 @@ void wl1271_scan_stm(struct wl1271 *wl)
case WL1271_SCAN_STATE_2GHZ_ACTIVE:
band = IEEE80211_BAND_2GHZ;
- rate = wl1271_tx_min_rate_get(wl, wl->bitrate_masks[band]);
+ if (wl->scan.req->no_cck)
+ rate = wl1271_tx_min_rate_get(wl,
+ CONF_TX_RATE_MASK_BASIC_P2P);
+ else
+ rate = wl1271_tx_min_rate_get(wl,
+ CONF_TX_RATE_MASK_BASIC);
ret = wl1271_scan_send(wl, band, false, rate);
if (ret == WL1271_NOTHING_TO_SCAN) {
wl->scan.state = WL1271_SCAN_STATE_2GHZ_PASSIVE;
@@ -254,7 +258,12 @@ void wl1271_scan_stm(struct wl1271 *wl)
case WL1271_SCAN_STATE_2GHZ_PASSIVE:
band = IEEE80211_BAND_2GHZ;
- rate = wl1271_tx_min_rate_get(wl, wl->bitrate_masks[band]);
+ if (wl->scan.req->no_cck)
+ rate = wl1271_tx_min_rate_get(wl,
+ CONF_TX_RATE_MASK_BASIC_P2P);
+ else
+ rate = wl1271_tx_min_rate_get(wl,
+ CONF_TX_RATE_MASK_BASIC);
ret = wl1271_scan_send(wl, band, true, rate);
if (ret == WL1271_NOTHING_TO_SCAN) {
if (wl->enable_11a)
--
1.7.4.1
^ permalink raw reply related
* Re: 3.1.0-rc9+ : wlan stops working w/o any error messages
From: David Rientjes @ 2011-10-15 21:21 UTC (permalink / raw)
To: Toralf Förster; +Cc: werner, Wey-Yi Guy, ilw, linux-wireless, linux-kernel
In-Reply-To: <201110152119.58509.toralf.foerster@gmx.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 960 bytes --]
On Sat, 15 Oct 2011, Toralf Förster wrote:
> With a ThinkPad T400 with "Intel Corporation PRO/Wireless 5100 AGN [Shiloh]
> Network Connection" I experienced few times in the last week that the suddenly
> the network stops to work - no messages in /var/log/messages nor any other
> outout. Only a restart of the network services helped
>
> n22 ~ # uname -a
> Linux n22 3.1.0-rc9+ #1 SMP Fri Oct 14 19:21:56 CEST 2011 i686 Intel(R)
> Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux
>
> It is an almost stable Gentoo.
>
> Anybody else made similar experiences ?
>
It looks like werner is reporting a similar problem in
https://lkml.org/lkml/2011/10/15/67 but with a different laptop,
information is vague in that regression report.
Adding him, Wey-Yi Guy from Intel, and linux-wireless mailing list to the
cc.
What's the last kernel prior to 3.1-rc9 that worked for you?
What does "iwconfig" show?
What does "dmesg | grep iwlagn" show?
^ permalink raw reply
* 3.1-rc9 wifi problem
From: werner @ 2011-10-15 21:43 UTC (permalink / raw)
To: linux-kernel, linux-wireless, dave.taht, rientjes, arend,
toralf.foerster, wey-yi.w.guy, ilw
I'm very sorry that I cannot give more informations, my
own computer is connected with the modem via ethernet
cable, a friend used in the past often wifi here at me,
and since 2.6.38 never with problems, also with 3.0-rcX no
problems, nor with 3.0.X until 3.0.4 . There were
general problems with 3.1-rcX until 5 , which had nothing
to do with wifi but what was the reason that I only late
got working 3.1-rcX , so the first 3.1-rc the friend
tested on his laptop was 3.1-rc9, and with this his wifi
didn't work, but I don't know if it would have worked with
-rc5. When he come back, perhaps next week , then I'll ask
him to try 3.1-rc5 or 6 . This is a kernel+modules
problem, because with re-installing 3.0.4 it returned to
work as before. Anyway, I wanted to report this, so that
before the release of 3.1 the wifi drivers could be
checked better.
wl
---
Professional hosting for everyone - http://www.host.ru
^ permalink raw reply
* Re: 3.1-rc9 wifi problem
From: Larry Finger @ 2011-10-16 2:42 UTC (permalink / raw)
To: werner
Cc: linux-kernel, linux-wireless, dave.taht, rientjes, arend,
toralf.foerster, wey-yi.w.guy, ilw
In-Reply-To: <web-626905859@zbackend1.aha.ru>
On 10/15/2011 04:43 PM, werner wrote:
> I'm very sorry that I cannot give more informations, my own computer is
> connected with the modem via ethernet cable, a friend used in the past often
> wifi here at me, and since 2.6.38 never with problems, also with 3.0-rcX no
> problems, nor with 3.0.X until 3.0.4 . There were general problems with 3.1-rcX
> until 5 , which had nothing to do with wifi but what was the reason that I only
> late got working 3.1-rcX , so the first 3.1-rc the friend tested on his laptop
> was 3.1-rc9, and with this his wifi didn't work, but I don't know if it would
> have worked with -rc5. When he come back, perhaps next week , then I'll ask him
> to try 3.1-rc5 or 6 . This is a kernel+modules problem, because with
> re-installing 3.0.4 it returned to work as before. Anyway, I wanted to report
> this, so that before the release of 3.1 the wifi drivers could be checked better.
Unless you say which driver is involved, we will n ot be able to help.
Larry
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: Larry Finger @ 2011-10-16 2:49 UTC (permalink / raw)
To: v4mp; +Cc: linux-wireless
In-Reply-To: <loom.20111015T161652-440@post.gmane.org>
On 10/15/2011 09:22 AM, v4mp wrote:
>
>
> i've tried also kernel 3.1-rc9 with latest compat wireless 14-10-2011 and still
> don't work...it was recognized but no APs can be detected..the led of the alfa
> is off..seems that it is power off..
>
> i don't know about firmware, i see that there are .bin on lib/firmware/rtlwifi..
> how can i update them?
That depends on your distro, but please look at the output of the dmesg command
to see if there is an error loading the firmware.
You also need to install rfkill and look at the output of 'rfkill list'. If you
have another wireless device that is being hard blocked, or if there is a soft
block active, then rtl8192cu cannot work.
Note that the device works on my system. There should not be a problem with the
driver on your device once we clean up these questions. Once the device gets the
proper firmware and the RF is unblocked, the LED will light.
Larry
^ permalink raw reply
* [PATCH] mac80211: call set_wmm_default only for valid vifs
From: Eliad Peller @ 2011-10-16 8:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
mac80211 calls ieee80211_set_wmm_default (which in turn
calls drv_conf_tx()) for every new interface, including
"internal" ones (e.g. monitor interface, which the low-level
driver doesn't know about).
Limit this call only to valid interfaces.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
net/mac80211/iface.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index ef741e8..87a5b47 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -286,6 +286,13 @@ static int ieee80211_do_open(struct net_device *dev, bool coming_up)
netif_carrier_off(dev);
else
netif_carrier_on(dev);
+
+ /*
+ * set default queue parameters so drivers don't
+ * need to initialise the hardware if the hardware
+ * doesn't start up with sane defaults
+ */
+ ieee80211_set_wmm_default(sdata);
}
set_bit(SDATA_STATE_RUNNING, &sdata->state);
@@ -329,15 +336,8 @@ static int ieee80211_do_open(struct net_device *dev, bool coming_up)
if (coming_up)
local->open_count++;
- if (hw_reconf_flags) {
+ if (hw_reconf_flags)
ieee80211_hw_config(local, hw_reconf_flags);
- /*
- * set default queue parameters so drivers don't
- * need to initialise the hardware if the hardware
- * doesn't start up with sane defaults
- */
- ieee80211_set_wmm_default(sdata);
- }
ieee80211_recalc_ps(local, -1);
--
1.7.6.401.g6a319
^ permalink raw reply related
* Re: [PATCH] wl12xx: set scan probe requests rate according to the no_cck flag
From: Eliad Peller @ 2011-10-16 10:58 UTC (permalink / raw)
To: Guy Eilam; +Cc: coelho, linux-wireless
In-Reply-To: <1318710223-29285-1-git-send-email-guy@wizery.com>
hi Guy,
On Sat, Oct 15, 2011 at 10:23 PM, Guy Eilam <guy@wizery.com> wrote:
> Set the TX rate of probe requests during scanning according to the
> no_cck flag in the scan request struct.
>
> Signed-off-by: Guy Eilam <guy@wizery.com>
> ---
[...]
> @@ -243,7 +242,12 @@ void wl1271_scan_stm(struct wl1271 *wl)
>
> case WL1271_SCAN_STATE_2GHZ_ACTIVE:
> band = IEEE80211_BAND_2GHZ;
> - rate = wl1271_tx_min_rate_get(wl, wl->bitrate_masks[band]);
> + if (wl->scan.req->no_cck)
> + rate = wl1271_tx_min_rate_get(wl,
> + CONF_TX_RATE_MASK_BASIC_P2P);
> + else
> + rate = wl1271_tx_min_rate_get(wl,
> + CONF_TX_RATE_MASK_BASIC);
on a second thought, this seems a bit wrong.
i think we should consider the configured bitrate_masks when scanning.
maybe just mask-out the cck rates?
Eliad.
^ permalink raw reply
* Compat-wireless release for 2011-10-16 is baked
From: Compat-wireless cronjob account @ 2011-10-16 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
814119 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3535 - % of code consists of backport work
^ permalink raw reply
* [PATCH 3.2] b43: fill ctl1 word on all new PHYs, fix PHY errors
From: Rafał Miłecki @ 2011-10-16 21:23 UTC (permalink / raw)
To: linux-wireless, John W. Linville; +Cc: b43-dev, Rafał Miłecki
This fixes PHY transmission errors reported on some LP-PHY and HT-PHY
cards. For LP-PHY they were quite rare and not really noticable. On
HT-PHY they were critical, OFDM rates were not available at all.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
I've this patch since August or earlier, just didn't submit it yet. It
was succesfully tested on LP-PHY cards and fixed performance for every
tested HT-PHY case.
---
drivers/net/wireless/b43/xmit.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/b43/xmit.c b/drivers/net/wireless/b43/xmit.c
index c73e860..390c234 100644
--- a/drivers/net/wireless/b43/xmit.c
+++ b/drivers/net/wireless/b43/xmit.c
@@ -175,6 +175,7 @@ void b43_generate_plcp_hdr(struct b43_plcp_hdr4 *plcp,
}
}
+/* TODO: verify for SSLPN and LCN if support is implemented */
static u16 b43_generate_tx_phy_ctl1(struct b43_wldev *dev, u8 bitrate)
{
const struct b43_phy *phy = &dev->phy;
@@ -531,7 +532,7 @@ int b43_generate_txhdr(struct b43_wldev *dev,
extra_ft |= B43_TXH_EFT_RTSFB_CCK;
if (rates[0].flags & IEEE80211_TX_RC_USE_RTS_CTS &&
- phy->type == B43_PHYTYPE_N) {
+ phy->type >= B43_PHYTYPE_N) {
txhdr->phy_ctl1_rts = cpu_to_le16(
b43_generate_tx_phy_ctl1(dev, rts_rate));
txhdr->phy_ctl1_rts_fb = cpu_to_le16(
@@ -552,7 +553,7 @@ int b43_generate_txhdr(struct b43_wldev *dev,
break;
}
- if (phy->type == B43_PHYTYPE_N) {
+ if (phy->type >= B43_PHYTYPE_N) {
txhdr->phy_ctl1 =
cpu_to_le16(b43_generate_tx_phy_ctl1(dev, rate));
txhdr->phy_ctl1_fb =
--
1.7.3.4
^ permalink raw reply related
* [PATCH 3.2 REQUEST] b43: HT-PHY: report signal to mac80211
From: Rafał Miłecki @ 2011-10-16 21:30 UTC (permalink / raw)
To: linux-wireless, John W. Linville
Cc: b43-dev, David Woodhouse, Rafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
John, this is new feature, not a bug fix. However I still think it'd be
great to take this for 3.2. This is hopefully final b43 patch for 3.2
related to HT-PHY support. With this last one, basic support should be
100% implemented now.
This can be even more important, as there isn't any native Linux driver
(open or closed source) for HT-PHY (BCM4331) other than b43.
This has been succesfully tested by David, reported signal looked sane
for him. Unfortunately we still lack info about the noise, but having
signal gives users some basic overview on the available networks.
---
drivers/net/wireless/b43/xmit.c | 7 +++++++
drivers/net/wireless/b43/xmit.h | 16 +++++++++++++++-
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/b43/xmit.c b/drivers/net/wireless/b43/xmit.c
index 390c234..ed54f7d 100644
--- a/drivers/net/wireless/b43/xmit.c
+++ b/drivers/net/wireless/b43/xmit.c
@@ -737,7 +737,14 @@ void b43_rx(struct b43_wldev *dev, struct sk_buff *skb, const void *_rxhdr)
/* Link quality statistics */
switch (chanstat & B43_RX_CHAN_PHYTYPE) {
+ case B43_PHYTYPE_HT:
+ /* TODO: is max the right choice? */
+ status.signal = max(
+ (__s8) max(rxhdr->phy_ht_power0, rxhdr->phy_ht_power1),
+ rxhdr->phy_ht_power2);
+ break;
case B43_PHYTYPE_N:
+ /* Broadcom has code for min and avg, but always uses max */
if (rxhdr->power0 == 16 || rxhdr->power0 == 32)
status.signal = max(rxhdr->power1, rxhdr->power2);
else
diff --git a/drivers/net/wireless/b43/xmit.h b/drivers/net/wireless/b43/xmit.h
index 16c514d..98d9074 100644
--- a/drivers/net/wireless/b43/xmit.h
+++ b/drivers/net/wireless/b43/xmit.h
@@ -249,6 +249,12 @@ struct b43_rxhdr_fw4 {
} __packed;
} __packed;
union {
+ /* HT-PHY */
+ struct {
+ PAD_BYTES(1);
+ __s8 phy_ht_power0;
+ } __packed;
+
/* RSSI for N-PHYs */
struct {
__s8 power2;
@@ -257,7 +263,15 @@ struct b43_rxhdr_fw4 {
__le16 phy_status2; /* PHY RX Status 2 */
} __packed;
- __le16 phy_status3; /* PHY RX Status 3 */
+ union {
+ /* HT-PHY */
+ struct {
+ __s8 phy_ht_power1;
+ __s8 phy_ht_power2;
+ } __packed;
+
+ __le16 phy_status3; /* PHY RX Status 3 */
+ } __packed;
union {
/* Tested with 598.314, 644.1001 and 666.2 */
struct {
--
1.7.3.4
^ permalink raw reply related
* Re: 3.1-rc9 wifi problem
From: werner @ 2011-10-17 1:33 UTC (permalink / raw)
To: linux-kernel, linux-wireless, dave.taht, rientjes, arend,
toralf.foerster, wey-yi.w.guy, ilw, larry.finger
In-Reply-To: <4E9A4496.1000906@lwfinger.net>
I have to wait until the friend with the laptop comes
back, perhaps this week. Then I can look what wireless
card is in it.
However, now I remember me: that laptop worked only good
since 2.6.39 with the new kernel-embedded modules.
Before, it didn't work normally, i.e. on booting the
wireless almost never didn't switch on; only ocasionally .
And, beside of kernel 2.6.39, and the normal wifi
software, I still had him to install a file
iwlwifi-1000-3.ucode or .5 ucode (i'm not sure, the number
can also be 5000), and I had the problem to search long
time for that file because one find only .2 or .4 in
internet but what don't work at that wifi card. You
could improve the kernel-module so that everything is
included so that one don't need to search such files.
Then, with this kernel and that file however, it worked
without any problem.
I hope from these informations you can find out what wifi
card or what driver is in the laptop.
W.Landgraf
---
Professional hosting for everyone - http://www.host.ru
^ permalink raw reply
* Re: 3.1-rc9 wifi problem
From: Larry Finger @ 2011-10-17 2:16 UTC (permalink / raw)
To: werner
Cc: linux-kernel, linux-wireless, dave.taht, rientjes, arend,
toralf.foerster, wey-yi.w.guy, ilw, larry.finger
In-Reply-To: <web-627302724@zbackend1.aha.ru>
On 10/16/2011 08:33 PM, werner wrote:
> I have to wait until the friend with the laptop comes back, perhaps this week.
> Then I can look what wireless card is in it.
>
> However, now I remember me: that laptop worked only good since 2.6.39 with the
> new kernel-embedded modules. Before, it didn't work normally, i.e. on booting
> the wireless almost never didn't switch on; only ocasionally .
>
>
> And, beside of kernel 2.6.39, and the normal wifi software, I still had him to
> install a file iwlwifi-1000-3.ucode or .5 ucode (i'm not sure, the number can
> also be 5000), and I had the problem to search long time for that file because
> one find only .2 or .4 in internet but what don't work at that wifi card. You
> could improve the kernel-module so that everything is included so that one don't
> need to search such files.
That will not happen. In fact, the trend is from having firmware be a part of
the driver to having it be external.
I don't know what distro you use, but mine (openSUSE) maintains a package called
kernel-firmware that contains all the redistributable firmware that is available
from tne linux-firmware git tree. If that package is installed, then you do not
have to search for firmware in most cases. If your distro does not have such a
package, then complain or find another distro.
> Then, with this kernel and that file however, it worked without any problem.
>
> I hope from these informations you can find out what wifi card or what driver is
> in the laptop.
We can tell that you have an Intel card, but not much more.
Larry
^ permalink raw reply
* Re: 3.1-rc9 wifi problem
From: Guy, Wey-Yi @ 2011-10-17 1:34 UTC (permalink / raw)
To: Larry Finger
Cc: werner, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, dave.taht@gmail.com,
rientjes@google.com, arend@broadcom.com, toralf.foerster@gmx.de,
ilw@linux.intel.com, larry.finger@gmail.com
In-Reply-To: <4E9B9018.1000002@lwfinger.net>
On Sun, 2011-10-16 at 19:16 -0700, Larry Finger wrote:
> On 10/16/2011 08:33 PM, werner wrote:
> > I have to wait until the friend with the laptop comes back, perhaps this week.
> > Then I can look what wireless card is in it.
> >
> > However, now I remember me: that laptop worked only good since 2.6.39 with the
> > new kernel-embedded modules. Before, it didn't work normally, i.e. on booting
> > the wireless almost never didn't switch on; only ocasionally .
> >
> >
> > And, beside of kernel 2.6.39, and the normal wifi software, I still had him to
> > install a file iwlwifi-1000-3.ucode or .5 ucode (i'm not sure, the number can
> > also be 5000), and I had the problem to search long time for that file because
> > one find only .2 or .4 in internet but what don't work at that wifi card. You
> > could improve the kernel-module so that everything is included so that one don't
> > need to search such files.
>
> That will not happen. In fact, the trend is from having firmware be a part of
> the driver to having it be external.
>
> I don't know what distro you use, but mine (openSUSE) maintains a package called
> kernel-firmware that contains all the redistributable firmware that is available
> from tne linux-firmware git tree. If that package is installed, then you do not
> have to search for firmware in most cases. If your distro does not have such a
> package, then complain or find another distro.
>
> > Then, with this kernel and that file however, it worked without any problem.
> >
> > I hope from these informations you can find out what wifi card or what driver is
> > in the laptop.
>
> We can tell that you have an Intel card, but not much more.
>
> Larry
>
Not knowing much about what problem you encounter, but you can find all
the latest intel WiFi firmware at
http://www.intellinuxwireless.org/?n=Downloads
Thanks
Wey
^ permalink raw reply
* [patch] ath9k_hw: min_t() casts u32 to int
From: Dan Carpenter @ 2011-10-17 7:28 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Jouni Malinen, Vasanthakumar Thiagarajan, Senthil Balasubramanian,
John W. Linville, linux-wireless, ath9k-devel, kernel-janitors
The code here treats very large values of "limit" as less than
MAX_POWER_RATE because of the cast to int. We should do the compare
as u32 instead.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index e0c8549..f9abbb7 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2526,7 +2526,7 @@ void ath9k_hw_set_txpowerlimit(struct ath_hw *ah, u32 limit, bool test)
struct ath9k_channel *chan = ah->curchan;
struct ieee80211_channel *channel = chan->chan;
- reg->power_limit = min_t(int, limit, MAX_RATE_POWER);
+ reg->power_limit = min_t(u32, limit, MAX_RATE_POWER);
if (test)
channel->max_power = MAX_RATE_POWER / 2;
^ permalink raw reply related
* Re: 3.1.0-rc9+ : wlan stops working w/o any error messages
From: Toralf Förster @ 2011-10-17 7:31 UTC (permalink / raw)
To: David Rientjes, David Rientjes
Cc: werner, Wey-Yi Guy, ilw, linux-wireless, linux-kernel
In-Reply-To: <alpine.DEB.2.00.1110151416360.15894@chino.kir.corp.google.com>
David Rientjes wrote at 23:21:59
> What's the last kernel prior to 3.1-rc9 that worked for you?
2.6.39.4 (in general that kernel version rocks, reliable, stable, no problems
AFAICS, 3.0.x have problems in the DVB-T area, 3.1 added wlan issues)
> What does "iwconfig" show?
wlan0 IEEE 802.11abgn ESSID:"IBM"
Mode:Managed Frequency:2.462 GHz Access Point: 00:21:55:AC:8B:80
Bit Rate=54 Mb/s Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=49/70 Signal level=-61 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
> What does "dmesg | grep iwlagn" show?
n22 ~ # dmesg | grep iwlagn
iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn 0000:03:00.0: setting latency timer to 64
iwlagn 0000:03:00.0: pci_resource_len = 0x00002000
iwlagn 0000:03:00.0: pci_resource_base = f81f8000
iwlagn 0000:03:00.0: HW Revision ID = 0x0
iwlagn 0000:03:00.0: irq 48 for MSI/MSI-X
iwlagn 0000:03:00.0: Detected Intel(R) WiFi Link 5100 AGN, REV=0x54
iwlagn 0000:03:00.0: L1 Disabled; Enabling L0S
iwlagn 0000:03:00.0: device EEPROM VER=0x11e, CALIB=0x4
iwlagn 0000:03:00.0: Device SKU: 0Xf0
iwlagn 0000:03:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels
iwlagn 0000:03:00.0: loaded firmware version 8.83.5.1 build 33692
iwlagn 0000:03:00.0: L1 Disabled; Enabling L0S
iwlagn 0000:03:00.0: Radio type=0x1-0x2-0x0
iwlagn 0000:03:00.0: L1 Disabled; Enabling L0S
iwlagn 0000:03:00.0: Radio type=0x1-0x2-0x0
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply
* Re: 3.1.0-rc9+ : wlan stops working w/o any error messages
From: Toralf Förster @ 2011-10-17 7:52 UTC (permalink / raw)
To: David Rientjes; +Cc: werner, Wey-Yi Guy, ilw, linux-wireless, linux-kernel
In-Reply-To: <201110170931.59534.toralf.foerster@gmx.de>
Toralf Förster wrote at 09:31:58
> > What does "iwconfig" show?
And this is the state if the netwerk stops working :
wlan0 IEEE 802.11abgn ESSID:"IBM"
Mode:Managed Frequency:2.462 GHz Access Point: 00:21:55:AC:8B:80
Bit Rate=54 Mb/s Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=45/70 Signal level=-65 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:77 Missed beacon:0
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: v4mp @ 2011-10-17 10:07 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4E9A4647.60901@lwfinger.net>
ok, i've attached the alfa and run rfkill list but it shows that there are no
blocked devices, then i run modprobe rtl8192cu and strangely the alfa has
lighted, but it doesn't work..
i've done dmesg and seen this:
[ 1218.079638] rtlwifi: reg 0xc80, usbctrl_vendorreq TimeOut! status:0xfffffff4
value=0xed545b78
[ 1218.079645] xhci_hcd 0000:05:00.0: ERROR no room on ep ring
[ 1218.079650] rtlwifi: reg 0xc80, usbctrl_vendorreq TimeOut! status:0xfffffff4
value=0xed545b78
[ 1218.079657] xhci_hcd 0000:05:00.0: ERROR no room on ep ring
[ 1218.079664] xhci_hcd 0000:05:00.0: ERROR no room on ep ring
[ 1218.079669] rtlwifi: reg 0xc4c, usbctrl_vendorreq TimeOut! status:0xfffffff4
value=0xed545b78
[ 1218.079676] xhci_hcd 0000:05:00.0: ERROR no room on ep ring
[ 1218.079682] xhci_hcd 0000:05:00.0: ERROR no room on ep ring
[ 1218.079687] rtlwifi: reg 0xc94, usbctrl_vendorreq TimeOut! status:0xfffffff4
value=0xed545b78
[ 1218.241190] ADDRCONF(NETDEV_UP): wlan1: link is not ready
for the firmware i don't know how to update it, i'm using ubuntu 11.04 natty
with 3.1.0-0301rc9-generic
where can i download updated firmware to test it for this card?
thx
^ permalink raw reply
* Re: [PATCH 3.2] b43: fill ctl1 word on all new PHYs, fix PHY errors
From: Michael Büsch @ 2011-10-17 14:24 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless, John W. Linville, b43-dev
In-Reply-To: <1318800236-5329-1-git-send-email-zajec5@gmail.com>
On Sun, 16 Oct 2011 23:23:56 +0200
Rafał Miłecki <zajec5@gmail.com> wrote:
> + if (phy->type >= B43_PHYTYPE_N) {
I must say that I really dislike this. It's error prone (previous patch got it wrong)
and it's hard to read. Just spell out all types or use a switch statement, as appropriate.
It also makes grepping the sources a lot harder.
I don't see any real advantage.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH 3.2 REQUEST] b43: HT-PHY: report signal to mac80211
From: Michael Büsch @ 2011-10-17 14:27 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless, John W. Linville, David Woodhouse, b43-dev
In-Reply-To: <1318800649-5609-1-git-send-email-zajec5@gmail.com>
On Sun, 16 Oct 2011 23:30:49 +0200
Rafał Miłecki <zajec5@gmail.com> wrote:
> + case B43_PHYTYPE_HT:
> + /* TODO: is max the right choice? */
> + status.signal = max(
> + (__s8) max(rxhdr->phy_ht_power0, rxhdr->phy_ht_power1),
Hm, why is this cast needed? Does it throw a warning?
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH 3.2 REQUEST] b43: HT-PHY: report signal to mac80211
From: Rafał Miłecki @ 2011-10-17 14:35 UTC (permalink / raw)
To: Michael Büsch
Cc: linux-wireless, John W. Linville, David Woodhouse, b43-dev
In-Reply-To: <20111017162727.388624fc@milhouse>
W dniu 17 października 2011 16:27 użytkownik Michael Büsch <m@bues.ch> napisał:
> On Sun, 16 Oct 2011 23:30:49 +0200
> Rafał Miłecki <zajec5@gmail.com> wrote:
>> + case B43_PHYTYPE_HT:
>> + /* TODO: is max the right choice? */
>> + status.signal = max(
>> + (__s8) max(rxhdr->phy_ht_power0, rxhdr->phy_ht_power1),
>
> Hm, why is this cast needed? Does it throw a warning?
warning: comparison of distinct pointer types lacks a cast
gcc 4.5.1
--
Rafał
^ 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