* Re: Abour linux driver supports BCM4325
From: Holger Schurig @ 2009-08-24 8:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: Larry Finger, feng tian, linux-wireless
In-Reply-To: <1251018830.23605.32.camel@johannes.local>
> 1) changing b43 so it knows how to talk not just to
> SSB/PCI/PCMCIA chips but also SDIO chips
Feng, for this you could use another b43 card with SDIO, which
doesn't use the LP-PHY, but the older phy. If you find such a
device, you'll be start to code this now. As the SDIO-via-SSB
code is identical to b43-with-LP-PHY and b43-without-LP-PHY, can
you transfer all of this.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH 2/2] wl1271: remove print_mac usage
From: Luciano Coelho @ 2009-08-24 8:08 UTC (permalink / raw)
To: ext John W. Linville; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1250607301-24944-1-git-send-email-linville@tuxdriver.com>
ext John W. Linville wrote:
> CC [M] drivers/net/wireless/wl12xx/wl1271_main.o
> drivers/net/wireless/wl12xx/wl1271_main.c: In function ‘wl1271_op_add_interface’:
> drivers/net/wireless/wl12xx/wl1271_main.c:611: warning: ‘print_mac’ is deprecated (declared at include/linux/if_ether.h:142)
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
>
Thanks John.
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
--
Cheers,
Luca.
^ permalink raw reply
* WARNING: at include/net/mac80211.h:2104 minstrel_get_rate
From: Arnd Hannemann @ 2009-08-24 8:08 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi,
I managed to trigger the following warning (for the first time)
on 2.6.31-rc6. Never seen this in rc3,4,5 but maybe I was
just lucky this time.
[854748.332641] wlan0: associated
[854756.240475] ------------[ cut here ]------------
[854756.254840] WARNING: at include/net/mac80211.h:2104 minstrel_get_rate+0x78/0x48a [mac80211]()
[854756.280793] Modules linked in: xt_state ipt_MASQUERADE aes_generic ipt_LOG iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 arc4 ecb ath5k mac80211 ehci_hcd ath ohci_hcd
[854756.331887] Pid: 2554, comm: wpa_supplicant Not tainted 2.6.31-rc6-ah0 #8
[854756.352601] Call Trace:
[854756.360408] [<d08873e0>] ? minstrel_get_rate+0x78/0x48a [mac80211]
[854756.379597] [<c1012746>] warn_slowpath_common+0x60/0x77
[854756.395887] [<c101276a>] warn_slowpath_null+0xd/0x10
[854756.411487] [<d08873e0>] minstrel_get_rate+0x78/0x48a [mac80211]
[854756.430129] [<c113b665>] ? vsnprintf+0xceb/0xd62
[854756.444692] [<d087ba06>] rate_control_get_rate+0x82/0xc9 [mac80211]
[854756.464190] [<d0880fd3>] invoke_tx_handlers+0x4f9/0xb37 [mac80211]
[854756.483347] [<c1058d12>] ? pollwake+0x0/0x59
[854756.496872] [<d0880849>] ? __ieee80211_tx_prepare+0x2a5/0x2fc [mac80211]
[854756.517656] [<d08819da>] ieee80211_tx+0xa9/0x199 [mac80211]
[854756.535056] [<d08820b6>] ieee80211_master_start_xmit+0x280/0x290 [mac80211]
[854756.556562] [<c119f641>] dev_hard_start_xmit+0x1c2/0x24a
[854756.573136] [<c11acf67>] __qdisc_run+0xb4/0x172
[854756.587352] [<c11a1c79>] dev_queue_xmit+0x1b9/0x2a8
[854756.602611] [<c124d7c3>] ? nl80211_send_deauth+0xd/0x11
[854756.618976] [<d0883582>] ieee80211_tx_skb+0x4e/0x51 [mac80211]
[854756.637185] [<d0877739>] ieee80211_send_deauth_disassoc+0xfc/0x104 [mac80211]
[854756.659283] [<d087788a>] ieee80211_set_disassoc+0xf5/0x1f9 [mac80211]
[854756.679303] [<d087a571>] ieee80211_sta_req_auth+0x5b/0x9a [mac80211]
[854756.699039] [<d0872a51>] ieee80211_ioctl_siwfreq+0x10b/0x13e [mac80211]
[854756.719498] [<c1247209>] ioctl_standard_call+0x4b/0x26c
[854756.735791] [<c1259159>] ? __mutex_lock_slowpath+0x17e/0x186
[854756.753398] [<c1246f57>] wext_handle_ioctl+0xe2/0x179
[854756.769228] [<d0872946>] ? ieee80211_ioctl_siwfreq+0x0/0x13e [mac80211]
[854756.789710] [<c11a0e76>] dev_ioctl+0x554/0x57e
[854756.803693] [<c11947d2>] ? sys_sendto+0xa1/0xc0
[854756.817911] [<c1194f45>] ? sys_recvfrom+0x96/0xb7
[854756.832652] [<c122882a>] ? packet_bind+0x50/0x66
[854756.847117] [<c11954b8>] ? sock_ioctl+0x0/0x1ee
[854756.861333] [<c119569a>] sock_ioctl+0x1e2/0x1ee
[854756.875555] [<c11954b8>] ? sock_ioctl+0x0/0x1ee
[854756.889781] [<c1056e99>] vfs_ioctl+0x19/0x50
[854756.903235] [<c10576eb>] do_vfs_ioctl+0x446/0x47a
[854756.917974] [<c1194809>] ? sys_send+0x18/0x1a
[854756.931677] [<c1195280>] ? sys_socketcall+0xbb/0x165
[854756.947179] [<c105774b>] sys_ioctl+0x2c/0x45
[854756.960605] [<c1002715>] syscall_call+0x7/0xb
[854756.974302] ---[ end trace cd3397cce4cc2497 ]---
[854764.311238] wlan0: authenticate with AP XX:XX:XX:XX:XX:XX
Best regards,
Arnd
^ permalink raw reply
* Re: Implementing wireless testbed on Linux
From: Holger Schurig @ 2009-08-24 8:18 UTC (permalink / raw)
To: Jinsung Lee; +Cc: linux-wireless
In-Reply-To: <029301ca2239$0ac9ad70$205d0850$@kaist.ac.kr>
> In the case of using 802.11n chipset, which card and device
> driver should I choose? At the same time, which version of
> Linux kernel should be appropriate?
I'd go with Atheros based PCI cards. The cards are good, and the
support is outstanding (Atheros people work together with Linux
community on this mailing list!).
> Is there any difference between pci and usb interfaces?
Sure. Please read http://www.pcisig.com/specifications and
http://www.usb.org/developers/docs/. The busses are VERY
different in case of hierarchy, latency, max transfer rates and
so on.
I fear, however, that this mailing list isn't the right channel
to transfer this knowledge.
> Definitely, all device and software should be stable and
> up-to-date.
That's a contradicion. Especially wireless is quite evolving in
the Linux kernel.
There's the possibility that you use a vendor-kernel (e.g. Debian
kernel, Fedora kernel, or whatever distro you use). I personally
won't do this, but I'd use a more "vanilla" kernel. The vendors
usually put a huge amount on patches into their kernels, that
will make results not as easy to compare. Also, if you have a
specific questions, chances are way higher that the people in
the mailing list know about the "vanilla" kernel or
wireless-testing kernel than some random vendor kernel.
If you absolutely need something stable, you should go with the
least recent stable linux kernel (see http://www.kernel.org/).
If you want to be more up-to-date, you should use
wireless-testing. Expect new functionality, fixed bugs, but also
new bugs there :-) However, If you ever have to change some
driver code, you definitely want wireless-testing. You cannot
(usually) use the source from the stable kernel when submitting
patches. More info at
http://wireless.kernel.org/en/developers/Documentation
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Michael Buesch @ 2009-08-24 9:08 UTC (permalink / raw)
To: feng tian; +Cc: Johannes Berg, Larry Finger, linux-wireless
In-Reply-To: <f42a38140908232303j320f858cw5c0e45cc98a1e440@mail.gmail.com>
On Monday 24 August 2009 08:03:12 feng tian wrote:
> >>> 1) changing b43 so it knows how to talk not just to SSB/PCI/PCMCIA
> >>> chips but also SDIO chips
> >>
> >> We already have working support for that and we're currently merging it mainline.
> >> If you want to help, please test the spinlock removal patchset I just posted.
>
> >>> 2) changing b43 so it knows how to talk to your specific radio/PHY
> >>> chip, and LP PHY
>
> Where can I get theses codes which supports b43 talking to SDIO chips?
> Thanks very much.
They are not ready for public review, yet. We're working on merging them mainline.
But it does basically work and we (Albert Herranz) got the SDIO chip on the Nintendo Wii running.
--
Greetings, Michael.
^ permalink raw reply
* [IW] don't emit usage to stderr
From: Holger Schurig @ 2009-08-24 9:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
Only write error output to stderr, not help und usage information.
This allows now
./iw | less
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Index: iw/iw.c
===================================================================
--- iw.orig/iw.c 2009-08-24 10:00:08.000000000 +0200
+++ iw/iw.c 2009-08-24 10:01:08.000000000 +0200
@@ -103,24 +103,24 @@ static void __usage_cmd(struct cmd *cmd,
{
const char *start, *lend, *end;
- fprintf(stderr, "%s", indent);
+ printf("%s", indent);
switch (cmd->idby) {
case CIB_NONE:
break;
case CIB_PHY:
- fprintf(stderr, "phy <phyname> ");
+ printf("phy <phyname> ");
break;
case CIB_NETDEV:
- fprintf(stderr, "dev <devname> ");
+ printf("dev <devname> ");
break;
}
if (cmd->section)
- fprintf(stderr, "%s ", cmd->section);
- fprintf(stderr, "%s", cmd->name);
+ printf("%s ", cmd->section);
+ printf("%s", cmd->name);
if (cmd->args)
- fprintf(stderr, " %s", cmd->args);
- fprintf(stderr, "\n");
+ printf(" %s", cmd->args);
+ printf("\n");
if (!full || !cmd->help)
return;
@@ -129,7 +129,7 @@ static void __usage_cmd(struct cmd *cmd,
if (strlen(indent))
indent = "\t\t";
else
- fprintf(stderr, "\n");
+ printf("\n");
/* print line by line */
start = cmd->help;
@@ -138,18 +138,18 @@ static void __usage_cmd(struct cmd *cmd,
lend = strchr(start, '\n');
if (!lend)
lend = end;
- fprintf(stderr, "%s", indent);
- fprintf(stderr, "%.*s\n", (int)(lend - start), start);
+ printf("%s", indent);
+ printf("%.*s\n", (int)(lend - start), start);
start = lend + 1;
} while (end != lend);
- fprintf(stderr, "\n");
+ printf("\n");
}
static void usage_options(void)
{
- fprintf(stderr, "Options:\n");
- fprintf(stderr, "\t--debug\t\tenable netlink debugging\n");
+ printf("Options:\n");
+ printf("\t--debug\t\tenable netlink debugging\n");
}
static const char *argv0;
@@ -158,17 +158,17 @@ static void usage(bool full)
{
struct cmd *cmd;
- fprintf(stderr, "Usage:\t%s [options] command\n", argv0);
+ printf("Usage:\t%s [options] command\n", argv0);
usage_options();
- fprintf(stderr, "\t--version\tshow version (%s)\n", iw_version);
- fprintf(stderr, "Commands:\n");
+ printf("\t--version\tshow version (%s)\n", iw_version);
+ printf("Commands:\n");
for (cmd = &__start___cmd; cmd < &__stop___cmd;
cmd = (struct cmd *)((char *)cmd + cmd_size)) {
if (!cmd->handler || cmd->hidden)
continue;
__usage_cmd(cmd, "\t", full);
}
- fprintf(stderr, "\nYou can omit the 'phy' or 'dev' if "
+ printf("\nYou can omit the 'phy' or 'dev' if "
"the identification is unique,\n"
"e.g. \"iw wlan0 info\" or \"iw phy0 info\". "
"(Don't when scripting.)\n\n"
@@ -188,7 +188,7 @@ TOPLEVEL(help, NULL, 0, 0, CIB_NONE, pri
static void usage_cmd(struct cmd *cmd)
{
- fprintf(stderr, "Usage:\t%s [options] ", argv0);
+ printf("Usage:\t%s [options] ", argv0);
__usage_cmd(cmd, "", true);
usage_options();
}
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: feng tian @ 2009-08-24 9:35 UTC (permalink / raw)
To: Michael Buesch; +Cc: Johannes Berg, Larry Finger, linux-wireless
In-Reply-To: <200908241108.43943.mb@bu3sch.de>
Wow, that's really cool.
We wonder if you can send these codes to us a little earlier, then we
can start to integrate and test them on our platform.
That'll save us some time.
Thanks very much.
BR, Feng.
>> Where can I get theses codes which supports b43 talking to SDIO chips?
>> Thanks very much.
>
> They are not ready for public review, yet. We're working on merging them mainline.
> But it does basically work and we (Albert Herranz) got the SDIO chip on the Nintendo Wii running.
>
>
> --
> Greetings, Michael.
>
^ permalink raw reply
* [PATCH] mac80211: fix RX skb leaks
From: Johannes Berg @ 2009-08-24 9:46 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In mac80211's RX path some of the warnings that
warn about drivers passing invalid status values
leak the skb, fix that by refactoring the code.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/rx.c | 34 +++++++++++++++-------------------
1 file changed, 15 insertions(+), 19 deletions(-)
--- wireless-testing.orig/net/mac80211/rx.c 2009-08-24 11:42:11.000000000 +0200
+++ wireless-testing/net/mac80211/rx.c 2009-08-24 11:43:32.000000000 +0200
@@ -2447,17 +2447,13 @@ void ieee80211_rx(struct ieee80211_hw *h
struct ieee80211_supported_band *sband;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
- if (status->band < 0 ||
- status->band >= IEEE80211_NUM_BANDS) {
- WARN_ON(1);
- return;
- }
+ if (WARN_ON(status->band < 0 ||
+ status->band >= IEEE80211_NUM_BANDS))
+ goto drop;
sband = local->hw.wiphy->bands[status->band];
- if (!sband) {
- WARN_ON(1);
- return;
- }
+ if (WARN_ON(!sband))
+ goto drop;
/*
* If we're suspending, it is possible although not too likely
@@ -2466,25 +2462,21 @@ void ieee80211_rx(struct ieee80211_hw *h
* that might, for example, cause stations to be added or other
* driver callbacks be invoked.
*/
- if (unlikely(local->quiescing || local->suspended)) {
- kfree_skb(skb);
- return;
- }
+ if (unlikely(local->quiescing || local->suspended))
+ goto drop;
/*
* The same happens when we're not even started,
* but that's worth a warning.
*/
- if (WARN_ON(!local->started)) {
- kfree_skb(skb);
- return;
- }
+ if (WARN_ON(!local->started))
+ goto drop;
if (status->flag & RX_FLAG_HT) {
/* rate_idx is MCS index */
if (WARN_ON(status->rate_idx < 0 ||
status->rate_idx >= 76))
- return;
+ goto drop;
/* HT rates are not in the table - use the highest legacy rate
* for now since other parts of mac80211 may not yet be fully
* MCS aware. */
@@ -2492,7 +2484,7 @@ void ieee80211_rx(struct ieee80211_hw *h
} else {
if (WARN_ON(status->rate_idx < 0 ||
status->rate_idx >= sband->n_bitrates))
- return;
+ goto drop;
rate = &sband->bitrates[status->rate_idx];
}
@@ -2531,6 +2523,10 @@ void ieee80211_rx(struct ieee80211_hw *h
__ieee80211_rx_handle_packet(hw, skb, rate);
rcu_read_unlock();
+
+ return;
+ drop:
+ kfree_skb(skb);
}
EXPORT_SYMBOL(ieee80211_rx);
^ permalink raw reply
* driver_nl80211 broken again
From: Maxim Levitsky @ 2009-08-24 12:32 UTC (permalink / raw)
To: linux-wireless
First connection works fine, but all following connections hang
wpa_supplicant hard, and more than that, this is first time,
NetworkManager confused that much that it refuses flat to connect to my
network, even if I reload the wireless stack.
Only way to connect again, is to reload wireless stack, restart
wpa_supplicant, and restart NM, and this helps, only for one more shot.
My network is WPA2 protected, I use iwl3945, this is quite recent
regression (of course I use tip of wireless-testing)
Best regards,
Maxim Levitsky
^ permalink raw reply
* [PATCH 0/4] mwl8k: three bug fixes, and a cosmetic fix
From: Lennert Buytenhek @ 2009-08-24 13:42 UTC (permalink / raw)
To: linville, linux-wireless
Some more patches for wireless-testing:
- A bug fix to fix an inverted error test in mwl8k_bss_info_changed().
This was accidentally introduced in the last batch of changes.
- Two minor bug fixes for issues that exist in 2.6.31 as well, but
aren't really important enough to justify applying there.
- A cosmetic fix to clarify the difference between driver and device
info during probe.
^ permalink raw reply
* [PATCH 1/4] mwl8k: fix inverted error test in mwl8k_bss_info_changed()
From: Lennert Buytenhek @ 2009-08-24 13:42 UTC (permalink / raw)
To: linville, linux-wireless
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
---
drivers/net/wireless/mwl8k.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 41a708c..4d3353c 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -2617,7 +2617,7 @@ static void mwl8k_bss_info_changed(struct ieee80211_hw *hw,
priv->capture_beacon = false;
rc = mwl8k_fw_lock(hw);
- if (!rc)
+ if (rc)
return;
if (info->assoc) {
--
1.5.6.4
^ permalink raw reply related
* [PATCH 2/4] mwl8k: fix pci dma mapping leak in mwl8k_post_cmd() error path
From: Lennert Buytenhek @ 2009-08-24 13:42 UTC (permalink / raw)
To: linville, linux-wireless
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
---
drivers/net/wireless/mwl8k.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 4d3353c..a4336f4 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -1439,8 +1439,11 @@ static int mwl8k_post_cmd(struct ieee80211_hw *hw, struct mwl8k_cmd_pkt *cmd)
return -ENOMEM;
rc = mwl8k_fw_lock(hw);
- if (rc)
+ if (rc) {
+ pci_unmap_single(priv->pdev, dma_addr, dma_size,
+ PCI_DMA_BIDIRECTIONAL);
return rc;
+ }
priv->hostcmd_wait = &cmd_wait;
iowrite32(dma_addr, regs + MWL8K_HIU_GEN_PTR);
--
1.5.6.4
^ permalink raw reply related
* [PATCH 3/4] mwl8k: missing endian conversion when printing firmware command result
From: Lennert Buytenhek @ 2009-08-24 13:42 UTC (permalink / raw)
To: linville, linux-wireless
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
---
drivers/net/wireless/mwl8k.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index a4336f4..6e017db 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -1474,7 +1474,7 @@ static int mwl8k_post_cmd(struct ieee80211_hw *hw, struct mwl8k_cmd_pkt *cmd)
printk(KERN_ERR "%s: Command %s error 0x%x\n",
priv->name,
mwl8k_cmd_name(cmd->code, buf, sizeof(buf)),
- cmd->result);
+ le16_to_cpu(cmd->result));
}
return rc;
--
1.5.6.4
^ permalink raw reply related
* [PATCH 4/4] mwl8k: separate driver and device info reporting during probe
From: Lennert Buytenhek @ 2009-08-24 13:48 UTC (permalink / raw)
To: linville, linux-wireless
Only print the driver version once, and condense all per-PHY
information to a single line.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
---
drivers/net/wireless/mwl8k.c | 21 ++++++++++++---------
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 6e017db..746532e 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -164,7 +164,7 @@ struct mwl8k_priv {
u16 num_mcaddrs;
u8 hw_rev;
- __le32 fw_rev;
+ u32 fw_rev;
/*
* Running count of TX packets in flight, to avoid
@@ -2825,11 +2825,16 @@ static void mwl8k_finalize_join_worker(struct work_struct *work)
static int __devinit mwl8k_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
+ static int printed_version = 0;
struct ieee80211_hw *hw;
struct mwl8k_priv *priv;
int rc;
int i;
- u8 *fw;
+
+ if (!printed_version) {
+ printk(KERN_INFO "%s version %s\n", MWL8K_DESC, MWL8K_VERSION);
+ printed_version = 1;
+ }
rc = pci_enable_device(pdev);
if (rc) {
@@ -3004,13 +3009,11 @@ static int __devinit mwl8k_probe(struct pci_dev *pdev,
goto err_stop_firmware;
}
- fw = (u8 *)&priv->fw_rev;
- printk(KERN_INFO "%s: 88W%u %s\n", priv->name, priv->part_num,
- MWL8K_DESC);
- printk(KERN_INFO "%s: Driver Ver:%s Firmware Ver:%u.%u.%u.%u\n",
- priv->name, MWL8K_VERSION, fw[3], fw[2], fw[1], fw[0]);
- printk(KERN_INFO "%s: MAC Address: %pM\n", priv->name,
- hw->wiphy->perm_addr);
+ printk(KERN_INFO "%s: 88w%u v%d, %pM, firmware version %u.%u.%u.%u\n",
+ wiphy_name(hw->wiphy), priv->part_num, priv->hw_rev,
+ hw->wiphy->perm_addr,
+ (priv->fw_rev >> 24) & 0xff, (priv->fw_rev >> 16) & 0xff,
+ (priv->fw_rev >> 8) & 0xff, priv->fw_rev & 0xff);
return 0;
--
1.5.6.4
^ permalink raw reply related
* Re: [PATCHv4] b43 add harware tkip
From: John W. Linville @ 2009-08-24 14:20 UTC (permalink / raw)
To: gregor kowski; +Cc: Kalle Valo, linux-wireless, bcm43xx-dev, Michael Buesch
In-Reply-To: <83a869cd0908211443s1d366f70o202ae768a93b20dc@mail.gmail.com>
On Fri, Aug 21, 2009 at 11:43:55PM +0200, gregor kowski wrote:
> This add hardware tkip for b43. This can help to reduce the load a low
> powered router and make higher throughput. To enable it, you need to
> set "hwtkip" module param.
>
> Signed-off-by: Gregor Kowski <gregor.kowski@gmail.com>
> Acked-by: Michael Buesch <mb@bu3sch.de>
An earlier version was already merged. What is different here?
Please submit a new patch with just the differences.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [davem@davemloft.net: consider 2.6.31 a done deal...]
From: John W. Linville @ 2009-08-24 14:36 UTC (permalink / raw)
To: linux-wireless
FYI...obviously, this goes for wireless fixes for 2.6.31 as well...
----- Forwarded message from David Miller <davem@davemloft.net> -----
> Date: Sun, 23 Aug 2009 23:21:11 -0700 (PDT)
> From: David Miller <davem@davemloft.net>
> To: netdev@vger.kernel.org
> Subject: consider 2.6.31 a done deal...
> X-Mailer: Mew version 6.2.51 on Emacs 22.1 / Mule 5.0 (SAKAKI)
>
>
> At least that should be your mindset when you submit changes
> at this point. With the net-2.6 pull request I just sent to
> Linus, I really don't want to see anything submitted for
> net-2.6 unless it is EARTH SHATTERING.
>
> And chances are, the "super important" bug fix you might have for your
> driver is absolutely not EARTH SHATTERING.
>
> So don't even try to slip it by me. Ok? :-)
>
> net-next-2.6 submissions, on the other hand, are very highly
> encouraged :-)
>
> Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
----- End forwarded message -----
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [davem@davemloft.net: consider 2.6.31 a done deal...]
From: Bob Copeland @ 2009-08-24 15:18 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20090824143622.GC8998@tuxdriver.com>
On Mon, Aug 24, 2009 at 10:36 AM, John W.
Linville<linville@tuxdriver.com> wrote:
> FYI...obviously, this goes for wireless fixes for 2.6.31 as well...
>
Right-o, then I withdraw the request about that ath5k fix, we'll
just plan to send it @stable.
>> At least that should be your mindset when you submit changes
>> at this point. With the net-2.6 pull request I just sent to
>> Linus, I really don't want to see anything submitted for
>> net-2.6 unless it is EARTH SHATTERING.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: driver_nl80211 broken again
From: Johannes Berg @ 2009-08-24 14:08 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux-wireless
In-Reply-To: <1251117161.22951.4.camel@maxim-laptop>
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
On Mon, 2009-08-24 at 15:32 +0300, Maxim Levitsky wrote:
> First connection works fine, but all following connections hang
> wpa_supplicant hard, and more than that, this is first time,
> NetworkManager confused that much that it refuses flat to connect to my
> network, even if I reload the wireless stack.
>
> Only way to connect again, is to reload wireless stack, restart
> wpa_supplicant, and restart NM, and this helps, only for one more shot.
>
> My network is WPA2 protected, I use iwl3945, this is quite recent
> regression (of course I use tip of wireless-testing)
Need more info, works ok here (hwsim).
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [Fwd: [Bug 13725] p54 gets a "tx refused but queue active" WARNING from mac80211]
From: Larry Finger @ 2009-08-24 16:40 UTC (permalink / raw)
To: Chr; +Cc: wireless
Christian and Johannes,
A dongle running p54usb gets a "tx refused but queue active" WARNING
when used as an AP using hostapd and running 2.6.31-rc6 from Linus's
tree, even with my patch that fixed this problem in STA mode.
Christian, have you tested this configuration? Johannes - any thoughts?
I'm trying to reproduce the problem.
Larry
======================================================================
-------- Original Message --------
Subject: [Bug 13725] p54 gets a "tx refused but queue active" WARNING
from mac80211
Date: Mon, 24 Aug 2009 15:22:34 GMT
From: bugzilla-daemon@bugzilla.kernel.org
To: Larry.Finger@lwfinger.net
References: <bug-13725-734@http.bugzilla.kernel.org/>
http://bugzilla.kernel.org/show_bug.cgi?id=13725
--- Comment #3 from cortez8591@gmail.com 2009-08-24 15:22:33 ---
I'm using p54usb dongle with hostapd to share my Internet connection.
After
client connects with station and start browsing/downloading it takes
0.5 - 1min
and suddenly network sharing stops working. The only error message
comes from
dmesg and it is the error mentioned before. System load was from 0.10
to 0.30
max.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug.
^ permalink raw reply
* Re: [Fwd: [Bug 13725] p54 gets a "tx refused but queue active" WARNING from mac80211]
From: Chunkeey @ 2009-08-24 17:24 UTC (permalink / raw)
To: Larry Finger; +Cc: Max Filippov, wireless
> Christian and Johannes,
>
> A dongle running p54usb gets a "tx refused but queue active" WARNING
> when used as an AP using hostapd and running 2.6.31-rc6 from Linus's
> tree, even with my patch that fixed this problem in STA mode.
> Christian, have you tested this configuration? Johannes - any thoughts?
well, this particular WARN_ON can probably be fixed by reverting the following patch:
"p54: call p54_wake_free_queues on every p54_free_skb and p54_rx_frame_sent"
however, based on Max commit description this patch is necessary for p54spi to
work properly. So, I'm not going to touch it...
The best thing he can do now is to use compat-wireless.
(Or since he uses a -rc kernel anyway, why not wireless-testing?)
wireless-testing/cw does not only have a newer driver,
but also mac80211 improvements for power-saving clients.
________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/
^ permalink raw reply
* [PATCH] mac80211: Fix output of minstrels rc_stats
From: Arnd Hannemann @ 2009-08-24 17:42 UTC (permalink / raw)
To: linux-wireless; +Cc: Arnd Hannemann
An integer overflow in the minstrel debug code prevented the
throughput to be displayed correctly. This patch fixes that,
by swaping the division and multiplication.
Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
---
net/mac80211/rc80211_minstrel_debugfs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_debugfs.c b/net/mac80211/rc80211_minstrel_debugfs.c
index 98f4807..caf9453 100644
--- a/net/mac80211/rc80211_minstrel_debugfs.c
+++ b/net/mac80211/rc80211_minstrel_debugfs.c
@@ -83,7 +83,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
p += sprintf(p, "%3u%s", mr->bitrate / 2,
(mr->bitrate & 1 ? ".5" : " "));
- tp = ((mr->cur_tp * 96) / 18000) >> 10;
+ tp = ((mr->cur_tp / 18000) * 96) >> 10;
prob = mr->cur_prob / 18;
eprob = mr->probability / 18;
--
1.6.4.1
^ permalink raw reply related
* Re: [PATCH] mac80211: Fix output of minstrels rc_stats
From: Joe Perches @ 2009-08-24 17:57 UTC (permalink / raw)
To: Arnd Hannemann; +Cc: linux-wireless
In-Reply-To: <1251135778-27288-1-git-send-email-hannemann@nets.rwth-aachen.de>
On Mon, 2009-08-24 at 19:42 +0200, Arnd Hannemann wrote:
> An integer overflow in the minstrel debug code prevented the
> throughput to be displayed correctly. This patch fixes that,
> by swaping the division and multiplication.
>
> Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
> ---
> net/mac80211/rc80211_minstrel_debugfs.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/rc80211_minstrel_debugfs.c b/net/mac80211/rc80211_minstrel_debugfs.c
> index 98f4807..caf9453 100644
> --- a/net/mac80211/rc80211_minstrel_debugfs.c
> +++ b/net/mac80211/rc80211_minstrel_debugfs.c
> @@ -83,7 +83,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
> p += sprintf(p, "%3u%s", mr->bitrate / 2,
> (mr->bitrate & 1 ? ".5" : " "));
>
> - tp = ((mr->cur_tp * 96) / 18000) >> 10;
> + tp = ((mr->cur_tp / 18000) * 96) >> 10;
Maybe do_div instead?
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Herton Ronaldo Krzesinski @ 2009-08-24 18:03 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Hin-Tak Leung
In-Reply-To: <4A91F100.9040804@lwfinger.net>
Em Dom 23 Ago 2009, às 22:46:40, Larry Finger escreveu:
> Herton Ronaldo Krzesinski wrote:
> > This change implements rfkill support for RTL8187B and RTL8187L devices,
> > using new cfg80211 rfkill API.
> >
> > Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
> > ---
>
> I found a problem with this patch. When I issue an 'rfkill block 1'
> command, I get the following circular locking warning:
Hmm, this is a issue that was already present before the rfkill patch, but
seems with it, it became more likely to happen. Please try this patch:
[PATCH] rtl8187: fix circular locking (rtl8187_stop/rtl8187_work)
Larry Finger reports following lockdep warning:
[ INFO: possible circular locking dependency detected ]
2.6.31-rc6-wl #201
-------------------------------------------------------
rfkill/30578 is trying to acquire lock:
(&(&priv->work)->work#2){+.+...}, at: [<ffffffff81051215>]
__cancel_work_timer+0xd9/0x222
but task is already holding lock:
(&priv->conf_mutex#2){+.+.+.}, at: [<ffffffffa064a024>]
rtl8187_stop+0x31/0x364 [rtl8187]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&priv->conf_mutex#2){+.+.+.}:
[<ffffffff81065957>] __lock_acquire+0x12d0/0x1614
[<ffffffff81065d54>] lock_acquire+0xb9/0xdd
[<ffffffff8127c32f>] mutex_lock_nested+0x56/0x2a8
[<ffffffffa064a392>] rtl8187_work+0x3b/0xf2 [rtl8187]
[<ffffffff81050758>] worker_thread+0x1fa/0x30a
[<ffffffff81054ca5>] kthread+0x8f/0x97
[<ffffffff8100cb7a>] child_rip+0xa/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
-> #0 (&(&priv->work)->work#2){+.+...}:
[<ffffffff8106568c>] __lock_acquire+0x1005/0x1614
[<ffffffff81065d54>] lock_acquire+0xb9/0xdd
[<ffffffff8105124e>] __cancel_work_timer+0x112/0x222
[<ffffffff8105136b>] cancel_delayed_work_sync+0xd/0xf
[<ffffffffa064a33f>] rtl8187_stop+0x34c/0x364 [rtl8187]
[<ffffffffa0242866>] ieee80211_stop_device+0x29/0x61 [mac80211]
[<ffffffffa0239194>] ieee80211_stop+0x476/0x530 [mac80211]
[<ffffffff8120ce15>] dev_close+0x8a/0xac
[<ffffffffa01d9fa7>] cfg80211_rfkill_set_block+0x4a/0x7a [cfg80211]
[<ffffffffa01bf4f0>] rfkill_set_block+0x84/0xd9 [rfkill]
[<ffffffffa01bfc31>] rfkill_fop_write+0xda/0x124 [rfkill]
[<ffffffff810cf286>] vfs_write+0xae/0x14a
[<ffffffff810cf3e6>] sys_write+0x47/0x6e
[<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
The problem here is that rtl8187_stop, while helding priv->conf_mutex,
runs cancel_delayed_work_sync on an workqueue that runs rtl8187_work,
which also takes priv->conf_mutex lock. Move cancel_delayed_work_sync
out of rtl8187_stop priv->conf_mutex locking region.
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
---
drivers/net/wireless/rtl818x/rtl8187_dev.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index b6e9fbd..2017ccc 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -1018,9 +1018,10 @@ static void rtl8187_stop(struct ieee80211_hw *dev)
dev_kfree_skb_any(skb);
usb_kill_anchored_urbs(&priv->anchored);
+ mutex_unlock(&priv->conf_mutex);
+
if (!priv->is_rtl8187b)
cancel_delayed_work_sync(&priv->work);
- mutex_unlock(&priv->conf_mutex);
}
static int rtl8187_add_interface(struct ieee80211_hw *dev,
--
1.6.4.1
>
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.31-rc6-wl #201
> -------------------------------------------------------
> rfkill/30578 is trying to acquire lock:
> (&(&priv->work)->work#2){+.+...}, at: [<ffffffff81051215>]
> __cancel_work_timer+0xd9/0x222
>
> but task is already holding lock:
> (&priv->conf_mutex#2){+.+.+.}, at: [<ffffffffa064a024>]
> rtl8187_stop+0x31/0x364 [rtl8187]
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&priv->conf_mutex#2){+.+.+.}:
> [<ffffffff81065957>] __lock_acquire+0x12d0/0x1614
> [<ffffffff81065d54>] lock_acquire+0xb9/0xdd
> [<ffffffff8127c32f>] mutex_lock_nested+0x56/0x2a8
> [<ffffffffa064a392>] rtl8187_work+0x3b/0xf2 [rtl8187]
> [<ffffffff81050758>] worker_thread+0x1fa/0x30a
> [<ffffffff81054ca5>] kthread+0x8f/0x97
> [<ffffffff8100cb7a>] child_rip+0xa/0x20
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> -> #0 (&(&priv->work)->work#2){+.+...}:
> [<ffffffff8106568c>] __lock_acquire+0x1005/0x1614
> [<ffffffff81065d54>] lock_acquire+0xb9/0xdd
> [<ffffffff8105124e>] __cancel_work_timer+0x112/0x222
> [<ffffffff8105136b>] cancel_delayed_work_sync+0xd/0xf
> [<ffffffffa064a33f>] rtl8187_stop+0x34c/0x364 [rtl8187]
> [<ffffffffa0242866>] ieee80211_stop_device+0x29/0x61 [mac80211]
> [<ffffffffa0239194>] ieee80211_stop+0x476/0x530 [mac80211]
> [<ffffffff8120ce15>] dev_close+0x8a/0xac
> [<ffffffffa01d9fa7>] cfg80211_rfkill_set_block+0x4a/0x7a [cfg80211]
> [<ffffffffa01bf4f0>] rfkill_set_block+0x84/0xd9 [rfkill]
> [<ffffffffa01bfc31>] rfkill_fop_write+0xda/0x124 [rfkill]
> [<ffffffff810cf286>] vfs_write+0xae/0x14a
> [<ffffffff810cf3e6>] sys_write+0x47/0x6e
> [<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> other info that might help us debug this:
>
> 4 locks held by rfkill/30578:
> #0: (rfkill_global_mutex){+.+.+.}, at: [<ffffffffa01bfbbc>]
> rfkill_fop_write+0x65/0x124 [rfkill]
> #1: (rtnl_mutex){+.+.+.}, at: [<ffffffff81215a60>] rtnl_lock+0x12/0x14
> #2: (&rdev->devlist_mtx){+.+.+.}, at: [<ffffffffa01d9f89>]
> cfg80211_rfkill_set_block+0x2c/0x7a [cfg80211]
> #3: (&priv->conf_mutex#2){+.+.+.}, at: [<ffffffffa064a024>]
> rtl8187_stop+0x31/0x364 [rtl8187]
>
> stack backtrace:
> Pid: 30578, comm: rfkill Not tainted 2.6.31-rc6-wl #201
> Call Trace:
> [<ffffffff810641ec>] print_circular_bug_tail+0xc1/0xcc
> [<ffffffff8106568c>] __lock_acquire+0x1005/0x1614
> [<ffffffff81065d54>] lock_acquire+0xb9/0xdd
> [<ffffffff81051215>] ? __cancel_work_timer+0xd9/0x222
> [<ffffffff8105124e>] __cancel_work_timer+0x112/0x222
> [<ffffffff81051215>] ? __cancel_work_timer+0xd9/0x222
> [<ffffffff81063791>] ? mark_held_locks+0x4d/0x6b
> [<ffffffff8127db94>] ? _spin_unlock_irq+0x2b/0x30
> [<ffffffff81063a04>] ? trace_hardirqs_on_caller+0x10b/0x12f
> [<ffffffff81063a35>] ? trace_hardirqs_on+0xd/0xf
> [<ffffffff8127db94>] ? _spin_unlock_irq+0x2b/0x30
> [<ffffffffa00de2c4>] ? usb_kill_anchored_urbs+0x46/0x5c [usbcore]
> [<ffffffff8105136b>] cancel_delayed_work_sync+0xd/0xf
> [<ffffffffa064a33f>] rtl8187_stop+0x34c/0x364 [rtl8187]
> [<ffffffffa0242866>] ieee80211_stop_device+0x29/0x61 [mac80211]
> [<ffffffffa0239194>] ieee80211_stop+0x476/0x530 [mac80211]
> [<ffffffffa0238d68>] ? ieee80211_stop+0x4a/0x530 [mac80211]
> [<ffffffff81044a28>] ? local_bh_enable_ip+0xc8/0xcd
> [<ffffffff8127db65>] ? _spin_unlock_bh+0x2f/0x33
> [<ffffffff8121d116>] ? dev_deactivate+0x162/0x192
> [<ffffffff8120ce15>] dev_close+0x8a/0xac
> [<ffffffffa01d9fa7>] cfg80211_rfkill_set_block+0x4a/0x7a [cfg80211]
> [<ffffffffa01bf4f0>] rfkill_set_block+0x84/0xd9 [rfkill]
> [<ffffffffa01bfc31>] rfkill_fop_write+0xda/0x124 [rfkill]
> [<ffffffff8100ba9c>] ? sysret_check+0x27/0x62
> [<ffffffff810cf286>] vfs_write+0xae/0x14a
> [<ffffffff810cf3e6>] sys_write+0x47/0x6e
> [<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1bf
>
>
> Larry
--
[]'s
Herton
^ permalink raw reply related
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Herton Ronaldo Krzesinski @ 2009-08-24 18:10 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: linux-wireless, Larry Finger
In-Reply-To: <3ace41890908231238h32b85839qe74bce2852103402@mail.gmail.com>
Em Dom 23 Ago 2009, às 16:38:43, Hin-Tak Leung escreveu:
> On Sat, Aug 22, 2009 at 10:59 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> > On Sat, Aug 22, 2009 at 4:38 AM, Herton Ronaldo
> > Krzesinski<herton@mandriva.com.br> wrote:
> >> This change implements rfkill support for RTL8187B and RTL8187L devices,
> >> using new cfg80211 rfkill API.
> >>
> >> Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
> >
> > Tested-by: Hin-Tak Leung <htl10@users.sourceforge.net>
> >
> > Neat!
> >
> > I ran a ping to the router while flicking the switch on and off, and
> > have 'ping: sendmsg: Network is unreachable' in the middle. dmesg also
> > shows
>
> It appears that I wrote prematurely - flicking the switch with the
> patch seems to just do the equivalent of ifconfig down.
Yes, the equivalent of ifconfig down is what cfg80211 rfkill does in this case.
> (before the patch, the switch has no effect). However, NetworkManager
> soon notices the interface going down and ifup it again. So I have
> simply got a 30s to 1 minute disruption in connectivity.
This is strange, may be NetworkManager does something extra and for some reason
manages to wake up the interface again? I thought it would be unable to "if up"
the interface since -ERFKILL should be returned to it when switch is off...
>
> Is this intentional? I thought it is supposed to actually switch off
> the hardware, or is this how the code supposed to work?
> Maybe some component needs to let NM knows not to reenanble the device.
About taking interface down, thats expected, but I don't know about
NetworkManager, I was expecting it to be unable to "if up" the interface again.
>
> Hin-Tak
>
--
[]'s
Herton
^ permalink raw reply
* Re: [PATCH] mac80211: Fix output of minstrels rc_stats
From: Pavel Roskin @ 2009-08-24 18:20 UTC (permalink / raw)
To: Joe Perches; +Cc: Arnd Hannemann, linux-wireless
In-Reply-To: <1251136676.3873.28.camel@Joe-Laptop.home>
On Mon, 2009-08-24 at 10:57 -0700, Joe Perches wrote:
> On Mon, 2009-08-24 at 19:42 +0200, Arnd Hannemann wrote:
> > An integer overflow in the minstrel debug code prevented the
> > throughput to be displayed correctly. This patch fixes that,
> > by swaping the division and multiplication.
> >
> > Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
> > ---
> > net/mac80211/rc80211_minstrel_debugfs.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/net/mac80211/rc80211_minstrel_debugfs.c b/net/mac80211/rc80211_minstrel_debugfs.c
> > index 98f4807..caf9453 100644
> > --- a/net/mac80211/rc80211_minstrel_debugfs.c
> > +++ b/net/mac80211/rc80211_minstrel_debugfs.c
> > @@ -83,7 +83,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
> > p += sprintf(p, "%3u%s", mr->bitrate / 2,
> > (mr->bitrate & 1 ? ".5" : " "));
> >
> > - tp = ((mr->cur_tp * 96) / 18000) >> 10;
> > + tp = ((mr->cur_tp / 18000) * 96) >> 10;
>
> Maybe do_div instead?
How about this?
tp = mr->cur_tp / ((18000 << 10) / 96);
((18000 << 10) / 96) is exactly 192000.
--
Regards,
Pavel Roskin
^ 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