* Re: ath5k Ad Hoc Association
From: Bob Copeland @ 2010-07-19 19:22 UTC (permalink / raw)
To: Jonathan Guerin; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTilmifjH5Zopo82LhjidzsYfT_xRgKJzjGCZZPlq@mail.gmail.com>
On Mon, Jul 19, 2010 at 12:35 AM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
> Hi,
>
> I'm trying to get my wireless nodes to associate in ad hoc mode.
[...]
> I've built and installed the compat package for this kernel version:
> compat-wireless-2.6.32.16
Ok, I'm not sure which mainline kernel this corresponds to, but I
just tested ath5k adhoc with success in the latest wireless-testing
kernel. Here's what I did:
(had dnsmasq running dhcp for 192.168.10.x, network manager disabled)
$ su
# modprobe -r ath5k
# modprobe ath5k
# iw dev wlan0 set type ibss
# ifconfig wlan0 192.168.10.1 up
# iw dev wlan0 ibss join myibss 2462
Then on the other machine (Vista) I just located 'myibss' (so beacons
are working) and selected it, then successfully pinged 192.168.10.1.
It may depend on which channel you are trying to use; are you on
a channel that allows beaconing in your regulatory domain?
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* pull request: wireless-2.6 2010-07-19
From: John W. Linville @ 2010-07-19 19:17 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
In this round we have two more-or-less-one-liners intended for 2.6.25.
The hostap fix is the third (and hopefully final) bite at the apple
for correcting an initialization failure. The first two attempts
created and then reinstated a regression caused by a discrepency
between the PCI and PCMCIA support within hostap. The regression
was caused by checking the value of dev->base_addr, which the PCI
code was not setting. Testing by the regression reporter indicates
that his device is finally working again with this fix.
The rt2x00 fix merely reorders some initialization so that unwinding
that init in an error path works as expected.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 91a72a70594e5212c97705ca6a694bd307f7a26b:
net/core: neighbour update Oops (2010-07-14 18:02:16 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
John W. Linville (1):
hostap_pci: set dev->base_addr during probe
Stephen Boyd (1):
rt2x00: Fix lockdep warning in rt2x00lib_probe_dev()
drivers/net/wireless/hostap/hostap_pci.c | 1 +
drivers/net/wireless/rt2x00/rt2x00dev.c | 10 +++++-----
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_pci.c b/drivers/net/wireless/hostap/hostap_pci.c
index d24dc7d..972a9c3 100644
--- a/drivers/net/wireless/hostap/hostap_pci.c
+++ b/drivers/net/wireless/hostap/hostap_pci.c
@@ -330,6 +330,7 @@ static int prism2_pci_probe(struct pci_dev *pdev,
dev->irq = pdev->irq;
hw_priv->mem_start = mem;
+ dev->base_addr = (unsigned long) mem;
prism2_pci_cor_sreset(local);
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 3ae468c..f20d3ee 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -854,6 +854,11 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
BIT(NL80211_IFTYPE_WDS);
/*
+ * Initialize configuration work.
+ */
+ INIT_WORK(&rt2x00dev->intf_work, rt2x00lib_intf_scheduled);
+
+ /*
* Let the driver probe the device to detect the capabilities.
*/
retval = rt2x00dev->ops->lib->probe_hw(rt2x00dev);
@@ -863,11 +868,6 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
}
/*
- * Initialize configuration work.
- */
- INIT_WORK(&rt2x00dev->intf_work, rt2x00lib_intf_scheduled);
-
- /*
* Allocate queue array.
*/
retval = rt2x00queue_allocate(rt2x00dev);
--
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 related
* Re: pull request: wireless-2.6 2010-07-19
From: David Miller @ 2010-07-19 19:39 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100719191709.GA6115@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 19 Jul 2010 15:17:09 -0400
> In this round we have two more-or-less-one-liners intended for 2.6.25.
>
> The hostap fix is the third (and hopefully final) bite at the apple
> for correcting an initialization failure. The first two attempts
> created and then reinstated a regression caused by a discrepency
> between the PCI and PCMCIA support within hostap. The regression
> was caused by checking the value of dev->base_addr, which the PCI
> code was not setting. Testing by the regression reporter indicates
> that his device is finally working again with this fix.
>
> The rt2x00 fix merely reorders some initialization so that unwinding
> that init in an error path works as expected.
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH] cfg80211: fix WEXT ioctl GIWFREQ for monitor interfaces
From: Gábor Stefanik @ 2010-07-19 20:12 UTC (permalink / raw)
To: David Gnedt; +Cc: John W. Linville, linux-wireless, Johannes Berg
In-Reply-To: <4C449C67.6010004@davizone.at>
On Mon, Jul 19, 2010 at 8:41 PM, David Gnedt <david.gnedt@davizone.at> wrote:
> The cfg80211_set_freq function now also saves the channel for monitor
> interfaces.
> This fixes a issue were the WEXT ioctl GIWFREQ doesn't report the correct
> channel when the channel was switched in monitor mode.
>
> Signed-off-by: David Gnedt <david.gnedt@davizone.at>
> ---
> net/wireless/chan.c | 7 +++----
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index d0c92dd..fd05938 100644
> --- a/net/wireless/chan.c
> +++ b/net/wireless/chan.c
> @@ -51,9 +51,6 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
> struct ieee80211_channel *chan;
> int result;
>
> - if (wdev && wdev->iftype == NL80211_IFTYPE_MONITOR)
> - wdev = NULL;
> -
> if (wdev) {
> ASSERT_WDEV_LOCK(wdev);
>
> @@ -69,7 +66,9 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
> return -EINVAL;
>
> result = rdev->ops->set_channel(&rdev->wiphy,
> - wdev ? wdev->netdev : NULL,
> + wdev && wdev->iftype !=
> + NL80211_IFTYPE_MONITOR ?
> + wdev->netdev : NULL,
Just out of curiosity: why is it important to pass NULL as netdev for
monitor interfaces?
> chan, channel_type);
> if (result)
> return result;
> --
> 1.6.3.3
>
> --
> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] mac80211: set carrier on for monitor interfaces on ieee80211_open
From: Johannes Berg @ 2010-07-19 20:26 UTC (permalink / raw)
To: David Gnedt; +Cc: John W. Linville, linux-wireless
In-Reply-To: <4C449CF2.7090800@davizone.at>
On Mon, 2010-07-19 at 20:44 +0200, David Gnedt wrote:
> If a station interface is reused as monitor interface it is possible that
> the carrier is still set to off. This breaks packet injection on that
> monitor interface.
> Force the carrier on in monitor interface initialisation like it is also done
> for other interface types (e.g. adhoc, mesh point, ap).
>
> Signed-off-by: David Gnedt <david.gnedt@davizone.at>
This looks good,
Acked-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> net/mac80211/iface.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
> index 910729f..d07d223 100644
> --- a/net/mac80211/iface.c
> +++ b/net/mac80211/iface.c
> @@ -249,6 +249,8 @@ static int ieee80211_open(struct net_device *dev)
> local->fif_other_bss++;
>
> ieee80211_configure_filter(local);
> +
> + netif_carrier_on(dev);
> break;
> default:
> res = drv_add_interface(local, &sdata->vif);
^ permalink raw reply
* Re: [PATCH] cfg80211: fix WEXT ioctl GIWFREQ for monitor interfaces
From: Johannes Berg @ 2010-07-19 20:27 UTC (permalink / raw)
To: David Gnedt; +Cc: John W. Linville, linux-wireless
In-Reply-To: <4C449C67.6010004@davizone.at>
On Mon, 2010-07-19 at 20:41 +0200, David Gnedt wrote:
> The cfg80211_set_freq function now also saves the channel for monitor
> interfaces.
> This fixes a issue were the WEXT ioctl GIWFREQ doesn't report the correct
> channel when the channel was switched in monitor mode.
This is still wrong, as discussed previously on this list.
johannes
^ permalink raw reply
* Re: RTL8180L is hitting WARN_ON in net/wireless/scan.c:575
From: John W. Linville @ 2010-07-19 20:48 UTC (permalink / raw)
To: Pauli Nieminen; +Cc: linux-wireless
In-Reply-To: <AANLkTiknLRzt2bdhcin5WRzwPXSWqEs8dIUe5imlN0I9@mail.gmail.com>
On Sat, Jul 17, 2010 at 10:30:49AM +0300, Pauli Nieminen wrote:
> Hi,
>
> I'm testing 2.6.35-rc4+, I have problem that warning is spamming dmesg
> when I have my wifi on. Actual problem caused y that problem is that I
> can't scan/connect to any network with 2.6.35.
>
> When I looked the code in warning it might be related to problem that
> my wifi reports all signal strength to be 175 or 178 (if I remember
> correctly). I'm now using 2.6.35 so I can't check the reported values
> from scan results.
I just sent "rtl8180: improve signal reporting for rtl8185 hardware"
as a reply to this email. Can you try that patch?
Thanks!
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
* [PATCH] rtl8180: improve signal reporting for rtl8185 hardware
From: John W. Linville @ 2010-07-19 20:47 UTC (permalink / raw)
To: linux-wireless; +Cc: Pauli Nieminen, John W. Linville
In-Reply-To: <AANLkTiknLRzt2bdhcin5WRzwPXSWqEs8dIUe5imlN0I9@mail.gmail.com>
The existing code seemed to be somewhat based on the datasheet, but
varied substantially from the vendor-provided driver. This mirrors the
handling of the rtl8185 case from that driver, but still neglects the
specifics for the rtl8180 hardware. Those details are a bit muddled...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rtl818x/rtl8180_dev.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8180_dev.c b/drivers/net/wireless/rtl818x/rtl8180_dev.c
index 4270502..90046dc 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
@@ -103,6 +103,7 @@ static void rtl8180_handle_rx(struct ieee80211_hw *dev)
{
struct rtl8180_priv *priv = dev->priv;
unsigned int count = 32;
+ u8 signal;
while (count--) {
struct rtl8180_rx_desc *entry = &priv->rx_ring[priv->rx_idx];
@@ -130,10 +131,14 @@ static void rtl8180_handle_rx(struct ieee80211_hw *dev)
skb_put(skb, flags & 0xFFF);
rx_status.antenna = (flags2 >> 15) & 1;
- /* TODO: improve signal/rssi reporting */
- rx_status.signal = (flags2 >> 8) & 0x7F;
- /* XXX: is this correct? */
rx_status.rate_idx = (flags >> 20) & 0xF;
+ /* TODO: improve signal/rssi reporting for !rtl8185 */
+ signal = (flags2 >> 17) & 0x7F;
+ if (rx_status.rate_idx > 3)
+ signal = clamp_t(u8, signal, 25, 90);
+ else
+ signal = clamp_t(u8, signal, 30, 95);
+ rx_status.signal = signal;
rx_status.freq = dev->conf.channel->center_freq;
rx_status.band = dev->conf.channel->band;
rx_status.mactime = le64_to_cpu(entry->tsft);
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] cfg80211: fix WEXT ioctl GIWFREQ for monitor interfaces
From: Gábor Stefanik @ 2010-07-19 21:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: David Gnedt, John W. Linville, linux-wireless
In-Reply-To: <1279571235.30478.5.camel@jlt3.sipsolutions.net>
On Mon, Jul 19, 2010 at 10:27 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2010-07-19 at 20:41 +0200, David Gnedt wrote:
>> The cfg80211_set_freq function now also saves the channel for monitor
>> interfaces.
>> This fixes a issue were the WEXT ioctl GIWFREQ doesn't report the correct
>> channel when the channel was switched in monitor mode.
>
> This is still wrong, as discussed previously on this list.
>
> johannes
>
And the conclusion was... ?
(BTW, I say that a GIWFREQ on a monitor interface should always return
the channel the PHY is tuned to at the moment when it is issued. Most
tools seem to expect this behavior.)
^ permalink raw reply
* Re: [PATCH] compat: fix build if CONFIG_PCCARD=y and CONFIG_PCMCIA=n
From: Luis R. Rodriguez @ 2010-07-19 21:41 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof
In-Reply-To: <1279480162-20673-1-git-send-email-hauke@hauke-m.de>
On Sun, Jul 18, 2010 at 12:09 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> The includes are needed for pccard_loop_tuple.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Thanks! Applied and pushed out.
Luis
^ permalink raw reply
* iwlagn and many firmware restarts with Fedora kernel
From: Marcel Holtmann @ 2010-07-19 18:43 UTC (permalink / raw)
To: linux-wireless
Hi,
so during the last few weeks, I have seen a huge amount of firmware
restarts with my Intel 5350 card and Fedora 13 kernel (2.6.33.6-147).
iwlagn 0000:03:00.0: low ack count detected, restart firmware
iwlagn 0000:03:00.0: On demand firmware reload
iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting
iwlagn 0000:03:00.0: queue number out of range: 0, must be 10 to 19
If this happens then I don't see it once, I normally see this 10-20
times and the connectivity is stalled until the cards comes back to
life. I have seen patches that should have fixed this symptom, but they
might be also send to -stable since this is a major hassle.
The time without connectivity is something around 4-5 minutes or longer
when this happens. Not really funny.
Regards
Marcel
^ permalink raw reply
* RE: iwlagn and many firmware restarts with Fedora kernel
From: Guy, Wey-Yi W @ 2010-07-19 22:23 UTC (permalink / raw)
To: Marcel Holtmann, linux-wireless@vger.kernel.org
In-Reply-To: <1279565034.4572.36.camel@localhost.localdomain>
SGkgTWFyY2VsLA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbGludXgtd2ly
ZWxlc3Mtb3duZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtd2lyZWxlc3Mtb3duZXJA
dmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgTWFyY2VsIEhvbHRtYW5uDQpTZW50OiBNb25k
YXksIEp1bHkgMTksIDIwMTAgMTE6NDQgQU0NClRvOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5l
bC5vcmcNClN1YmplY3Q6IGl3bGFnbiBhbmQgbWFueSBmaXJtd2FyZSByZXN0YXJ0cyB3aXRoIEZl
ZG9yYSBrZXJuZWwNCg0KSGksDQoNCnNvIGR1cmluZyB0aGUgbGFzdCBmZXcgd2Vla3MsIEkgaGF2
ZSBzZWVuIGEgaHVnZSBhbW91bnQgb2YgZmlybXdhcmUNCnJlc3RhcnRzIHdpdGggbXkgSW50ZWwg
NTM1MCBjYXJkIGFuZCBGZWRvcmEgMTMga2VybmVsICgyLjYuMzMuNi0xNDcpLg0KDQppd2xhZ24g
MDAwMDowMzowMC4wOiBsb3cgYWNrIGNvdW50IGRldGVjdGVkLCByZXN0YXJ0IGZpcm13YXJlDQpp
d2xhZ24gMDAwMDowMzowMC4wOiBPbiBkZW1hbmQgZmlybXdhcmUgcmVsb2FkDQppd2xhZ24gMDAw
MDowMzowMC4wOiBTdG9wcGluZyBBR0cgd2hpbGUgc3RhdGUgbm90IE9OIG9yIHN0YXJ0aW5nDQpp
d2xhZ24gMDAwMDowMzowMC4wOiBxdWV1ZSBudW1iZXIgb3V0IG9mIHJhbmdlOiAwLCBtdXN0IGJl
IDEwIHRvIDE5DQoNCklmIHRoaXMgaGFwcGVucyB0aGVuIEkgZG9uJ3Qgc2VlIGl0IG9uY2UsIEkg
bm9ybWFsbHkgc2VlIHRoaXMgMTAtMjANCnRpbWVzIGFuZCB0aGUgY29ubmVjdGl2aXR5IGlzIHN0
YWxsZWQgdW50aWwgdGhlIGNhcmRzIGNvbWVzIGJhY2sgdG8NCmxpZmUuIEkgaGF2ZSBzZWVuIHBh
dGNoZXMgdGhhdCBzaG91bGQgaGF2ZSBmaXhlZCB0aGlzIHN5bXB0b20sIGJ1dCB0aGV5DQptaWdo
dCBiZSBhbHNvIHNlbmQgdG8gLXN0YWJsZSBzaW5jZSB0aGlzIGlzIGEgbWFqb3IgaGFzc2xlLg0K
DQpUaGUgdGltZSB3aXRob3V0IGNvbm5lY3Rpdml0eSBpcyBzb21ldGhpbmcgYXJvdW5kIDQtNSBt
aW51dGVzIG9yIGxvbmdlcg0Kd2hlbiB0aGlzIGhhcHBlbnMuIE5vdCByZWFsbHkgZnVubnkuDQoN
CldoaWNoIHBhdGNoIHlvdSByZWZlcnJpbmcgdG8/IEkgd2lsbCB0cnkgdG8gd29yayBvbiBzdWJt
aXQgaXQgdG8gc3RhYmxlLg0KDQpUaGFua3MNCldleQ0K
^ permalink raw reply
* Re: iwlagn and many firmware restarts with Fedora kernel
From: drago01 @ 2010-07-19 22:33 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-wireless
In-Reply-To: <1279565034.4572.36.camel@localhost.localdomain>
On Mon, Jul 19, 2010 at 8:43 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi,
>
> so during the last few weeks, I have seen a huge amount of firmware
> restarts with my Intel 5350 card and Fedora 13 kernel (2.6.33.6-147).
>
> iwlagn 0000:03:00.0: low ack count detected, restart firmware
> iwlagn 0000:03:00.0: On demand firmware reload
> iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting
> iwlagn 0000:03:00.0: queue number out of range: 0, must be 10 to 19
>
> If this happens then I don't see it once, I normally see this 10-20
> times and the connectivity is stalled until the cards comes back to
> life. I have seen patches that should have fixed this symptom, but they
> might be also send to -stable since this is a major hassle.
>
> The time without connectivity is something around 4-5 minutes or longer
> when this happens. Not really funny.
This happens here too even with the 2.6.34.1-9.fc13.x86_64 kernel;
when this happens reloading the iwlagn module seems to be the only
(quick) way to get it back to life.
^ permalink raw reply
* RE: iwlagn and many firmware restarts with Fedora kernel
From: Marcel Holtmann @ 2010-07-19 23:28 UTC (permalink / raw)
To: Guy, Wey-Yi W; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <E9954878DD1FB34FAE5187FB88C58A350120692494@orsmsx506.amr.corp.intel.com>
Hi Wey,
> so during the last few weeks, I have seen a huge amount of firmware
> restarts with my Intel 5350 card and Fedora 13 kernel (2.6.33.6-147).
>
> iwlagn 0000:03:00.0: low ack count detected, restart firmware
> iwlagn 0000:03:00.0: On demand firmware reload
> iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting
> iwlagn 0000:03:00.0: queue number out of range: 0, must be 10 to 19
>
> If this happens then I don't see it once, I normally see this 10-20
> times and the connectivity is stalled until the cards comes back to
> life. I have seen patches that should have fixed this symptom, but they
> might be also send to -stable since this is a major hassle.
>
> The time without connectivity is something around 4-5 minutes or longer
> when this happens. Not really funny.
>
> Which patch you referring to? I will try to work on submit it to stable.
no patch in particular, I just have seen some commit messages that would
be indicating this got fixed.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] cfg80211: fix WEXT ioctl GIWFREQ for monitor interfaces
From: David Gnedt @ 2010-07-19 23:28 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: linux-wireless, John W. Linville, Johannes Berg
In-Reply-To: <AANLkTimxBt7dPcZrmAihWq9UKs77qS0cnAxQXIY_55ci@mail.gmail.com>
Am 2010-07-19 23:06, schrieb Gábor Stefanik:
> (BTW, I say that a GIWFREQ on a monitor interface should always return
> the channel the PHY is tuned to at the moment when it is issued. Most
> tools seem to expect this behavior.)
I agree, that would be the expected behaviour.
I am not very familar with the entire wireless subsystem yet, but wouldn't that
imply a interface change in cfg80211 and mac80211 to add an "get_channel" function?
Because if the card is hopping channels (e.g. because of 2 station interfaces on
different channels), only the driver itself can tell what's really the current
channel.
Nevertheless a default implementation for this new "get_channel" can be written
at mac80211 level (or even cfg80211?), which tries to find the current channel
by looking at all virtual interfaces, so only mac80211 drivers which allow
multiple channels (and non-mac80211 drivers) need to implement it.
Regards,
David
^ permalink raw reply
* Re: iwlagn and many firmware restarts with Fedora kernel
From: Marcel Holtmann @ 2010-07-19 23:29 UTC (permalink / raw)
To: drago01; +Cc: linux-wireless
In-Reply-To: <AANLkTinGUQjPoMRmt_jeFgpxLhzma7qhfR14t_tWLvO1@mail.gmail.com>
Hi,
> > so during the last few weeks, I have seen a huge amount of firmware
> > restarts with my Intel 5350 card and Fedora 13 kernel (2.6.33.6-147).
> >
> > iwlagn 0000:03:00.0: low ack count detected, restart firmware
> > iwlagn 0000:03:00.0: On demand firmware reload
> > iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting
> > iwlagn 0000:03:00.0: queue number out of range: 0, must be 10 to 19
> >
> > If this happens then I don't see it once, I normally see this 10-20
> > times and the connectivity is stalled until the cards comes back to
> > life. I have seen patches that should have fixed this symptom, but they
> > might be also send to -stable since this is a major hassle.
> >
> > The time without connectivity is something around 4-5 minutes or longer
> > when this happens. Not really funny.
>
> This happens here too even with the 2.6.34.1-9.fc13.x86_64 kernel;
> when this happens reloading the iwlagn module seems to be the only
> (quick) way to get it back to life.
the quick way is re-loading the module, that is true. Otherwise you have
to sit it out. It always comes back nicely and starts working again.
Regards
Marcel
^ permalink raw reply
* Re: iwlagn and many firmware restarts with Fedora kernel
From: Guy, Wey-Yi @ 2010-07-19 23:56 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: drago01, linux-wireless@vger.kernel.org
In-Reply-To: <1279582174.4572.43.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
Hi drago,
On Mon, 2010-07-19 at 16:29 -0700, Marcel Holtmann wrote:
> Hi,
>
> > > so during the last few weeks, I have seen a huge amount of firmware
> > > restarts with my Intel 5350 card and Fedora 13 kernel (2.6.33.6-147).
> > >
> > > iwlagn 0000:03:00.0: low ack count detected, restart firmware
> > > iwlagn 0000:03:00.0: On demand firmware reload
> > > iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting
> > > iwlagn 0000:03:00.0: queue number out of range: 0, must be 10 to 19
> > >
> > > If this happens then I don't see it once, I normally see this 10-20
> > > times and the connectivity is stalled until the cards comes back to
> > > life. I have seen patches that should have fixed this symptom, but they
> > > might be also send to -stable since this is a major hassle.
> > >
> > > The time without connectivity is something around 4-5 minutes or longer
> > > when this happens. Not really funny.
> >
> > This happens here too even with the 2.6.34.1-9.fc13.x86_64 kernel;
> > when this happens reloading the iwlagn module seems to be the only
> > (quick) way to get it back to life.
>
> the quick way is re-loading the module, that is true. Otherwise you have
> to sit it out. It always comes back nicely and starts working again.
>
Are you using 5350? here I attach a "RFC patch", could you give a try to
see if it help?
Regards
Wey
[-- Attachment #2: 0001-iwlwifi-extend-the-stuck-queue-monitor-timer-for-53.patch --]
[-- Type: text/x-patch, Size: 1715 bytes --]
>From d399851898df57fc03d513c2a336d3f3745b0d10 Mon Sep 17 00:00:00 2001
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Mon, 19 Jul 2010 16:38:19 -0700
Subject: [PATCH 1/1] iwlwifi: extend the stuck queue monitor timer for 5350 device
Different hardware has differnet behavior, extend the monitor period
timer from 1 second to 5 seconds to avoid the un-necessary firmware reload
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-5000.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index 68e282b..4325a53 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -642,7 +642,7 @@ struct iwl_cfg iwl5350_agn_cfg = {
.chain_noise_num_beacons = IWL_CAL_NUM_BEACONS,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_LONG_THRESHOLD_DEF,
.chain_noise_scale = 1000,
- .monitor_recover_period = IWL_MONITORING_PERIOD,
+ .monitor_recover_period = IWL_LONG_MONITORING_PERIOD,
.max_event_log_size = 512,
.ucode_tracing = true,
.sensitivity_calib_by_driver = true,
diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
index 30853c8..d439b80 100644
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -1051,6 +1051,7 @@ struct iwl_event_log {
/* timer constants use to monitor and recover stuck tx queues in mSecs */
#define IWL_MONITORING_PERIOD (1000)
+#define IWL_LONG_MONITORING_PERIOD (5000)
#define IWL_ONE_HUNDRED_MSECS (100)
#define IWL_SIXTY_SECS (60000)
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH/RFC 1/3] ath5k: log descriptor chains at a new debug level
From: Bruno Randolf @ 2010-07-20 5:01 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <1279395336-856-2-git-send-email-me@bobcopeland.com>
On Sun July 18 2010 04:35:34 Bob Copeland wrote:
> Descriptors are currently logged with ATH5K_DEBUG_RESET,
> which isn't really apt, and also means we can't see just
> the descriptor setup or just the resets. Add a new
> debug level just for that.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/debug.c | 5 +++--
> drivers/net/wireless/ath/ath5k/debug.h | 2 ++
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/debug.c
> b/drivers/net/wireless/ath/ath5k/debug.c index ebb9c23..2222022 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.c
> +++ b/drivers/net/wireless/ath/ath5k/debug.c
> @@ -309,6 +309,7 @@ static const struct {
> { ATH5K_DEBUG_DUMP_TX, "dumptx", "print transmit skb content" },
> { ATH5K_DEBUG_DUMPBANDS, "dumpbands", "dump bands" },
> { ATH5K_DEBUG_ANI, "ani", "adaptive noise immunity" },
> + { ATH5K_DEBUG_DESC, "desc", "descriptor chains" },
> { ATH5K_DEBUG_ANY, "all", "show all debug levels" },
> };
>
> @@ -937,7 +938,7 @@ ath5k_debug_printrxbuffs(struct ath5k_softc *sc, struct
> ath5k_hw *ah) struct ath5k_rx_status rs = {};
> int status;
>
> - if (likely(!(sc->debug.level & ATH5K_DEBUG_RESET)))
> + if (likely(!(sc->debug.level & ATH5K_DEBUG_DESC)))
> return;
>
> printk(KERN_DEBUG "rxdp %x, rxlink %p\n",
> @@ -979,7 +980,7 @@ ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct
> ath5k_buf *bf) struct ath5k_tx_status ts = {};
> int done;
>
> - if (likely(!(sc->debug.level & ATH5K_DEBUG_RESET)))
> + if (likely(!(sc->debug.level & ATH5K_DEBUG_DESC)))
> return;
>
> done = sc->ah->ah_proc_tx_desc(sc->ah, bf->desc, &ts);
> diff --git a/drivers/net/wireless/ath/ath5k/debug.h
> b/drivers/net/wireless/ath/ath5k/debug.h index 606ae94..9b22722 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.h
> +++ b/drivers/net/wireless/ath/ath5k/debug.h
> @@ -95,6 +95,7 @@ struct ath5k_dbg_info {
> * @ATH5K_DEBUG_DUMP_TX: print transmit skb content
> * @ATH5K_DEBUG_DUMPBANDS: dump bands
> * @ATH5K_DEBUG_TRACE: trace function calls
> + * @ATH5K_DEBUG_DESC: descriptor setup
> * @ATH5K_DEBUG_ANY: show at any debug level
> *
> * The debug level is used to control the amount and type of debugging
> output @@ -117,6 +118,7 @@ enum ath5k_debug_level {
> ATH5K_DEBUG_DUMP_TX = 0x00000200,
> ATH5K_DEBUG_DUMPBANDS = 0x00000400,
> ATH5K_DEBUG_ANI = 0x00002000,
> + ATH5K_DEBUG_DESC = 0x00004000,
> ATH5K_DEBUG_ANY = 0xffffffff
> };
Acked-by: Bruno Randolf <br1@einfach.org>
^ permalink raw reply
* Re: [ath5k-devel] [PATCH/RFC 0/3] ath5k: add driver tracepoints
From: Bruno Randolf @ 2010-07-20 5:11 UTC (permalink / raw)
To: ath5k-devel; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <1279395336-856-1-git-send-email-me@bobcopeland.com>
On Sun July 18 2010 04:35:33 Bob Copeland wrote:
> This series adds some tracepoints for reset and tx/rx, with an
> eye toward replacing some of the debug printks we have today.
> Stolen form iwlwifi is the idea of logging entire packets so
> we can generate pcap files from the traces, via something like:
>
> $ mkdir -p ~/.trace-cmd/plugins
> $ cd ~/.trace-cmd/plugins
> $ wget 'http://bobcopeland.com/srcs/ath5k_trace.py'
> $ trace-cmd record -e mac80211 -e ath5k sleep 500
> $ trace-cmd report | less
> $ wireshark /tmp/pcap.out
>
> I quite like the result, but I'd be interested to hear others'
> opinions on the approach. Right now I think these tracepoints
> will be useful in seeing causes of excessive resets, and debugging
> queue hangs.
hmm, this is really nice stuff, but i'm not sure what to do on embedded boards
where we don't have python or where it's not possible to use tracing in
general due to (low) performance reasons. in these cases the kernel printks
are just so much more easy to use... i would actually prefer to keep them...
additionally to the new tracing you made, maybe? otoh we could probably get
tracing enabled on all boards if we really need it, it's just some extra
work...
bruno
^ permalink raw reply
* Re: [PATCH/RFC 3/3] ath5k: trace resets
From: Bruno Randolf @ 2010-07-20 5:20 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <1279395336-856-4-git-send-email-me@bobcopeland.com>
On Sun July 18 2010 04:35:36 Bob Copeland wrote:
> This change adds a tracepoint for ath5k_reset. We record the
> reason for each reset and the new channel frequency.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/ath5k_trace.h | 38 +++++++++++++++++
> drivers/net/wireless/ath/ath5k/base.c | 56
> +++++++------------------- drivers/net/wireless/ath/ath5k/base.h |
> 12 ++++++
> drivers/net/wireless/ath/ath5k/debug.c | 7 ++-
> drivers/net/wireless/ath/ath5k/debug.h | 2 -
> 5 files changed, 70 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/ath5k_trace.h
> b/drivers/net/wireless/ath/ath5k/ath5k_trace.h index 00d9773..3a5112d
> 100644
> --- a/drivers/net/wireless/ath/ath5k/ath5k_trace.h
> +++ b/drivers/net/wireless/ath/ath5k/ath5k_trace.h
> @@ -12,6 +12,44 @@ struct sk_buff;
> #undef TRACE_SYSTEM
> #define TRACE_SYSTEM ath5k
>
> +TRACE_EVENT(ath5k_reset,
> + TP_PROTO(struct ath5k_softc *priv, struct ieee80211_channel *chan,
> + enum ath5k_reset_reason reason),
> +
> + TP_ARGS(priv, chan, reason),
> + TP_STRUCT__entry(
> + PRIV_ENTRY
> + __field(u32, reason)
> + __field(u16, freq)
> + ),
> + TP_fast_assign(
> + PRIV_ASSIGN;
> + __entry->reason = reason;
> + __entry->freq = chan->center_freq;
> + ),
> + TP_printk(
> + "[%p] reset reason=%d freq=%u", __entry->priv,
> + __entry->reason, __entry->freq
> + )
> +);
> +
> +TRACE_EVENT(ath5k_reset_end,
> + TP_PROTO(struct ath5k_softc *priv, int result),
> +
> + TP_ARGS(priv, result),
> + TP_STRUCT__entry(
> + PRIV_ENTRY
> + __field(s32, result)
> + ),
> + TP_fast_assign(
> + PRIV_ASSIGN;
> + __entry->result = (s32) result;
> + ),
> + TP_printk(
> + "[%p] reset ret=%d", __entry->priv, __entry->result
> + )
> +);
> +
> TRACE_EVENT(ath5k_rx,
> TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb),
> TP_ARGS(priv, skb),
> diff --git a/drivers/net/wireless/ath/ath5k/base.c
> b/drivers/net/wireless/ath/ath5k/base.c index 23a5679..44732b5 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -224,7 +224,8 @@ static struct pci_driver ath5k_pci_driver = {
> static int ath5k_tx(struct ieee80211_hw *hw, struct sk_buff *skb);
> static int ath5k_tx_queue(struct ieee80211_hw *hw, struct sk_buff *skb,
> struct ath5k_txq *txq);
> -static int ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel
> *chan); +static int ath5k_reset(struct ath5k_softc *sc, struct
> ieee80211_channel *chan, + enum ath5k_reset_reason
> ath5k_reset_reason);
> static int ath5k_start(struct ieee80211_hw *hw);
> static void ath5k_stop(struct ieee80211_hw *hw);
> static int ath5k_add_interface(struct ieee80211_hw *hw,
> @@ -1120,17 +1121,13 @@ ath5k_setup_bands(struct ieee80211_hw *hw)
> static int
> ath5k_chan_set(struct ath5k_softc *sc, struct ieee80211_channel *chan)
> {
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> - "channel set, resetting (%u -> %u MHz)\n",
> - sc->curchan->center_freq, chan->center_freq);
> -
> /*
> * To switch channels clear any pending DMA operations;
> * wait long enough for the RX fifo to drain, reset the
> * hardware at the new frequency, and then re-enable
> * the relevant bits of the h/w.
> */
> - return ath5k_reset(sc, chan);
> + return ath5k_reset(sc, chan, RESET_SET_CHANNEL);
> }
>
> static void
> @@ -1615,8 +1612,6 @@ ath5k_txq_drainq(struct ath5k_softc *sc, struct
> ath5k_txq *txq) */
> spin_lock_bh(&txq->lock);
> list_for_each_entry_safe(bf, bf0, &txq->q, list) {
> - ath5k_debug_printtxbuf(sc, bf);
> -
> ath5k_txbuf_free_skb(sc, bf);
>
> spin_lock_bh(&sc->txbuflock);
> @@ -1641,18 +1636,9 @@ ath5k_txq_cleanup(struct ath5k_softc *sc)
> if (likely(!test_bit(ATH_STAT_INVALID, sc->status))) {
> /* don't touch the hardware if marked invalid */
> ath5k_hw_stop_tx_dma(ah, sc->bhalq);
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "beacon queue %x\n",
> - ath5k_hw_get_txdp(ah, sc->bhalq));
> for (i = 0; i < ARRAY_SIZE(sc->txqs); i++)
> - if (sc->txqs[i].setup) {
> + if (sc->txqs[i].setup)
> ath5k_hw_stop_tx_dma(ah, sc->txqs[i].qnum);
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "txq [%u] %x, "
> - "link %p\n",
> - sc->txqs[i].qnum,
> - ath5k_hw_get_txdp(ah,
> - sc->txqs[i].qnum),
> - sc->txqs[i].link);
> - }
> }
>
> for (i = 0; i < ARRAY_SIZE(sc->txqs); i++)
> @@ -1693,9 +1679,6 @@ ath5k_rx_start(struct ath5k_softc *sc)
>
> common->rx_bufsize = roundup(IEEE80211_MAX_LEN, common->cachelsz);
>
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "cachelsz %u rx_bufsize %u\n",
> - common->cachelsz, common->rx_bufsize);
> -
> spin_lock_bh(&sc->rxbuflock);
> sc->rxlink = NULL;
> list_for_each_entry(bf, &sc->rxbuf, list) {
> @@ -2329,8 +2312,7 @@ ath5k_beacon_send(struct ath5k_softc *sc)
> ATH5K_DBG(sc, ATH5K_DEBUG_BEACON,
> "stuck beacon time (%u missed)\n",
> sc->bmisscount);
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> - "stuck beacon, resetting\n");
> + sc->reset_reason = RESET_STUCK_BEACON;
> ieee80211_queue_work(sc->hw, &sc->reset_work);
> }
> return;
> @@ -2561,8 +2543,6 @@ ath5k_init(struct ath5k_softc *sc)
>
> mutex_lock(&sc->lock);
>
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "mode %d\n", sc->opmode);
> -
> /*
> * Stop anything previously setup. This is safe
> * no matter this is the first time through or not.
> @@ -2582,7 +2562,7 @@ ath5k_init(struct ath5k_softc *sc)
> AR5K_INT_RXORN | AR5K_INT_TXDESC | AR5K_INT_TXEOL |
> AR5K_INT_FATAL | AR5K_INT_GLOBAL | AR5K_INT_MIB;
>
> - ret = ath5k_reset(sc, NULL);
> + ret = ath5k_reset(sc, NULL, RESET_INIT);
> if (ret)
> goto done;
>
> @@ -2608,9 +2588,6 @@ ath5k_stop_locked(struct ath5k_softc *sc)
> {
> struct ath5k_hw *ah = sc->ah;
>
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "invalid %u\n",
> - test_bit(ATH_STAT_INVALID, sc->status));
> -
> /*
> * Shutdown the hardware and driver:
> * stop output from above
> @@ -2686,9 +2663,6 @@ ath5k_stop_hw(struct ath5k_softc *sc)
> * on the device (same as initial state after attach) and
> * leave it idle (keep MAC/BB on warm reset) */
> ret = ath5k_hw_on_hold(sc->ah);
> -
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> - "putting device to sleep\n");
> }
> ath5k_txbuf_free_skb(sc, sc->bbuf);
>
> @@ -2743,8 +2717,7 @@ ath5k_intr(int irq, void *dev_id)
> * Fatal errors are unrecoverable.
> * Typically these are caused by DMA errors.
> */
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> - "fatal int, resetting\n");
> + sc->reset_reason = RESET_FATAL;
> ieee80211_queue_work(sc->hw, &sc->reset_work);
> } else if (unlikely(status & AR5K_INT_RXORN)) {
> /*
> @@ -2758,8 +2731,7 @@ ath5k_intr(int irq, void *dev_id)
> */
> sc->stats.rxorn_intr++;
> if (ah->ah_mac_srev < AR5K_SREV_AR5212) {
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> - "rx overrun, resetting\n");
> + sc->reset_reason = RESET_RXORN;
> ieee80211_queue_work(sc->hw, &sc->reset_work);
> }
> else
> @@ -2829,7 +2801,7 @@ ath5k_tasklet_calibrate(unsigned long data)
> * Rfgain is out of bounds, reset the chip
> * to load new gain values.
> */
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "calibration, resetting\n");
> + sc->reset_reason = RESET_CALIBRATION;
> ieee80211_queue_work(sc->hw, &sc->reset_work);
> }
> if (ath5k_hw_phy_calibrate(ah, sc->curchan))
> @@ -2938,12 +2910,13 @@ drop_packet:
> * This should be called with sc->lock.
> */
> static int
> -ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
> +ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan,
> + enum ath5k_reset_reason reason)
> {
> struct ath5k_hw *ah = sc->ah;
> int ret;
>
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "resetting\n");
> + trace_ath5k_reset(sc, chan, reason);
>
> ath5k_hw_set_imr(ah, 0);
> synchronize_irq(sc->pdev->irq);
> @@ -2990,8 +2963,9 @@ ath5k_reset(struct ath5k_softc *sc, struct
> ieee80211_channel *chan)
>
> ieee80211_wake_queues(sc->hw);
>
> - return 0;
> + ret = 0;
> err:
> + trace_ath5k_reset_end(sc, ret);
> return ret;
> }
>
> @@ -3001,7 +2975,7 @@ static void ath5k_reset_work(struct work_struct
> *work) reset_work);
>
> mutex_lock(&sc->lock);
> - ath5k_reset(sc, sc->curchan);
> + ath5k_reset(sc, sc->curchan, sc->reset_reason);
> mutex_unlock(&sc->lock);
> }
>
> diff --git a/drivers/net/wireless/ath/ath5k/base.h
> b/drivers/net/wireless/ath/ath5k/base.h index dc1241f..cb6e2be 100644
> --- a/drivers/net/wireless/ath/ath5k/base.h
> +++ b/drivers/net/wireless/ath/ath5k/base.h
> @@ -140,6 +140,17 @@ struct ath5k_statistics {
> unsigned int rxeol_intr;
> };
>
> +/* Reset tracing */
> +enum ath5k_reset_reason {
> + RESET_INIT,
> + RESET_SET_CHANNEL,
> + RESET_STUCK_BEACON,
> + RESET_FATAL,
> + RESET_RXORN,
> + RESET_CALIBRATION,
> + RESET_DEBUGFS,
> +};
> +
> #if CHAN_DEBUG
> #define ATH_CHAN_MAX (26+26+26+200+200)
> #else
> @@ -192,6 +203,7 @@ struct ath5k_softc {
> led_on; /* pin setting for LED on */
>
> struct work_struct reset_work; /* deferred chip reset */
> + enum ath5k_reset_reason reset_reason; /* reason for resetting */
>
> unsigned int rxbufsize; /* rx size based on mtu */
> struct list_head rxbuf; /* receive buffer */
> diff --git a/drivers/net/wireless/ath/ath5k/debug.c
> b/drivers/net/wireless/ath/ath5k/debug.c index d107cd6..9ddbfd5 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.c
> +++ b/drivers/net/wireless/ath/ath5k/debug.c
> @@ -278,7 +278,7 @@ static ssize_t write_file_reset(struct file *file,
> size_t count, loff_t *ppos)
> {
> struct ath5k_softc *sc = file->private_data;
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "debug file triggered reset\n");
> + sc->reset_reason = RESET_DEBUGFS;
> ieee80211_queue_work(sc->hw, &sc->reset_work);
> return count;
> }
> @@ -297,7 +297,6 @@ static const struct {
> const char *name;
> const char *desc;
> } dbg_info[] = {
> - { ATH5K_DEBUG_RESET, "reset", "reset and initialization" },
> { ATH5K_DEBUG_INTR, "intr", "interrupt handling" },
> { ATH5K_DEBUG_MODE, "mode", "mode init/setup" },
> { ATH5K_DEBUG_XMIT, "xmit", "basic xmit operation" },
> @@ -931,6 +930,7 @@ ath5k_debug_printrxbuf(struct ath5k_buf *bf, int done,
> void
> ath5k_debug_printrxbuffs(struct ath5k_softc *sc, struct ath5k_hw *ah)
> {
> +#if 0
> struct ath5k_desc *ds;
> struct ath5k_buf *bf;
> struct ath5k_rx_status rs = {};
> @@ -950,11 +950,13 @@ ath5k_debug_printrxbuffs(struct ath5k_softc *sc,
> struct ath5k_hw *ah) ath5k_debug_printrxbuf(bf, status == 0, &rs);
> }
> spin_unlock_bh(&sc->rxbuflock);
> +#endif
> }
>
> void
> ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf)
> {
> +#if 0
> struct ath5k_desc *ds = bf->desc;
> struct ath5k_hw_5212_tx_desc *td = &ds->ud.ds_tx5212;
> struct ath5k_tx_status ts = {};
> @@ -971,6 +973,7 @@ ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct
> ath5k_buf *bf) td->tx_ctl.tx_control_2, td->tx_ctl.tx_control_3,
> td->tx_stat.tx_status_0, td->tx_stat.tx_status_1,
> done ? ' ' : (ts.ts_status == 0) ? '*' : '!');
> +#endif
> }
>
> #endif /* ifdef CONFIG_ATH5K_DEBUG */
> diff --git a/drivers/net/wireless/ath/ath5k/debug.h
> b/drivers/net/wireless/ath/ath5k/debug.h index c260b00..8a484f2 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.h
> +++ b/drivers/net/wireless/ath/ath5k/debug.h
> @@ -83,7 +83,6 @@ struct ath5k_dbg_info {
> /**
> * enum ath5k_debug_level - ath5k debug level
> *
> - * @ATH5K_DEBUG_RESET: reset processing
> * @ATH5K_DEBUG_INTR: interrupt handling
> * @ATH5K_DEBUG_MODE: mode init/setup
> * @ATH5K_DEBUG_XMIT: basic xmit operation
> @@ -104,7 +103,6 @@ struct ath5k_dbg_info {
> * be combined together by bitwise OR.
> */
> enum ath5k_debug_level {
> - ATH5K_DEBUG_RESET = 0x00000001,
> ATH5K_DEBUG_INTR = 0x00000002,
> ATH5K_DEBUG_MODE = 0x00000004,
> ATH5K_DEBUG_XMIT = 0x00000008,
again, here my same concerns: printing the reasons for resets is something
which is useful on embedded boards and production setups which can't have
tracing enabled. which is why i want to object against this change!
also adding a reason argument to the reset function just for tracing seems to
be... umm... not so nice... couldn't you add the tracepoints before?
and: didn't we want to split channel change out of reset anyhow?
bruno
^ permalink raw reply
* Re: ath5k Ad Hoc Association
From: Jonathan Guerin @ 2010-07-20 6:39 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTintLd8YTgMQuzbEB36t_i5AL4TePBSDAa7G2zvl@mail.gmail.com>
Hi,
Thanks heaps for replying.
Yes, I've checked the channel (36, 5180) allows beaconing. I've tried
the commands you mentioned, but no luck. If I monitor the interface
from another station, the ath5k drive never appears to beacon.
What I've managed to get working, however, is to start one station
using MadWifi. This definitely beacons, then I bring up the ath5k
interfaces on the other machines using these commands:
*******
# Create interfaces
iw phy phy0 interface add wlan0 type adhoc
iw wlan0 set channel 36
iwconfig wlan0 channel 36
iwconfig wlan0 essid txctest
# Set IP and bring up
ifconfig wlan0 10.0.1.64 netmask 255.255.255.0 up
ifconfig mon0 up
sleep 5
# Scan trick to force association
iwlist scan
*****
They ath5k stations will then correctly join the SSID and I am able to
ping them.
Using the ibss join command doesn't seem to help when I only bring up
ath5k stations - they never seem to beacon at all. This was run from a
monitor interface on the MadWifi node:
****
tcpdump -s 2048 -i mon0 -w dump.pcap
tcpdump: WARNING: mon0: no IPv4 address assigned
tcpdump: listening on mon0, link-type IEEE802_11_RADIO (802.11 plus
radiotap header), capture size 2048 bytes
^C0 packets captured
0 packets received by filter
0 packets dropped by kernel
****
Thanks,
--
Jonathan Guerin
On Tue, Jul 20, 2010 at 5:22 AM, Bob Copeland <me@bobcopeland.com> wrote:
> On Mon, Jul 19, 2010 at 12:35 AM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
>> Hi,
>>
>> I'm trying to get my wireless nodes to associate in ad hoc mode.
> [...]
>> I've built and installed the compat package for this kernel version:
>> compat-wireless-2.6.32.16
>
> Ok, I'm not sure which mainline kernel this corresponds to, but I
> just tested ath5k adhoc with success in the latest wireless-testing
> kernel. Here's what I did:
>
> (had dnsmasq running dhcp for 192.168.10.x, network manager disabled)
>
> $ su
> # modprobe -r ath5k
> # modprobe ath5k
> # iw dev wlan0 set type ibss
> # ifconfig wlan0 192.168.10.1 up
> # iw dev wlan0 ibss join myibss 2462
>
> Then on the other machine (Vista) I just located 'myibss' (so beacons
> are working) and selected it, then successfully pinged 192.168.10.1.
>
> It may depend on which channel you are trying to use; are you on
> a channel that allows beaconing in your regulatory domain?
>
> --
> Bob Copeland %% www.bobcopeland.com
>
^ permalink raw reply
* Re: ath5k Ad Hoc Association
From: Jonathan Guerin @ 2010-07-20 6:59 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTimgt_HdXyGneQMOz7wR7Xs7BBrDUCGoxP1qDcYg@mail.gmail.com>
I've just tried associating with an existing MadWifi station, and the
'ibss join' command doesn't work - the ath5k station eventually gives
up and just creates it's own BSSID.
I used the above method:
# Create interfaces
iw phy phy0 interface add wlan0 type adhoc
iw wlan0 set channel 36
iwconfig wlan0 channel 36
iwconfig wlan0 essid txctest
# Set IP and bring up
ifconfig wlan0 10.0.1.64 netmask 255.255.255.0 up
sleep 5
# Scan trick to force association
iwlist scan
and this works and the station joins the existing Cell ID - I can ping
the other station etc.
Thanks,
--
Jonathan Guerin
On Tue, Jul 20, 2010 at 4:39 PM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
> Hi,
>
> Thanks heaps for replying.
>
> Yes, I've checked the channel (36, 5180) allows beaconing. I've tried
> the commands you mentioned, but no luck. If I monitor the interface
> from another station, the ath5k drive never appears to beacon.
>
> What I've managed to get working, however, is to start one station
> using MadWifi. This definitely beacons, then I bring up the ath5k
> interfaces on the other machines using these commands:
> *******
> # Create interfaces
> iw phy phy0 interface add wlan0 type adhoc
> iw wlan0 set channel 36
> iwconfig wlan0 channel 36
> iwconfig wlan0 essid txctest
>
> # Set IP and bring up
> ifconfig wlan0 10.0.1.64 netmask 255.255.255.0 up
> ifconfig mon0 up
>
> sleep 5
> # Scan trick to force association
> iwlist scan
> *****
>
> They ath5k stations will then correctly join the SSID and I am able to
> ping them.
>
> Using the ibss join command doesn't seem to help when I only bring up
> ath5k stations - they never seem to beacon at all. This was run from a
> monitor interface on the MadWifi node:
> ****
> tcpdump -s 2048 -i mon0 -w dump.pcap
> tcpdump: WARNING: mon0: no IPv4 address assigned
> tcpdump: listening on mon0, link-type IEEE802_11_RADIO (802.11 plus
> radiotap header), capture size 2048 bytes
> ^C0 packets captured
> 0 packets received by filter
> 0 packets dropped by kernel
> ****
>
> Thanks,
>
> --
> Jonathan Guerin
>
>
>
> On Tue, Jul 20, 2010 at 5:22 AM, Bob Copeland <me@bobcopeland.com> wrote:
>> On Mon, Jul 19, 2010 at 12:35 AM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
>>> Hi,
>>>
>>> I'm trying to get my wireless nodes to associate in ad hoc mode.
>> [...]
>>> I've built and installed the compat package for this kernel version:
>>> compat-wireless-2.6.32.16
>>
>> Ok, I'm not sure which mainline kernel this corresponds to, but I
>> just tested ath5k adhoc with success in the latest wireless-testing
>> kernel. Here's what I did:
>>
>> (had dnsmasq running dhcp for 192.168.10.x, network manager disabled)
>>
>> $ su
>> # modprobe -r ath5k
>> # modprobe ath5k
>> # iw dev wlan0 set type ibss
>> # ifconfig wlan0 192.168.10.1 up
>> # iw dev wlan0 ibss join myibss 2462
>>
>> Then on the other machine (Vista) I just located 'myibss' (so beacons
>> are working) and selected it, then successfully pinged 192.168.10.1.
>>
>> It may depend on which channel you are trying to use; are you on
>> a channel that allows beaconing in your regulatory domain?
>>
>> --
>> Bob Copeland %% www.bobcopeland.com
>>
>
^ permalink raw reply
* Re: [ath5k-devel] [PATCH/RFC 0/3] ath5k: add driver tracepoints
From: Johannes Berg @ 2010-07-20 7:54 UTC (permalink / raw)
To: Bruno Randolf; +Cc: ath5k-devel, Bob Copeland, linux-wireless
In-Reply-To: <201007201411.51259.br1@einfach.org>
On Tue, 2010-07-20 at 14:11 +0900, Bruno Randolf wrote:
> hmm, this is really nice stuff, but i'm not sure what to do on embedded boards
> where we don't have python or where it's not possible to use tracing in
> general due to (low) performance reasons
err, tracing has much better performance than printk, and you can get
the trace into a file that you can analyse offline on a "real" machine.
No need for python on the board, and tracing improves performance over
printk.
johannes
^ permalink raw reply
* Re: [PATCH v3] mac80211: remove wep dependency
From: Johannes Berg @ 2010-07-20 10:59 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1278529669-9904-1-git-send-email-linville@tuxdriver.com>
On Wed, 2010-07-07 at 15:07 -0400, John W. Linville wrote:
> The current mac80211 code assumes that WEP is always available. If WEP
> fails to initialize, ieee80211_register_hw will always fail.
>
> In some cases (e.g. FIPS certification), the cryptography used by WEP is
> unavailable. However, in such cases there is no good reason why CCMP
> encryption (or even no link level encryption) cannot be used. So, this
> patch removes mac80211's assumption that WEP (and TKIP) will always be
> available for use.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> v3 -> actually post changed patch...
> v2 -> make it safe to call ieee80211_wep_free even if ieee80211_wep_init
> had failed
I think this is missing a change like this:
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1228,6 +1228,10 @@ static int ieee80211_scan(struct wiphy *wiphy,
static int ieee80211_auth(struct wiphy *wiphy, struct net_device *dev,
struct cfg80211_auth_request *req)
{
+ if (req->auth_type == NL80211_AUTHTYPE_SHARED_KEY &&
+ IS_ERR(sdata->local->wep_tx_tfm))
+ return -EINVAL;
+
return ieee80211_mgd_auth(IEEE80211_DEV_TO_SUB_IF(dev), req);
}
since otherwise you could end up trying to encrypt the auth frame with
the uninitialised WEP TFM?
johannes
^ permalink raw reply
* Re: ath5k Ad Hoc Association
From: Bob Copeland @ 2010-07-20 11:20 UTC (permalink / raw)
To: Jonathan Guerin; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTimgt_HdXyGneQMOz7wR7Xs7BBrDUCGoxP1qDcYg@mail.gmail.com>
[please don't top post]
On Tue, Jul 20, 2010 at 04:39:29PM +1000, Jonathan Guerin wrote:
> Yes, I've checked the channel (36, 5180) allows beaconing. I've tried
> the commands you mentioned, but no luck. If I monitor the interface
> from another station, the ath5k drive never appears to beacon.
What does "iw phy phy0 info" show?
--
Bob Copeland %% www.bobcopeland.com
^ 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