* Re: 2.6.31-rc2: Possible regression in rt61pci driver
From: Kalle Valo @ 2009-07-29 7:45 UTC (permalink / raw)
To: chris2553
Cc: Luis Correia, Johannes Berg, Pavel Roskin, linux-wireless,
Ivo van Doorn
In-Reply-To: <200907290803.46110.chris2553@googlemail.com>
Chris Clayton <chris2553@sky.com> writes:
> 4. Are there any plans to be able to switch power-saving on/off on a
> driver-by-driver basis. It seems to me, although I'm happy to be
> corrected, that it is either on or off for a given kernel, depending
> on CONFIG_MAC80211_DEFAULT_PS.
mac80211 drivers can control power save with IEEE80211_HW_SUPPORTS_PS
flag. Also it can runtime from user space with 'iwconfig wlan0 power
off'. nl80211 interface is on my todo list.
--
Kalle Valo
^ permalink raw reply
* Re: 2.6.31-rc2: Possible regression in rt61pci driver
From: Johannes Berg @ 2009-07-29 7:21 UTC (permalink / raw)
To: chris2553; +Cc: Luis Correia, Pavel Roskin, linux-wireless, Ivo van Doorn
In-Reply-To: <200907290803.46110.chris2553@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
On Wed, 2009-07-29 at 08:03 +0100, Chris Clayton wrote:
> 3. Once power-saving kicks in, the machine cannot be contacted from another machine on the network -
> pings are not responded to, for example. Is this the intended behaviour?
No. The device is supposed to listen to beacons, check if there's
traffic pending and retrieve it. So sounds like a device problem unless
your AP is broken.
> 4. Are there any plans to be able to switch power-saving on/off on a driver-by-driver basis. It
> seems to me, although I'm happy to be corrected, that it is either on or off for a given kernel,
> depending on CONFIG_MAC80211_DEFAULT_PS. But, if like me, someone has two cards (one at home and one
> at work, for example), one that works fine with PS and one that doesn't, they have to set PS off
> for their kernel, or have two kernels. Could PS be {en,dis}abled by, say, a module parameter or a
> sysfs switch?
iwconfig wlan0 power off
(yeah, looks weird, but power means "power saving")
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: 31-rc3-mmotm0716 - wonky wireless statistics..
From: Johannes Berg @ 2009-07-29 7:19 UTC (permalink / raw)
To: Zhu Yi
Cc: Valdis.Kletnieks@vt.edu, Andrew Morton,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <1248831078.3747.1117.camel@debian>
[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]
On Wed, 2009-07-29 at 09:31 +0800, Zhu Yi wrote:
> > # cat /proc/net/wireless
> > Inter-| sta-| Quality | Discarded packets | Missed | WE
> > face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
> > wlan0: 0000 63. -47. -256 0 0 0 0 0 0
> > wlan1: 0000 0 0 0 0 0 0 0 0 0
> > wlan2: 0000 0 0 0 0 0 0 0 0 0
> >
> > Where did that -256 for "noise" come from? It ends up confusing the
> > gkrellm-wifi plugin, it reports a S/N of 219dB ;)
>
> This should be related to http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=fdb897ea5c77836f890033d563336ab0c94c9222
>
> But I don't think this is an ABI broken. User space should parse the
> trailing '.' to see if a field is updated or not because there are cards
> not capable to report hardware noise level anyway. Johannes?
So I had to look at the code to figure out wtf is going on.
Then the value shown is calculated as:
((__s32) stats->qual.noise) - ((stats->qual.updated & IW_QUAL_DBM) ? 0x100 : 0)
and since we have dBm for the signal strength (and dBm is "all or
nothing") you get -256 since we don't fill noise right now.
However, it goes on like this:
stats->qual.updated & IW_QUAL_NOISE_UPDATED ? '.' : ' '
so you're right -- the tool shouldn't be using the value unless followed
by a dot (".").
Thus, your analysis is correct as far as I can tell -- it's a userspace
bug and your userspace just happened to work correctly with this card,
but would have been broken with almost all other wireless cards.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] orinoco: enable cfg80211 "set_channel" operation
From: Holger Schurig @ 2009-07-29 7:16 UTC (permalink / raw)
To: Dave; +Cc: linux-wireless, Pavel Roskin, orinoco-devel, John W. Linville
In-Reply-To: <4A6F270A.7030002@gmail.com>
On Tuesday 28 July 2009 18:27:54 Dave wrote:
> You can also eliminate orinoco_ioctl_setfreq from wext.c with
> this change.
You mean this ?!?
--- linux-wl.orig/drivers/net/wireless/orinoco/wext.c
+++ linux-wl/drivers/net/wireless/orinoco/wext.c
@@ -372,55 +372,6 @@
return 0;
}
-static int orinoco_ioctl_setfreq(struct net_device *dev,
- struct iw_request_info *info,
- struct iw_freq *frq,
- char *extra)
-{
- struct orinoco_private *priv = ndev_priv(dev);
- int chan = -1;
- unsigned long flags;
- int err = -EINPROGRESS; /* Call commit handler */
-
- /* In infrastructure mode the AP sets the channel */
- if (priv->iw_mode == NL80211_IFTYPE_STATION)
- return -EBUSY;
-
- if ((frq->e == 0) && (frq->m <= 1000)) {
- /* Setting by channel number */
- chan = frq->m;
- } else {
- /* Setting by frequency */
- int denom = 1;
- int i;
-
- /* Calculate denominator to rescale to MHz */
- for (i = 0; i < (6 - frq->e); i++)
- denom *= 10;
-
- chan = ieee80211_freq_to_dsss_chan(frq->m / denom);
- }
-
- if ((chan < 1) || (chan > NUM_CHANNELS) ||
- !(priv->channel_mask & (1 << (chan-1))))
- return -EINVAL;
-
- if (orinoco_lock(priv, &flags) != 0)
- return -EBUSY;
-
- priv->channel = chan;
- if (priv->iw_mode == NL80211_IFTYPE_MONITOR) {
- /* Fast channel change - no commit if successful */
- hermes_t *hw = &priv->hw;
- err = hermes_docmd_wait(hw, HERMES_CMD_TEST |
- HERMES_TEST_SET_CHANNEL,
- chan, NULL);
- }
- orinoco_unlock(priv, &flags);
-
- return err;
-}
-
static int orinoco_ioctl_getfreq(struct net_device *dev,
struct iw_request_info *info,
struct iw_freq *frq,
@@ -1481,7 +1432,6 @@
static const iw_handler orinoco_handler[] = {
STD_IW_HANDLER(SIOCSIWCOMMIT, orinoco_ioctl_commit),
STD_IW_HANDLER(SIOCGIWNAME, cfg80211_wext_giwname),
- STD_IW_HANDLER(SIOCSIWFREQ, orinoco_ioctl_setfreq),
STD_IW_HANDLER(SIOCGIWFREQ, orinoco_ioctl_getfreq),
STD_IW_HANDLER(SIOCSIWMODE, cfg80211_wext_siwmode),
STD_IW_HANDLER(SIOCGIWMODE, cfg80211_wext_giwmode),
I tried, but with then an "iwconfig eth1 channel 1" gave me an
error. I did not investigate this further.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: 2.6.31-rc2: Possible regression in rt61pci driver
From: Chris Clayton @ 2009-07-29 7:03 UTC (permalink / raw)
To: Luis Correia; +Cc: Johannes Berg, Pavel Roskin, linux-wireless, Ivo van Doorn
In-Reply-To: <efe7343f0907280638i12b0bb4bq237ca4f6376eb1fe@mail.gmail.com>
On Tuesday 28 July 2009, Luis Correia wrote:
> Chris
>
> On Tue, Jul 28, 2009 at 14:34, Chris Clayton<chris2553@googlemail.com> wrote:
> > 2009/7/28 Luis Correia <luis.f.correia@gmail.com>:
> >> Hi Chris
> >>
> >> Can you do a very dumb test for me?
> >>
> >> Boot your laptop by adding 'irqpoll' to the kernel command line
> >> options and see if the problem still occours.
> >
> > Not so dumb a request, actually. Running -rc4 with the irqpoll
> > command line option, the laptop has just survived 30 minutes without a
> > freeze. It can't survive more than 5 minutes without that option.
Well, the laptop ran -rc4-git2 all evening yesterday without freezing. So using the irqpoll option
seems to be an answer. A few questions and observations though:
1. Are we sure that it is the power-saving change that _caused_ this problem? Could it be that some
other bug is simply unmasked by the power-saving change? I ask this because I noticed yesterday
that the card's network LED switches off several seconds before the laptop freezes.
2. When power-saving kicks in, the network LED on the card is switched off. (At least I'm assuming
that is what switches the LED off) When the card is woken up again, neither the network nor activity
LED lights-up ever again. IMHO, this is a bug.
3. Once power-saving kicks in, the machine cannot be contacted from another machine on the network -
pings are not responded to, for example. Is this the intended behaviour?
4. Are there any plans to be able to switch power-saving on/off on a driver-by-driver basis. It
seems to me, although I'm happy to be corrected, that it is either on or off for a given kernel,
depending on CONFIG_MAC80211_DEFAULT_PS. But, if like me, someone has two cards (one at home and one
at work, for example), one that works fine with PS and one that doesn't, they have to set PS off
for their kernel, or have two kernels. Could PS be {en,dis}abled by, say, a module parameter or a
sysfs switch?
Thanks,
Chris
> >
> > Chris
>
> Well, if the laptop hangs on working without any problems, this may
> proove to be some strange kind of hardware incompatibility.
>
> The irqpoll option solves some of the interrupt related problems, by
> polling them instead of 'grabbing' them (at least that is what I think
> it is happening, correct me if I'm wrong:))
>
>
> Luis Correia
> rt2x00 project admin
--
No, Sir; there is nothing which has yet been contrived by man, by which
so much happiness is produced as by a good tavern or inn - Doctor Samuel
Johnson
^ permalink raw reply
* [RFC PATCH] rt61pci: fix module reloading with power saving enabled
From: Pavel Roskin @ 2009-07-29 5:52 UTC (permalink / raw)
To: linux-wireless, users
Unloading rt61pci can leave the device in such state that reloading
rt61pci would fail to reinitialize it. Bogus data would be read from
the EEPROM and the RF version won't be recognized. Only reboot would
return the device to a sane state.
It appears that it happens if rt61pci is unloaded while power saving is
active. To initialize the device properly, SOFT_RESET_CSR should be set
to the same value as rt61pci_config_ps() uses to wake up the device.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
I don't know what 0x00000007 is and I don't want to make up a name for
it.
rt61pci_config_ps() does other things, but this is the minimal required
change. If anyone has a specification for rt61, it should mention
SOFT_RESET_CSR and possibly other registers to be set before EEPROM may
be accessed.
Please note that unloading rt61pci (as well as rt73usb) can trigger an
oops or panic in sysfs code that I didn't have a chance to fix yet.
It's very elusive and manifests differently every time. Fortunately
(for everyone not debugging it), it's rare.
drivers/net/wireless/rt2x00/rt61pci.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index fb95b8c..f615fe6 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -2600,6 +2600,8 @@ static int rt61pci_probe_hw(struct rt2x00_dev *rt2x00dev)
{
int retval;
+ rt2x00pci_register_write(rt2x00dev, SOFT_RESET_CSR, 0x00000007);
+
/*
* Allocate eeprom data.
*/
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: [PATCH 2/2] at76c50x-usb: cancel scan work at stop callback
From: Kalle Valo @ 2009-07-29 5:41 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless
In-Reply-To: <1248720984-15922-3-git-send-email-lrodriguez@atheros.com>
"Luis R. Rodriguez" <lrodriguez@Atheros.com> writes:
> This should fix suspend as mac80211 expects all work queued
> to the mac80211 workqueue to be canceled at driver stop().
>
> Cc: Kalle Valo <kalle.valo@iki.fi>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Indeed, the original implementation doesn't make any sense. Thanks for
looking at at76c50x-usb.
Acked-by: Kalle Valo <kalle.valo@iki.fi>
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] ar76c50x-usb: cancel promisc work during mac80211 stop
From: Kalle Valo @ 2009-07-29 5:39 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless
In-Reply-To: <1248720984-15922-2-git-send-email-lrodriguez@atheros.com>
"Luis R. Rodriguez" <lrodriguez@Atheros.com> writes:
> We weren't ever cancelling this.
>
> Cc: Kalle Valo <kalle.valo@iki.fi>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Thanks.
Acked-by: Kalle Valo <kalle.valo@iki.fi>
--
Kalle Valo
^ permalink raw reply
* Re: 31-rc3-mmotm0716 - wonky wireless statistics..
From: Zhu Yi @ 2009-07-29 1:31 UTC (permalink / raw)
To: Valdis.Kletnieks@vt.edu, Johannes Berg
Cc: Andrew Morton, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org
In-Reply-To: <5934.1248814870@turing-police.cc.vt.edu>
On Wed, 2009-07-29 at 05:01 +0800, Valdis.Kletnieks@vt.edu wrote:
> Dell Latitude D820 laptop, lspci reports the network card as:
>
> 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Netwo rk Connection (rev 02)
>
> iwlwifi driver in use, card associated via wpa_supplicant but not being
> actively used
>
> # iwconfig
> wlan0 IEEE 802.11abg ESSID:"VT-Wireless"
> Mode:Managed Frequency:2.447 GHz Access Point: 00:11:20:A4:4C:10
> Bit Rate=54 Mb/s Tx-Power=15 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:<lopped out> [2]
> Link Quality=62/70 Signal level=-48 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
> # cat /proc/net/wireless
> Inter-| sta-| Quality | Discarded packets | Missed | WE
> face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
> wlan0: 0000 63. -47. -256 0 0 0 0 0 0
> wlan1: 0000 0 0 0 0 0 0 0 0 0
> wlan2: 0000 0 0 0 0 0 0 0 0 0
>
> Where did that -256 for "noise" come from? It ends up confusing the
> gkrellm-wifi plugin, it reports a S/N of 219dB ;)
This should be related to http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=fdb897ea5c77836f890033d563336ab0c94c9222
But I don't think this is an ABI broken. User space should parse the
trailing '.' to see if a field is updated or not because there are cards
not capable to report hardware noise level anyway. Johannes?
Thanks,
-yi
^ permalink raw reply
* [PATCH] b43: Work around mac80211 race condition that may transmit one packet after queue is stopped
From: Larry Finger @ 2009-07-29 1:21 UTC (permalink / raw)
To: John W Linville, Michael Buesch; +Cc: Johannes Berg, linux-wireless
As shown in http://thread.gmane.org/gmane.linux.kernel.wireless.general/36497,
mac80211 has a bug that allows a call to the TX routine after the queues have
been stopped. This situation will only occur under extreme stress. Although
b43 does not crash when this condition occurs, it does generate a WARN_ON and
also logs a queue overrun message. This patch recognizes b43 is not at fault
and logs a message only when the most verbose debugging mode is enabled. In
the unlikely event that the queue is not stopped when the DMA queue becomes
full, then a warning is issued.
During testing of this patch with one output stream running repeated tcpperf
writes and a second running a flood ping, this routine was entered with
the DMA ring stopped about once per hour. The condition where the DMA queue is
full but the ring has not been stopped has never been seen by me.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
John,
This patch is 2.6.32 material.
Larry
---
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c
+++ wireless-testing/drivers/net/wireless/b43/dma.c
@@ -1334,13 +1334,23 @@ int b43_dma_tx(struct b43_wldev *dev, st
spin_lock_irqsave(&ring->lock, flags);
B43_WARN_ON(!ring->tx);
- /* Check if the queue was stopped in mac80211,
- * but we got called nevertheless.
- * That would be a mac80211 bug. */
- B43_WARN_ON(ring->stopped);
+
+ if (unlikely(ring->stopped)) {
+ /* We get here only because of a bug in mac80211.
+ * Because of a race, one packet may be queued after
+ * the queue is stopped, thus we got called when we shouldn't.
+ * For now, just refuse the transmit. */
+ if (b43_debug(dev, B43_DBG_DMAVERBOSE))
+ b43err(dev->wl, "Packet after queue stopped\n");
+ err = -ENOSPC;
+ goto out_unlock;
+ }
if (unlikely(free_slots(ring) < TX_SLOTS_PER_FRAME)) {
- b43warn(dev->wl, "DMA queue overflow\n");
+ /* If we get here, we have a real error with the queue
+ * full, but queues not stopped. */
+ b43err(dev->wl, "DMA queue overflow\n");
+ WARN_ON(1);
err = -ENOSPC;
goto out_unlock;
}
^ permalink raw reply
* Re: [PATCH 2.6.31] mac80211: fix suspend
From: Jan Scholz @ 2009-07-28 23:51 UTC (permalink / raw)
To: Johannes Berg
Cc: John Linville, Jan Scholz, linux-wireless, Bob Copeland,
Rafael J. Wysocki, Tomas Janousek, linux-kernel
In-Reply-To: <1248797417.13742.0.camel@johannes.local>
I applied the patch to v2.6.31-rc4 and suspend works just fine.
Thanks,
Jan
Johannes Berg <johannes@sipsolutions.net> writes:
> Jan reported that his b43-based laptop hangs during suspend.
> The problem turned out to be mac80211 asking the driver to
> stop the hardware before removing interfaces, and interface
> removal caused b43 to touch the hardware (while down, which
> causes the hang).
>
> This patch fixes mac80211 to do reorder these operations to
> have them in the correct order -- first remove interfaces
> and then stop the hardware. Some more code is necessary to
> be able to do so in a race-free manner, in particular it is
> necessary to not process frames received during quiescing.
>
> Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13337.
>
> Reported-by: Jan Scholz <scholz@fias.uni-frankfurt.de>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> net/mac80211/pm.c | 24 +++++++++++++++---------
> net/mac80211/rx.c | 12 ++++++++++++
> 2 files changed, 27 insertions(+), 9 deletions(-)
>
> --- wireless-testing.orig/net/mac80211/pm.c 2009-07-28 17:58:11.000000000 +0200
> +++ wireless-testing/net/mac80211/pm.c 2009-07-28 18:06:25.000000000 +0200
> @@ -54,15 +54,6 @@ int __ieee80211_suspend(struct ieee80211
>
> rcu_read_unlock();
>
> - /* flush again, in case driver queued work */
> - flush_workqueue(local->hw.workqueue);
> -
> - /* stop hardware - this must stop RX */
> - if (local->open_count) {
> - ieee80211_led_radio(local, false);
> - drv_stop(local);
> - }
> -
> /* remove STAs */
> spin_lock_bh(&local->sta_lock);
> list_for_each_entry(sta, &local->sta_list, list) {
> @@ -110,7 +101,22 @@ int __ieee80211_suspend(struct ieee80211
> drv_remove_interface(local, &conf);
> }
>
> + /* stop hardware - this must stop RX */
> + if (local->open_count) {
> + ieee80211_led_radio(local, false);
> + drv_stop(local);
> + }
> +
> + /*
> + * flush again, in case driver queued work -- it
> + * shouldn't be doing (or cancel everything in the
> + * stop callback) that but better safe than sorry.
> + */
> + flush_workqueue(local->hw.workqueue);
> +
> local->suspended = true;
> + /* need suspended to be visible before quiescing is false */
> + barrier();
> local->quiescing = false;
>
> return 0;
> --- wireless-testing.orig/net/mac80211/rx.c 2009-07-28 17:58:52.000000000 +0200
> +++ wireless-testing/net/mac80211/rx.c 2009-07-28 18:04:24.000000000 +0200
> @@ -2441,6 +2441,18 @@ void __ieee80211_rx(struct ieee80211_hw
> return;
> }
>
> + /*
> + * If we're suspending, it is possible although not too likely
> + * that we'd be receiving frames after having already partially
> + * quiesced the stack. We can't process such frames then since
> + * 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 (status->flag & RX_FLAG_HT) {
> /* rate_idx is MCS index */
> if (WARN_ON(status->rate_idx < 0 ||
>
^ permalink raw reply
* Re: ath5k connection loss (failed to wakeup the MAC Chip)
From: Nick Kossifidis @ 2009-07-28 23:53 UTC (permalink / raw)
To: Adrian von Bidder; +Cc: linux-wireless
In-Reply-To: <200907280838.42541@fortytwo.ch>
2009/7/28 Adrian von Bidder <avbidder@fortytwo.ch>:
> Heyho!
>
> (This is using kernel 2.6.31-rc3 as packaged by Debian)
>
> While taking a full backup of my laptop, I noticed that after a few 100M the
> ath5k can't connect to WLAN anymore.
>
[...]
> This only happens with bulk data transfers, and probably only when sending.
> Downloading large dataset over WLAN is fine (I haven't tested it as much as
> sending, though: downloads are mostly small, while the bulk sending happens
> regularly during backup.)
>
> It is not related to how long the WLAN is up: I can work for days or weeks
> (happened with earlier kernels as well) with this laptop, over
> suspend/resume, and WLAN works fine. It's only when I run backup that it
> happens (always - but I since backups usually are incremental, they're often
> small enough. But once I do a full backup WLAN goes down. So use cable for
> those...)
>
> Is this known? Can I get you more information?
>
> Hardware is Acer AOA 150.
>
> thanks
Working on it, can you please post the part when ath5k loads ?
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* ar9170 DWA 160A
From: Luis R. Rodriguez @ 2009-07-28 23:46 UTC (permalink / raw)
To: linux-wireless, otus-devel; +Cc: Felix Bitterli
We have these listed on ar9170 wiki page as under Dlink DWA160A:
0x07d1:0x3c10
0x0846:0x9010
A user just reported thy purchased DWA160 by mistake thinking it was
the same but it turns out it has some other wireless chipset. Do any
of you have a DWA160A that is claimed by ar9170 or should we remove
this from the list?
Luis
^ permalink raw reply
* ath5k does multicast filtering in monitor mode
From: Pavel Roskin @ 2009-07-28 23:02 UTC (permalink / raw)
To: linux-wireless
Hello!
It turns out ath5k doesn't receive multicast packets while in monitor
mode. Multicast packets are only received on the interface if it's set
to a promiscuous or allmulti mode of if the multicast address I need is
added by "ip maddr add".
Wireshark puts interfaces in promiscuous mode, but some utility I wrote
wasn't doing that, so it could not capture multicast packets with ath5k.
Do we have any standard whether multicast filtering is allowed in
monitor mode? Should I fix ath5k or the userspace program?
--
Regards,
Pavel Roskin
^ permalink raw reply
* RE: kernel panic ieee80211_agg_splice_packets+0x3d/0xc0 [mac80211]
From: Pavel Roskin @ 2009-07-28 22:48 UTC (permalink / raw)
To: Jack Lau; +Cc: linux-wireless
In-Reply-To: <BAY0-DP3-241EC0B1A0E15935251FCBBD150@phx.gbl>
On Tue, 2009-07-28 at 21:21 +0000, Jack Lau wrote:
> > I have enabled debugging in config.mk and installed it.
I didn't suggest that. I think it's irrelevant. Only the setting
in .config is relevant.
If you are using compat-wireless, I suggest that you try the current
kernel from wireless-testing. It was quite unstable a few days ago, but
it should be cleaned up by now. Since you are using the AP mode, you'll
need this patch, it's still not applied as of now:
http://marc.info/?l=linux-wireless&m=124871936602667&w=2
compat-wireless is great if everything is working, but if something is
broken, the first suspicion is that compat-wireless doesn't backport
something correctly.
> The kernel already has debugging enabled as I have examined the
> source from Ubuntu.
Please be specific what you found and where. I don't have Ubuntu
around, but others could correct you if you are looking in a wrong
place.
> > When I load the gdb command, I just get no debugging symbols found
> and with the l command I just get no symbol file now.
Please don't rephrase tell the error messages, especially if you don't
understand them fully. I cannot see from your words why there are no
debugging symbols.
Also please don't top-post, as it makes it harder to quote the
discussion in a reasonable way.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add networking wireless drivers section
From: Johannes Berg @ 2009-07-28 21:33 UTC (permalink / raw)
To: David Miller
Cc: joe, linville, julia, netdev, linux-kernel, kernel-janitors,
linux-wireless
In-Reply-To: <20090728.113353.08715297.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 662 bytes --]
On Tue, 2009-07-28 at 11:33 -0700, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Tue, 28 Jul 2009 11:06:37 -0700
>
> > On Tue, 2009-07-28 at 10:30 -0700, David Miller wrote:
> >> Wireless patches need to be CC:'d to linux-wireless so that
> >> John Linville can notice and pick them up
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
>
> Why not just create a plain "WIRELESS" umbrella entry
> that contains all of drivers/net/wireless, net/mac80211,
> and net/wireless?
I'll happily maintain net/mac80211 and net/wireless, but won't be
touching all the old crappy drivers/net/wireless with a long stick.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* RE: kernel panic ieee80211_agg_splice_packets+0x3d/0xc0 [mac80211]
From: Jack Lau @ 2009-07-28 21:21 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1248640816.32168.42.camel@mj>
----------------------------------------
> From: jackelectronics@hotmail.com
> To: proski@gnu.org
> Subject: RE: kernel panic ieee80211_agg_splice_packets+0x3d/0xc0 [mac80211]
> Date: Tue, 28 Jul 2009 20:34:07 +0000
>
>
> Dear Pavel
>
> I have tried your suggestion and I am getting absolutely nowhere with it.
>
> I have enabled debugging in config.mk and installed it. The kernel already has debugging enabled as I have examined the source from Ubuntu.
>
> When I load the gdb command, I just get no debugging symbols found and with the l command I just get no symbol file now.
>
> I know this may sound really simple to you but I have so little experience with programming and please don't leave me on my own to try and sort the problem out.
>
> Remember, I only install and configure Linux because it is free and lots to learn from but I really don't do programming.
>
> Regards
>
>
> Jack
>
> ----------------------------------------
>> Subject: Re: kernel panic ieee80211_agg_splice_packets+0x3d/0xc0 [mac80211]
>> From: proski@gnu.org
>> To: jackelectronics@hotmail.com
>> CC: linux-wireless@vger.kernel.org
>> Date: Sun, 26 Jul 2009 16:40:16 -0400
>>
>> On Sun, 2009-07-26 at 17:35 +0000, Jack Lau wrote:
>>>
>>> This is my very first post on a public mailing list where I am not
>>> into programming. I just set up and configure Linux but have very
>>> little experience with programing except BASIC and shell scripting.
>>>
>>> I have recently assembled a Linux server and router (no GUI) where I
>>> am using an Atheros AR9160 controller (Sparklan WMIA-268N) as an
>>> access point. I am using Ubuntu 9.04 jaunty release but using hostapd
>>> 0.69 from the upcoming 9.10 karmic release because the one that comes
>>> with jaunty does not support nl80211.
>>>
>>> The problem is that I am constantly getting kernel panics, each time
>>> of the same error kernel panic ieee80211_agg_splice_packets+0x3d/0xc0
>>> [mac80211]
>>
>> You can find where it happens if you kernel is compiled with the debug
>> information (CONFIG_DEBUG_INFO in .config). Load the mac80211 module in
>> gdb:
>>
>> gdb /lib/modules/`uname -r`/kernel/net/mac80211/mac80211.ko
>>
>> On the gdb prompt, run:
>>
>> l *(ieee80211_agg_splice_packets+0x3d)
>>
>> Actually, ieee80211_agg_splice_packets is a short function. Perhaps you
>> could add debug print statements to find possible errors. For instance,
>> local->hw is used. It would crash if local is NULL. So you add before
>> that place:
>>
>> printk("local = %p\n", local);
>>
>> Likewise, check sta, sta->ampdu_mlme.tid_tx[tid] and local->pending. Or
>> just print the line numbers. You will see which printk is run last
>> before the crash.
>>
>>> I enclose screenshots of 3 occurrences, the last occurrence with the
>>> options nosmp noacpi acpi=off noapic just to see if it solves the
>>> problem but it didn't. Most frustratingly, I hate it when I am the
>>> only person experiencing it because searching Google yields nothing
>>> with this error.
>>
>> Chances are it's because 802.11n is not used much with ath9k in AP mode.
>>
>> --
>> Regards,
>> Pavel Roskin
> _________________________________________________________________
> With Windows Live, you can organise, edit, and share your photos.
> http://clk.atdmt.com/UKM/go/134665338/direct/01/
_________________________________________________________________
Windows Live Messenger: Celebrate 10 amazing years with free winks and emoticons.
http://clk.atdmt.com/UKM/go/157562755/direct/01/
^ permalink raw reply
* 31-rc3-mmotm0716 - wonky wireless statistics..
From: Valdis.Kletnieks @ 2009-07-28 21:01 UTC (permalink / raw)
To: Andrew Morton, Zhu Yi; +Cc: linux-kernel, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]
Dell Latitude D820 laptop, lspci reports the network card as:
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Netwo rk Connection (rev 02)
iwlwifi driver in use, card associated via wpa_supplicant but not being
actively used
# iwconfig
wlan0 IEEE 802.11abg ESSID:"VT-Wireless"
Mode:Managed Frequency:2.447 GHz Access Point: 00:11:20:A4:4C:10
Bit Rate=54 Mb/s Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:<lopped out> [2]
Link Quality=62/70 Signal level=-48 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
# cat /proc/net/wireless
Inter-| sta-| Quality | Discarded packets | Missed | WE
face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
wlan0: 0000 63. -47. -256 0 0 0 0 0 0
wlan1: 0000 0 0 0 0 0 0 0 0 0
wlan2: 0000 0 0 0 0 0 0 0 0 0
Where did that -256 for "noise" come from? It ends up confusing the
gkrellm-wifi plugin, it reports a S/N of 219dB ;)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH] orinoco: enable cfg80211 "set_channel" operation
From: Dave @ 2009-07-28 20:42 UTC (permalink / raw)
To: Johannes Berg
Cc: Holger Schurig, linux-wireless, Pavel Roskin, orinoco-devel,
John W. Linville
In-Reply-To: <1248798699.13742.3.camel@johannes.local>
Johannes Berg wrote:
> On Tue, 2009-07-28 at 18:29 +0200, Johannes Berg wrote:
>> On Tue, 2009-07-28 at 17:27 +0100, Dave wrote:
>>
>>> Looks right for monitor mode (as you tested), but for ad-hoc the channel
>>> change would be delayed until the next SIOCSIWCOMMIT. Which for cfg80211
>>> is currently only on change_vif.
>> You won't be getting this call for ad-hoc mode, because then the channel
>> is contained in the ibss_join() parameters.
>
>
>>> You can also eliminate orinoco_ioctl_setfreq from wext.c with this
>>> change.
>
> That also means you can't eliminate that, of course, since for connect()
> the channels is also contained in the parameters, and the set_freq isn't
> invoked.
Ah. Thanks for the corrections.
Dave.
^ permalink raw reply
* Re: [PATCH] libertas: Read outside array bounds
From: Dan Williams @ 2009-07-28 20:22 UTC (permalink / raw)
To: Roel Kluin; +Cc: libertas-dev, linux-wireless, Andrew Morton
In-Reply-To: <4A6EAFF3.8050502@gmail.com>
On Tue, 2009-07-28 at 09:59 +0200, Roel Kluin wrote:
> reads bss->rates[j] before checking bounds of index, and should use
> ARRAY_SIZE to determine the size of the array.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> ---
> diff --git a/drivers/net/wireless/libertas/scan.c b/drivers/net/wireless/libertas/scan.c
> index 601b542..6c95af3 100644
> --- a/drivers/net/wireless/libertas/scan.c
> +++ b/drivers/net/wireless/libertas/scan.c
> @@ -5,6 +5,7 @@
> * for sending scan commands to the firmware.
> */
> #include <linux/types.h>
> +#include <linux/kernel.h>
> #include <linux/etherdevice.h>
> #include <linux/if_arp.h>
> #include <asm/unaligned.h>
> @@ -876,7 +877,7 @@ static inline char *lbs_translate_scan(struct lbs_private *priv,
> iwe.u.bitrate.disabled = 0;
> iwe.u.bitrate.value = 0;
>
> - for (j = 0; bss->rates[j] && (j < sizeof(bss->rates)); j++) {
> + for (j = 0; j < ARRAY_SIZE(bss->rates) && bss->rates[j]; j++) {
> /* Bit rate given in 500 kb/s units */
> iwe.u.bitrate.value = bss->rates[j] * 500000;
> current_val = iwe_stream_add_value(info, start, current_val,
^ permalink raw reply
* Re: [PATCH] cfg80211: fix disassoc while not associated
From: Maxim Levitsky @ 2009-07-28 19:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1248682948.19945.27.camel@johannes.local>
On Mon, 2009-07-27 at 10:22 +0200, Johannes Berg wrote:
> When trying to disassociate while not associated,
> the kernel would crash rather than refusing the
> operation, fix this;
>
> Reported-by: Maxim Levitsky <maximlevitsky@gmail.com>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> net/wireless/mlme.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> --- wireless-testing.orig/net/wireless/mlme.c 2009-07-27 10:20:17.000000000 +0200
> +++ wireless-testing/net/wireless/mlme.c 2009-07-27 10:20:56.000000000 +0200
> @@ -545,6 +545,12 @@ static int __cfg80211_mlme_disassoc(stru
>
> ASSERT_WDEV_LOCK(wdev);
>
> + if (wdev->sme_state != CFG80211_SME_CONNECTED)
> + return -ENOTCONN;
> +
> + if (WARN_ON(!wdev->current_bss))
> + return -ENOTCONN;
> +
> memset(&req, 0, sizeof(req));
> req.reason_code = reason;
> req.ie = ie;
>
>
Thanks, this fixes this bug for me.
Still many problems though.
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: ath5k connection loss (failed to wakeup the MAC Chip)
From: Maxim Levitsky @ 2009-07-28 19:52 UTC (permalink / raw)
To: Adrian von Bidder; +Cc: linux-wireless
In-Reply-To: <200907280838.42541@fortytwo.ch>
On Tue, 2009-07-28 at 08:38 +0200, Adrian von Bidder wrote:
> Heyho!
>
> (This is using kernel 2.6.31-rc3 as packaged by Debian)
>
> While taking a full backup of my laptop, I noticed that after a few 100M the
> ath5k can't connect to WLAN anymore.
Yep, same here, same hardware.
I must say that moving large files typically results in prolonged
periods in which no communication is gone, maybe even something like
that.
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add networking wireless drivers section
From: Joe Perches @ 2009-07-28 18:48 UTC (permalink / raw)
To: David Miller
Cc: linville, julia, netdev, linux-kernel, kernel-janitors,
linux-wireless
In-Reply-To: <20090728.113353.08715297.davem@davemloft.net>
On Tue, 2009-07-28 at 11:33 -0700, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Tue, 28 Jul 2009 11:06:37 -0700
>
> > On Tue, 2009-07-28 at 10:30 -0700, David Miller wrote:
> >> Wireless patches need to be CC:'d to linux-wireless so that
> >> John Linville can notice and pick them up
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
>
> Why not just create a plain "WIRELESS" umbrella entry
> that contains all of drivers/net/wireless, net/mac80211,
> and net/wireless?
Whatever works for John I suppose.
John, do you have a preference?
I was trying to avoid the "S: Maintained" label
and was copying the form of this section:
NETWORKING DRIVERS
L: netdev@vger.kernel.org
W: http://www.linuxfoundation.org/en/Net
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
S: Odd Fixes
F: drivers/net/
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add networking wireless drivers section
From: David Miller @ 2009-07-28 18:34 UTC (permalink / raw)
To: joe
Cc: randy.dunlap, linville, julia, netdev, linux-kernel,
kernel-janitors, linux-wireless
In-Reply-To: <1248805627.18284.11.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Tue, 28 Jul 2009 11:27:07 -0700
> On Tue, 2009-07-28 at 11:15 -0700, Randy Dunlap wrote:
>> On Tue, 28 Jul 2009 11:06:37 -0700 Joe Perches wrote:
>> > On Tue, 2009-07-28 at 10:30 -0700, David Miller wrote:
>> > > Wireless patches need to be CC:'d to linux-wireless so that
>> > > John Linville can notice and pick them up
>> > Signed-off-by: Joe Perches <joe@perches.com>
>> > diff --git a/MAINTAINERS b/MAINTAINERS
>> > index ebc2691..0574aad 100644
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -4186,6 +4186,12 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
>> > S: Odd Fixes
>> > F: drivers/net/
>> >
>> > +NETWORKING WIRELESS DRIVERS
>> > +L: linux-wireless@vger.kernel.org
>> > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
>> > +S: Odd Fixes
>> > +F: drivers/net/wireless/
>> > +
>>
>> Already have this:
>>
>> NETWORKING [WIRELESS]
>> P: John W. Linville
>> M: linville@tuxdriver.com
>> L: linux-wireless@vger.kernel.org
>> T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
>> S: Maintained
>> F: net/wireless/
>> F: include/net/ieee80211*
>> F: include/linux/wireless.h
>
> That section does not include drivers/net/wireless/
So just add it.
> I believe John Linville isn't maintaining all the
> wireless drivers, he's acting as a gatekeeper in
> a similar role as DavidM for drivers/net/.
It still needs to hit his inbox and linux-wireless
regardless.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add networking wireless drivers section
From: David Miller @ 2009-07-28 18:33 UTC (permalink / raw)
To: joe; +Cc: linville, julia, netdev, linux-kernel, kernel-janitors,
linux-wireless
In-Reply-To: <1248804397.18284.5.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Tue, 28 Jul 2009 11:06:37 -0700
> On Tue, 2009-07-28 at 10:30 -0700, David Miller wrote:
>> Wireless patches need to be CC:'d to linux-wireless so that
>> John Linville can notice and pick them up
>
> Signed-off-by: Joe Perches <joe@perches.com>
Why not just create a plain "WIRELESS" umbrella entry
that contains all of drivers/net/wireless, net/mac80211,
and net/wireless?
^ 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