* Re: ath5k: monitor mode needs channel change
From: Joerg Albert @ 2009-08-01 22:14 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <b6c5339f0907311140o7e92a74eqf3ad095ac8412281@mail.gmail.com>
On 07/31/2009 08:40 PM, Bob Copeland wrote:
> Hmm, well, probably a ath5k_reset() in add_interface would do the
> trick. Maybe there's some wrong assumption about when
> configure_filter() is called.
Adding ath5k_reset() to the end of ath5k_add_interface didn't help.
Seems like in the case of
ifconfig wlan0 down
iwconfig wlan0 mode monitor channel 1
ifconfig wlan0 up
ath5k_chan_set() is called by ath5k_config() with sc->curchan == chan
and it doesn't call ath5k_reset() - which I guess is needed
to activate the new hw rx_filter.
ath5k_config() gets parameter changed == 0xffffffff,
i.e. CONF_CHANGE_CHANNEL is flagged.
With the following
iwconfig wlan0 channel 2
ath_chan_set() gets called with
sc->curchan->center_freq != chan->center_freq and
ath5k_reset() is invoked.
Patch follows.
Regards,
Joerg.
^ permalink raw reply
* Re: [PATCH 1/2] input: Add KEY_RFKILL_ALL
From: Matthew Garrett @ 2009-08-01 22:25 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-input, johannes, linux-wireless, dmitry.torokhov
In-Reply-To: <1249164685.3491.28.camel@localhost.localdomain>
On Sat, Aug 01, 2009 at 03:11:25PM -0700, Marcel Holtmann wrote:
> and that is what it should NOT imply. The policy if it applies to all
> internal devices, all devices in general or just WiFi or Bluetooth for
> example is up to the user.
>
> We are NOT going to have any kind of RFKILL policy in the kernel in the
> future. We will remove rfkill-input once we have a proper userspace
> solution (aka rfkilld or similar).
We seem to be talking at cross purposes here. My objection to the name
KEY_RFKILL is that it gives no indication what it's meant to be or why
it's different to KEY_WLAN. KEY_RFKILL implies that it's the only input
component that an rfkill policy agent needs to listen to, which isn't
the case.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* [PATCH] ath5k: fix missing output in monitor mode after ifconfig up
From: Joerg Albert @ 2009-08-01 22:33 UTC (permalink / raw)
To: John W. Linville
Cc: ath5k-devel, Luis R. Rodriguez, linux-wireless@vger.kernel.org,
Bob Copeland
Let ath5k_chan_set() call ath5k_reset() if ath5k_config() was told
that the channel changed. This fixes the bug that we don't
get any packets in monitor mode after:
ifconfig wlan0 down
iwconfig wlan0 mode monitor channel 1
ifconfig wlan0 up
but they arrive after
iwconfig wlan0 channel 2
Signed-off-by: Joerg Albert <jal2@gmx.de>
---
drivers/net/wireless/ath/ath5k/base.c | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 3a1c156..09ca89c 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -289,7 +289,8 @@ static unsigned int ath5k_copy_channels(struct ath5k_hw *ah,
unsigned int max);
static int ath5k_setup_bands(struct ieee80211_hw *hw);
static int ath5k_chan_set(struct ath5k_softc *sc,
- struct ieee80211_channel *chan);
+ struct ieee80211_channel *chan,
+ int chan_changed);
static void ath5k_setcurmode(struct ath5k_softc *sc,
unsigned int mode);
static void ath5k_mode_setup(struct ath5k_softc *sc);
@@ -1079,14 +1080,13 @@ ath5k_setup_bands(struct ieee80211_hw *hw)
* Called with sc->lock.
*/
static int
-ath5k_chan_set(struct ath5k_softc *sc, struct ieee80211_channel *chan)
+ath5k_chan_set(struct ath5k_softc *sc, struct ieee80211_channel *chan,
+ int chan_changed)
{
- ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "(%u MHz) -> (%u MHz)\n",
- sc->curchan->center_freq, chan->center_freq);
-
- if (chan->center_freq != sc->curchan->center_freq ||
- chan->hw_value != sc->curchan->hw_value) {
+ ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "(%u MHz) -> (%u MHz) chan_changed %x\n",
+ sc->curchan->center_freq, chan->center_freq, chan_changed);
+ if (chan_changed) {
/*
* To switch channels clear any pending DMA operations;
* wait long enough for the RX fifo to drain, reset the
@@ -2811,7 +2811,8 @@ ath5k_config(struct ieee80211_hw *hw, u32 changed)
mutex_lock(&sc->lock);
- ret = ath5k_chan_set(sc, conf->channel);
+ ret = ath5k_chan_set(sc, conf->channel,
+ changed & IEEE80211_CONF_CHANGE_CHANNEL);
if (ret < 0)
goto unlock;
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/1] rfkill: add the GPS radio type
From: Tomas Winkler @ 2009-08-01 23:36 UTC (permalink / raw)
To: linville, johannes; +Cc: linux-wireless, Tomas Winkler
Althoug GPS is a technology w/o transmitting radio
and thus not a primary candidate for rfkill switch,
rfkill gives unified interface point for devices with
wireless technology.
The input key is not supplied as it is too be deprecated.
Cc: johannes@sipsolutions.net
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
include/linux/rfkill.h | 1 +
net/rfkill/core.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index 1020290..21ca51b 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -47,6 +47,7 @@ enum rfkill_type {
RFKILL_TYPE_UWB,
RFKILL_TYPE_WIMAX,
RFKILL_TYPE_WWAN,
+ RFKILL_TYPE_GPS,
NUM_RFKILL_TYPES,
};
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 044de1c..dbeaf29 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -589,11 +589,13 @@ static const char *rfkill_get_type_str(enum rfkill_type type)
return "wimax";
case RFKILL_TYPE_WWAN:
return "wwan";
+ case RFKILL_TYPE_GPS:
+ return "gps";
default:
BUG();
}
- BUILD_BUG_ON(NUM_RFKILL_TYPES != RFKILL_TYPE_WWAN + 1);
+ BUILD_BUG_ON(NUM_RFKILL_TYPES != RFKILL_TYPE_GPS + 1);
}
static ssize_t rfkill_type_show(struct device *dev,
--
1.6.0.6
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* [DISCUSS] Implement non standard channel widths
From: Pat Erley @ 2009-08-01 23:55 UTC (permalink / raw)
To: linux-wireless; +Cc: sidhayn
I've been kicking around the idea of attacking the addition of the ability to set non 20MHz channels to the mac80211 stack. I've come up with 2 potentially un-intrusive ways to do this, but before starting, I'd like to get a touch of discussion on which way would be preferred/acceptable upstream (if any are).
1. Extend nl80211_channel_type to have values for the other channel bandwidths we want to support.
Maybe something like NL80211_CHAN_NO_HT_5 for 5MHz, etc.
This is the option I like least and have put the least thought into.
The upside to this is, it'd be the least intrusive into the actual code, with the downside being, that enum is currently really more aptly named nl80211_ht_channel_type, and as such, pretty much everywhere it's used currently would have to test to see if ht is supported, and if it is, if the current ht mode is supported, but also, if it's not NO_HT, if it's a non-standard channel width.
2. Add channel_width to the ieee80211_conf struct
Either an enum of allow channel widths, or a u16 like the frequency.
This is the option I like, and have spent a lot of time thinking about.
The basic steps would be:
a. add ->channel_width, default it to 20MHz
b. add command to nl80211_commands to set channel width
c. add op to cfg80211_ops to tell driver the desired channel width
then any drivers that support not 20MHz channels could implement it.
I figure, going the u16 route would be best as it allows the functionality to be the most flexible.
With this route, setting the channel width would be done something like:
iw dev <devname> set width <width in MHz>
or maybe
iw dev <devname> set freq <freq in MHz>[@<width in MHZ>]
-- Problems common to both --
In the beginning, I think that leaving the supported channels static to whatever operating band the card is in, is fine. Yes, going to 10MHz channels would double the number of available channels in a band, but with the absolute lack of hardware(AP/Router) that supports it, having a pre-set double sized channel list seems pointless. I suspect most people who would use this would want to set center frequency anyways, rather than specific channel, but that's another can of worms.
Another problem, odd channel width channels. With a 5MHz channel, would you do center freq +/-2.5MHz, or center freq +2/-3MHz/etc? Or maybe limit the problem to only even channel widths?
Next problem, background scanning. I think that disabling background scanning when not operating in a standard frequency would be a 'good thing', as all of the applications I can think of that would use this are cases where scanning isn't really necessary. I could go either way on this topic though.
Final problem, HT channels. I think that channel bonding should be mutually exclusive with non 20MHz channels. In theory, bonded 10MHz channels could provide better throughput than a single 20MHz channel, due to the ability of a 10MHz channel to get above the noise floor at a distance, but again, this seems like the amount of work to implement would grossly increase the complexity of the problem. Maybe this is something that should be left up to drivers as to if they can support it.
---
In the end, I've been spending a bit of time looking at Sam's ATH5k hal, and intend on getting a pair of ath5k devices talking to each other in 5/10MHz channels. I've already done a gross hack to get ath5k setting non 20MHz channels via a /sys interface, but that's not exactly a mergable solution(in my opinion, anyways). I need 5MHz channels for a project I'm working on (no line of sight 2mile link with a pair of ath5k cards that have a hardware frequency scalar to 900MHz on them), so I'm going to end up doing something, and I'd rather that something be merged into mainline than a set of patches I have to maintain for eternity. I'd also like it to be a well thought out solution that someone else has pointed out the errors in my ways as to the actual approach taken.
Pat Erley
^ permalink raw reply
* Re: [PATCH 1/1] rfkill: add the GPS radio type
From: Marcel Holtmann @ 2009-08-02 0:04 UTC (permalink / raw)
To: Tomas Winkler; +Cc: linville, johannes, linux-wireless
In-Reply-To: <1249169809-11853-1-git-send-email-tomas.winkler@intel.com>
Hi Tomas,
> Althoug GPS is a technology w/o transmitting radio
> and thus not a primary candidate for rfkill switch,
> rfkill gives unified interface point for devices with
> wireless technology.
>
> The input key is not supplied as it is too be deprecated.
>
> Cc: johannes@sipsolutions.net
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
we don't have a GPS subsystem, but even without it, I think this is a
good thing to have.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Please also send a patch updating the rfkill userspace utility.
Regards
Marcel
^ permalink raw reply
* Re: rt2800usb: memory corruption?
From: Pavel Roskin @ 2009-08-02 0:21 UTC (permalink / raw)
To: Mike Galbraith; +Cc: linux-wireless, LKML, John W. Linville
In-Reply-To: <1249124154.8236.5.camel@marge.simson.net>
On Sat, 2009-08-01 at 12:55 +0200, Mike Galbraith wrote:
> Enabled slub/pagealloc debugging. First down/rmmod said...
I suggest that you try kmemcheck. It's very slow, but it finds memory
problems when they occur, not when it's too late.
You may want to disable kmemleak and framebuffer support and make sure
that X doesn't start, at it will be too slow. Slub debugging might
conflict with kmemcheck, so it's better to disable it.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 1/2] input: Add KEY_RFKILL_ALL
From: Henrique de Moraes Holschuh @ 2009-08-02 1:05 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-input, johannes, linux-wireless, dmitry.torokhov
In-Reply-To: <1249152859-14769-1-git-send-email-mjg@redhat.com>
On Sat, 01 Aug 2009, Matthew Garrett wrote:
> This patch adds a new keycode, KEY_RFKILL_ALL. It indicates that the
> system should toggle the state of all rfkillable devices.
What should happen when you press it? Toggle state, or the same as EV_SW
SW_RFKILL_ALL OFF (i.e. radios off, killing active) ?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: [PATCH 1/2] input: Add KEY_RFKILL_ALL
From: Matthew Garrett @ 2009-08-02 1:15 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: linux-input, johannes, linux-wireless, dmitry.torokhov
In-Reply-To: <20090802010557.GA11073@khazad-dum.debian.net>
On Sat, Aug 01, 2009 at 10:05:57PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 01 Aug 2009, Matthew Garrett wrote:
> > This patch adds a new keycode, KEY_RFKILL_ALL. It indicates that the
> > system should toggle the state of all rfkillable devices.
>
> What should happen when you press it? Toggle state, or the same as EV_SW
> SW_RFKILL_ALL OFF (i.e. radios off, killing active) ?
rfkill-input should toggle, userspace policy can be anything.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH] Fix SPARC64 unaligned access in zd_mac_rx
From: Patrick Simmons @ 2009-08-02 1:41 UTC (permalink / raw)
To: David Miller; +Cc: mb, johannes, linux-wireless, dsd, kune
In-Reply-To: <20090801.091207.217317135.davem@davemloft.net>
David Miller wrote:
> From: Michael Buesch <mb@bu3sch.de>
> Date: Sat, 1 Aug 2009 12:40:16 +0200
>
>> On Saturday 01 August 2009 07:23:50 David Miller wrote:
>>> From: Johannes Berg <johannes@sipsolutions.net>
>>> Date: Fri, 31 Jul 2009 10:39:43 +0200
>>>
>>>> On Fri, 2009-07-31 at 01:59 -0600, Patrick Simmons wrote:
>>>>> I'm running zd1211rw on SPARC64 and was getting a lot of "unaligned
>>>>> access" messages in dmesg. I tracked the problem down to this line, and
>>>>> changing the cast to a memcpy fixes the issue.
>>>>>
>>>>> - fc = *(__le16 *)buffer;
>>>>> + memcpy(&fc,buffer,sizeof(__le16));
>>>>> need_padding = ieee80211_is_data_qos(fc) ^ ieee80211_has_a4(fc);
>>>> Please use get_unaligned instead.
>>> And, more specifically, one of the endian get_unaligned variants.
>> No. fc is supposed to be LE.
>
> Ok, I see.
Revised patch below.
Signed-off-by: Patrick Simmons <linuxrocks123@netscape.net>
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -694,7 +694,7 @@
&& !mac->pass_ctrl)
return 0;
- fc = *(__le16 *)buffer;
+ fc = get_unaligned(buffer);
need_padding = ieee80211_is_data_qos(fc) ^ ieee80211_has_a4(fc);
skb = dev_alloc_skb(length + (need_padding ? 2 : 0));
--
If I'm not here, I've gone out to find myself. If I get back before I
return, please keep me here.
^ permalink raw reply
* Regression since 2.6.31-rc3-wl
From: Larry Finger @ 2009-08-02 1:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: wireless, John Linville
When I tested 2.6.31-rc4-wl on my old i386 laptop that uses ifup to
control the network, wireless did not work. The problem was bisected
to the following:
commit f1b3c87b70287ded1338fb03a0a714d185041a96
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Tue Jul 7 03:56:05 2009 +0200
cfg80211: fix netdev down problem
We shouldn't be looking at the ssid_len for non-IBSS,
and for IBSS we should also return an error on trying
to leave an IBSS while not in or joining an IBSS.
This fixes an issue where we wouldn't disconnect() on
an interface being taken down since there's no SSID
configured this way.
The patch cannot be reverted as net/wireless.ibss.c has changed.
Reverting the first hunk that modifies net/wireless/core.c does not
make the system work.
Larry
^ permalink raw reply
* Re: [PATCH] ath5k: fix missing output in monitor mode after ifconfig up
From: Bob Copeland @ 2009-08-02 3:20 UTC (permalink / raw)
To: Joerg Albert
Cc: John W. Linville, ath5k-devel, Luis R. Rodriguez,
linux-wireless@vger.kernel.org
In-Reply-To: <4A74C2B6.3070407@gmx.de>
On Sun, Aug 02, 2009 at 12:33:26AM +0200, Joerg Albert wrote:
> Let ath5k_chan_set() call ath5k_reset() if ath5k_config() was told
> that the channel changed. This fixes the bug that we don't
> get any packets in monitor mode after:
Cool, thanks for the patch. Just a couple of comments:
> + int chan_changed);
Should use bool for that.
> - ret = ath5k_chan_set(sc, conf->channel);
> + ret = ath5k_chan_set(sc, conf->channel,
> + changed & IEEE80211_CONF_CHANGE_CHANNEL);
Since this is the only place ath5k_chan_set is called, how about changing
ath5k_chan_set to unconditionally do a reset, and put the test outside?
i.e.:
if (changed & IEEE80211_CONF_CHANGE_CHANNEL)
ath5k_chan_set(sc, conf->channel);
Thanks!
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH] b43legacy: Work around mac80211 race condition
From: Larry Finger @ 2009-08-02 3:32 UTC (permalink / raw)
To: John W Linville, Michael Buesch; +Cc: bcm43xx-dev, 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
b43legacy does not crash when this condition occurs, it does generate a WARN_ON
and also logs a queue overrun message. This patch recognizes b43legacy 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.
This patch is based on the one used by b43.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Index: wireless-testing/drivers/net/wireless/b43legacy/dma.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43legacy/dma.c
+++ wireless-testing/drivers/net/wireless/b43legacy/dma.c
@@ -1366,15 +1366,25 @@ int b43legacy_dma_tx(struct b43legacy_wl
ring = priority_to_txring(dev, skb_get_queue_mapping(skb));
spin_lock_irqsave(&ring->lock, flags);
B43legacy_WARN_ON(!ring->tx);
- if (unlikely(free_slots(ring) < SLOTS_PER_PACKET)) {
- b43legacywarn(dev->wl, "DMA queue overflow\n");
+
+ 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 (b43legacy_debug(dev, B43legacy_DBG_DMAVERBOSE))
+ b43legacyerr(dev->wl, "Packet after queue stopped\n");
+ err = -ENOSPC;
+ goto out_unlock;
+ }
+
+ if (unlikely(WARN_ON(free_slots(ring) < SLOTS_PER_PACKET))) {
+ /* If we get here, we have a real error with the queue
+ * full, but queues not stopped. */
+ b43legacyerr(dev->wl, "DMA queue overflow\n");
err = -ENOSPC;
goto out_unlock;
}
- /* Check if the queue was stopped in mac80211,
- * but we got called nevertheless.
- * That would be a mac80211 bug. */
- B43legacy_BUG_ON(ring->stopped);
err = dma_tx_fragment(ring, skb);
if (unlikely(err == -ENOKEY)) {
^ permalink raw reply
* RE: kernel panic ieee80211_agg_splice_packets+0x3d/0xc0 [mac80211]
From: Pavel Roskin @ 2009-08-02 4:18 UTC (permalink / raw)
To: Jack Lau; +Cc: linux-wireless
In-Reply-To: <SNT102-W3823D5AFC70CB052684837BD110@phx.gbl>
On Sat, 2009-08-01 at 10:03 +0000, Jack Lau wrote:
> Dear Pavel
>
> I have now taken the time to gather as many logs as possible.
...
> > Also please don't top-post, as it makes it harder to quote the
> > discussion in a reasonable way.
Please read what you are quoting. Until then, it makes no sense for me
to participate in this thread.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: rt2800usb: memory corruption?
From: Mike Galbraith @ 2009-08-02 5:16 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless, LKML, John W. Linville
In-Reply-To: <1249172514.3043.7.camel@ct>
On Sat, 2009-08-01 at 20:21 -0400, Pavel Roskin wrote:
> On Sat, 2009-08-01 at 12:55 +0200, Mike Galbraith wrote:
>
> > Enabled slub/pagealloc debugging. First down/rmmod said...
>
> I suggest that you try kmemcheck. It's very slow, but it finds memory
> problems when they occur, not when it's too late.
>
> You may want to disable kmemleak and framebuffer support and make sure
> that X doesn't start, at it will be too slow. Slub debugging might
> conflict with kmemcheck, so it's better to disable it.
I didn't even get as far as down/rmmod. Kmemcheck fired as soon as the
interface came up.
[ 230.954526] rt2800usb 2-5:1.0: firmware: requesting rt2870.bin
[ 231.388801] input: rt2800usb as /devices/pci0000:00/0000:00:1a.7/usb2/2-5/2-5:1.0/input/input4
[ 232.281796] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 235.428512] wlan0: direct probe to AP 00:1a:4f:9a:d0:12 try 1
[ 235.437710] wlan0 direct probe responded
[ 235.437740] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
[ 235.441546] wlan0: authenticated
[ 235.441578] wlan0: associate with AP 00:1a:4f:9a:d0:12
[ 235.448697] wlan0: RX AssocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
[ 235.448719] wlan0: associated
[ 235.495961] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 246.172043] wlan0: no IPv6 routers present
[ 282.661880] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8800bfb8c9f0)
[ 282.670576] 0000000000000000000000000000000000000000000000000000000000000000
[ 282.678086] u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u
[ 282.685594] ^
[ 282.690079]
[ 282.691571] Modules linked in: nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device ip6t_REJECT nf_conntrack_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_ipv4 cpufreq_conservative nf_conntrack nf_defrag_ipv4 cpufreq_ondemand cpufreq_userspace ip_tables cpufreq_powersave acpi_cpufreq ip6table_filter ip6_tables x_tables microcode ipv6 fuse loop dm_mod snd_hda_codec_realtek arc4 ecb i2c_i801 firewire_ohci i2c_core firewire_core snd_hda_intel crc_itu_t rt2800usb snd_hda_codec rt2x00usb sr_mod snd_hwdep ohci1394 rt2x00lib cdrom snd_pcm led_class input_polldev sg snd_timer ieee1394 mac80211 snd usb_storage soundcore snd_page_alloc cfg80211 crc_ccitt usb_libusual e1000e intel_agp rtc_cmos rtc_core rtc_lib button thermal processor usbhid hid sd_mod uhci_hcd ehci_hcd usbcore edd fan ext3 mbcache jbd ahci libata scsi_mod
[ 282.775664] Pid: 5857, comm: rpcinfo Not tainted 2.6.31-smp #1005 MS-7502
[ 282.782444] RIP: 0010:[<ffffffff8123f6e3>] [<ffffffff8123f6e3>] sk_clone+0x23/0x290
[ 282.790215] RSP: 0018:ffff88000156bb98 EFLAGS: 00010286
[ 282.795521] RAX: ffff8800bfb8c800 RBX: ffff8800bfb8c800 RCX: 0000000000000000
[ 282.802645] RDX: 0000000000000020 RSI: 0000000000000002 RDI: ffff8800bfb8c800
[ 282.809769] RBP: ffff88000156bba8 R08: 0000000000000004 R09: ffff8800be46c838
[ 282.816895] R10: 0000000000000000 R11: 000000000100007f R12: ffff8800bfb88000
[ 282.824021] R13: ffff8800be8eed00 R14: ffff8800bfb88000 R15: ffff8800bfb88000
[ 282.831149] FS: 00007f2e15b5a6f0(0000) GS:ffff880001568000(0000) knlGS:0000000000000000
[ 282.839230] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 282.844966] CR2: ffff8800377da024 CR3: 00000000b3c2c000 CR4: 00000000000006f0
[ 282.852089] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 282.859213] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
[ 282.866336] [<ffffffff8127f321>] inet_csk_clone+0x11/0xc0
[ 282.871829] [<ffffffff81297c8e>] tcp_create_openreq_child+0x1e/0x420
[ 282.878282] [<ffffffff81296b18>] tcp_v4_syn_recv_sock+0x48/0x280
[ 282.884383] [<ffffffff812979ad>] tcp_check_req+0x1dd/0x4a0
[ 282.889964] [<ffffffff81295c74>] tcp_v4_do_rcv+0x324/0x430
[ 282.895561] [<ffffffff81296414>] tcp_v4_rcv+0x694/0x880
[ 282.900887] [<ffffffff812751d1>] ip_local_deliver_finish+0xd1/0x230
[ 282.907249] [<ffffffff812753bd>] ip_local_deliver+0x8d/0xa0
[ 282.912917] [<ffffffff81274b5e>] ip_rcv_finish+0x19e/0x3f0
[ 282.918498] [<ffffffff81275071>] ip_rcv+0x2c1/0x350
[ 282.923473] [<ffffffff8124c164>] netif_receive_skb+0x314/0x5f0
[ 282.929405] [<ffffffff8124c4b5>] process_backlog+0x75/0xc0
[ 282.934985] [<ffffffff8124ccc8>] net_rx_action+0x108/0x210
[ 282.940567] [<ffffffff8104e972>] __do_softirq+0xe2/0x1c0
[ 282.945975] [<ffffffff8100cf5c>] call_softirq+0x1c/0x30
[ 282.951294] [<ffffffff8100ee65>] do_softirq+0x45/0x80
[ 282.956441] [<ffffffff8104e745>] local_bh_enable_ip+0xa5/0xb0
[ 282.962284] [<ffffffff812f542f>] _spin_unlock_bh+0xf/0x20
[ 282.967779] [<ffffffff8123e567>] release_sock+0xb7/0xd0
[ 282.973098] [<ffffffff812a4cb6>] inet_stream_connect+0x186/0x2c0
[ 282.979200] [<ffffffff8123c938>] sys_connect+0xb8/0xd0
[ 282.984434] [<ffffffff8100be2b>] system_call_fastpath+0x16/0x1b
[ 282.990447] [<ffffffffffffffff>] 0xffffffffffffffff
[ 328.666950] martian source 192.168.178.31 from 192.168.178.23, on dev wlan0
[ 328.670921] ll header: ff:ff:ff:ff:ff:ff:00:0c:76:67:11:5a:08:06
^ permalink raw reply
* Re: [PATCH 1/1] rfkill: add the GPS radio type
From: Tomas Winkler @ 2009-08-02 5:49 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linville, johannes, linux-wireless
In-Reply-To: <1249171448.3491.32.camel@localhost.localdomain>
On Sun, Aug 2, 2009 at 3:04 AM, Marcel Holtmann<marcel@holtmann.org> wrote:
> Hi Tomas,
>
>> Althoug GPS is a technology w/o transmitting radio
>> and thus not a primary candidate for rfkill switch,
>> rfkill gives unified interface point for devices with
>> wireless technology.
>>
>> The input key is not supplied as it is too be deprecated.
>>
>> Cc: johannes@sipsolutions.net
>> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
>
> we don't have a GPS subsystem, but even without it, I think this is a
> good thing to have.
GPS devices are usually serial devices.
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
>
> Please also send a patch updating the rfkill userspace utility.
On the way....
Tomas
^ permalink raw reply
* Re: rt2800usb: memory corruption?
From: Mike Galbraith @ 2009-08-02 6:29 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless, LKML, John W. Linville
In-Reply-To: <1249190209.7486.4.camel@marge.simson.net>
On Sun, 2009-08-02 at 07:16 +0200, Mike Galbraith wrote:
> On Sat, 2009-08-01 at 20:21 -0400, Pavel Roskin wrote:
> > On Sat, 2009-08-01 at 12:55 +0200, Mike Galbraith wrote:
> >
> > > Enabled slub/pagealloc debugging. First down/rmmod said...
> >
> > I suggest that you try kmemcheck. It's very slow, but it finds memory
> > problems when they occur, not when it's too late.
> >
> > You may want to disable kmemleak and framebuffer support and make sure
> > that X doesn't start, at it will be too slow. Slub debugging might
> > conflict with kmemcheck, so it's better to disable it.
>
>
> I didn't even get as far as down/rmmod. Kmemcheck fired as soon as the
> interface came up.
Corruption seems to be SMP only. I cycled down/rmmod/modprobe a few
times with kmemcheck enabled (disables smp unfortunately), kmemcheck
didn't trigger, nor did box have a conniption.
-Mike
^ permalink raw reply
* Re: Multiple BSSID problem with hostapd
From: Christian Felsing @ 2009-08-02 6:33 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4A73F9CB.8000606@taunusstein.net>
After investigating source code following function caused my problem:
static int i802_bss_add(void *priv, const char *ifname, const u8 *bssid)
{
int ifidx;
/*
* The kernel supports that when the low-level driver does,
* but we currently don't because we need per-BSS data that
* currently we can't handle easily.
*/
return -1;
ifidx = nl80211_create_iface(priv, ifname, NL80211_IFTYPE_AP,
bssid);
if (ifidx < 0)
return -1;
if (hostapd_set_iface_flags(priv, ifname, 1)) {
nl80211_remove_iface(priv, ifidx);
return -1;
}
return 0;
}
Obviously hostapd does not support multiple SSIDs because that function
returns always an error.
It would be nice to mention that in documentation...
Christian
^ permalink raw reply
* Re: rt2800usb: memory corruption?
From: Mike Galbraith @ 2009-08-02 6:47 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless, LKML, John W. Linville
In-Reply-To: <1249194546.7634.4.camel@marge.simson.net>
P.S. I'm no longer considering moving box away from router (and if I
ever do, I'll use repeater instead), so wireless connectivity via this
adapter is a dead issue here. Since I have the hw though, if anyone
wants patches tested, feel free to holler, and I'll give them a spin.
-Mike
^ permalink raw reply
* [PATCH] airo: Read buffer overflow
From: Roel Kluin @ 2009-08-02 7:23 UTC (permalink / raw)
To: linville, linux-wireless, Andrew Morton
Check whether index is within bounds before testing the element.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index c70604f..e8ac4d9 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -6819,7 +6819,7 @@ static int airo_set_txpow(struct net_device *dev,
return -EINVAL;
}
clear_bit (FLAG_RADIO_OFF, &local->flags);
- for (i = 0; cap_rid.txPowerLevels[i] && (i < 8); i++)
+ for (i = 0; i < 8 && cap_rid.txPowerLevels[i]; i++)
if (v == cap_rid.txPowerLevels[i]) {
readConfigRid(local, 1);
local->config.txPower = v;
^ permalink raw reply related
* Re: [PATCH] ath5k: fix missing output in monitor mode after ifconfig up
From: Joerg Albert @ 2009-08-02 7:36 UTC (permalink / raw)
To: Bob Copeland
Cc: John W. Linville, ath5k-devel, Luis R. Rodriguez,
linux-wireless@vger.kernel.org
In-Reply-To: <20090802032019.GA25339@hash.localnet>
On 08/02/2009 05:20 AM, Bob Copeland wrote:
> On Sun, Aug 02, 2009 at 12:33:26AM +0200, Joerg Albert wrote:
>> Let ath5k_chan_set() call ath5k_reset() if ath5k_config() was told
>> that the channel changed. This fixes the bug that we don't
>> get any packets in monitor mode after:
>
> Cool, thanks for the patch. Just a couple of comments:
>
>> + int chan_changed);
>
> Should use bool for that.
>
>> - ret = ath5k_chan_set(sc, conf->channel);
>> + ret = ath5k_chan_set(sc, conf->channel,
>> + changed & IEEE80211_CONF_CHANGE_CHANNEL);
>
> Since this is the only place ath5k_chan_set is called, how about changing
> ath5k_chan_set to unconditionally do a reset, and put the test outside?
>
> i.e.:
>
> if (changed & IEEE80211_CONF_CHANGE_CHANNEL)
> ath5k_chan_set(sc, conf->channel);
Good idea. I'll redo the patch.
BTW, it assumes that IEEE80211_CONF_CHANGE_CHANNEL is set even if only chan->hw_value has changed,
e.g. by switching from A to TurboA on the same channel. AFAIK TurboX isn't currently supported by ath5k.
Regards,
Jörg.
^ permalink raw reply
* [PATCH] libertas: Read buffer overflow
From: Roel Kluin @ 2009-08-02 7:44 UTC (permalink / raw)
To: linville, linux-wireless, Andrew Morton
Check whether index is within bounds before testing the element.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/net/wireless/libertas/11d.c b/drivers/net/wireless/libertas/11d.c
index 9a5408e..5c69681 100644
--- a/drivers/net/wireless/libertas/11d.c
+++ b/drivers/net/wireless/libertas/11d.c
@@ -47,7 +47,7 @@ static u8 lbs_region_2_code(u8 *region)
{
u8 i;
- for (i = 0; region[i] && i < COUNTRY_CODE_LEN; i++)
+ for (i = 0; i < COUNTRY_CODE_LEN && region[i]; i++)
region[i] = toupper(region[i]);
for (i = 0; i < ARRAY_SIZE(region_code_mapping); i++) {
^ permalink raw reply related
* Re: [PATCH 1/1] rfkill: add the GPS radio type
From: Johannes Berg @ 2009-08-02 7:45 UTC (permalink / raw)
To: Tomas Winkler; +Cc: Marcel Holtmann, linville, linux-wireless
In-Reply-To: <1ba2fa240908012249s348a2412wca21de44f9b8cb71@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
On Sun, 2009-08-02 at 08:49 +0300, Tomas Winkler wrote:
> > we don't have a GPS subsystem, but even without it, I think this is a
> > good thing to have.
>
> GPS devices are usually serial devices.
Yeah, this is interesting -- do we want something like /dev/urfkill
(cf. /dev/uinput), so that gpsd or whatever is controlling the GPS (same
applies for 3G) can be controlled with rfkill?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] airo: Read buffer overflow
From: Roel Kluin @ 2009-08-02 7:49 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Andrew Morton
In-Reply-To: <4A753EDE.9030506@gmail.com>
Op 02-08-09 09:23, Roel Kluin schreef:
> Check whether index is within bounds before testing the element.
Please ignore, I already sent this, sorry.
^ permalink raw reply
* Re: Regression since 2.6.31-rc3-wl
From: Johannes Berg @ 2009-08-02 7:46 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless, John Linville
In-Reply-To: <4A74F1E3.8050502@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
Hi Larry,
On Sat, 2009-08-01 at 20:54 -0500, Larry Finger wrote:
> When I tested 2.6.31-rc4-wl on my old i386 laptop that uses ifup to
> control the network, wireless did not work. The problem was bisected
> to the following:
Thanks for taking the time to bisect the problem, can you be more
specific as to how the problem manifests itself? Are you using ifup to
configure an ad-hoc network?
Thanks,
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ 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