* 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: Marcel Holtmann @ 2009-08-01 22:11 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-input, johannes, linux-wireless, dmitry.torokhov
In-Reply-To: <20090801215130.GA24201@srcf.ucam.org>
Hi Matthew,
> > why is it confusing? I don't understanding your argument here. I think
> > the KEY_RFKILL_ALL is confusing is the user policy then only kills WiFi
> > devices or toggles between various on/off combinations.
>
> Having it be KEY_RFKILL implies that KEY_WLAN and similar aren't related
> to rfkill. KEY_RFKILL_ALL implies that the key invokes policy on all
> rfkill devices, which is the aim here.
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).
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/2] input: Add KEY_RFKILL_ALL
From: Matthew Garrett @ 2009-08-01 21:51 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-input, johannes, linux-wireless, dmitry.torokhov
In-Reply-To: <1249163327.3491.24.camel@localhost.localdomain>
On Sat, Aug 01, 2009 at 02:48:47PM -0700, Marcel Holtmann wrote:
> why is it confusing? I don't understanding your argument here. I think
> the KEY_RFKILL_ALL is confusing is the user policy then only kills WiFi
> devices or toggles between various on/off combinations.
Having it be KEY_RFKILL implies that KEY_WLAN and similar aren't related
to rfkill. KEY_RFKILL_ALL implies that the key invokes policy on all
rfkill devices, which is the aim here.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH 1/2] input: Add KEY_RFKILL_ALL
From: Marcel Holtmann @ 2009-08-01 21:48 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-input, johannes, linux-wireless, dmitry.torokhov
In-Reply-To: <20090801205445.GA23751@srcf.ucam.org>
Hi Matthew,
> > actually if the key is clearly hardwired to WLAN, then it should not
> > even show up as input event at all. This is one of the mis-concepts of
> > the old RFKILL subsystem. No need to send an input event if the platform
> > driver is going to rfkill that device anyway.
>
> There's still a policy decision. Does it kill internal devices, or does
> it kill all attached wlan devices?
>
> > Remember that in the end it is just a key and whatever the user does
> > with it is users policy. So in summary it is up to the platform driver
> > to emit the proper key. For some it might be still KEY_WLAN, for other
> > it might be KEY_RFKILL. Sounds fair?
>
> I agree on the technical side, but not the naming. KEY_WLAN is an
> rfkill-related key, so introducing KEY_RFKILL is potentially confusing.
> KEY_RFKILL_ALL isn't.
why is it confusing? I don't understanding your argument here. I think
the KEY_RFKILL_ALL is confusing is the user policy then only kills WiFi
devices or toggles between various on/off combinations.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/2] input: Add KEY_RFKILL_ALL
From: Matthew Garrett @ 2009-08-01 20:54 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-input, johannes, linux-wireless, dmitry.torokhov
In-Reply-To: <1249159942.3491.21.camel@localhost.localdomain>
On Sat, Aug 01, 2009 at 01:52:22PM -0700, Marcel Holtmann wrote:
> actually if the key is clearly hardwired to WLAN, then it should not
> even show up as input event at all. This is one of the mis-concepts of
> the old RFKILL subsystem. No need to send an input event if the platform
> driver is going to rfkill that device anyway.
There's still a policy decision. Does it kill internal devices, or does
it kill all attached wlan devices?
> Remember that in the end it is just a key and whatever the user does
> with it is users policy. So in summary it is up to the platform driver
> to emit the proper key. For some it might be still KEY_WLAN, for other
> it might be KEY_RFKILL. Sounds fair?
I agree on the technical side, but not the naming. KEY_WLAN is an
rfkill-related key, so introducing KEY_RFKILL is potentially confusing.
KEY_RFKILL_ALL isn't.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH 1/2] input: Add KEY_RFKILL_ALL
From: Marcel Holtmann @ 2009-08-01 20:52 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-input, johannes, linux-wireless, dmitry.torokhov
In-Reply-To: <20090801204534.GA23642@srcf.ucam.org>
Hi Matthew,
> > actually I would prefer if we name this key KEY_RFKILL and not put the
> > policy of ALL into the kernel. Since we wanna get rid of rfkill-input.
> > That needs to be done in userspace and by users policy. If they wanna
> > map that key to ALL then that is fine. If they just wanna toggle WiFi,
> > then that is also fine. If the wanna have to popup some UI, that is also
> > reasonable.
>
> My reasoning was that this conceptually maps to a key that controls all
> of the radios in the system - whether a single press actually kills all
> of them or not is kind of irrelevent (having the simple policy in
> rfkill-input works fine for this, but userspace will obviously want
> something more cunning). My concern with KEY_RFKILL is that it it's not
> obvious that it refers to a specific type of key - ones that purely
> control wifi should still be KEY_WLAN, for instance.
actually if the key is clearly hardwired to WLAN, then it should not
even show up as input event at all. This is one of the mis-concepts of
the old RFKILL subsystem. No need to send an input event if the platform
driver is going to rfkill that device anyway.
If a key is clearly labeled as WLAN then it should emit only KEY_WLAN.
And if it is just a generic key with some radio on it like FN-F5 on my
ThinkPad, then it better just emits KEY_RFKILL and we let userspace (or
rfkill-input do the policy).
Remember that in the end it is just a key and whatever the user does
with it is users policy. So in summary it is up to the platform driver
to emit the proper key. For some it might be still KEY_WLAN, for other
it might be KEY_RFKILL. Sounds fair?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/2] input: Add KEY_RFKILL_ALL
From: Matthew Garrett @ 2009-08-01 20:45 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-input, johannes, linux-wireless, dmitry.torokhov
In-Reply-To: <1249159133.3491.13.camel@localhost.localdomain>
On Sat, Aug 01, 2009 at 01:38:53PM -0700, Marcel Holtmann wrote:
> actually I would prefer if we name this key KEY_RFKILL and not put the
> policy of ALL into the kernel. Since we wanna get rid of rfkill-input.
> That needs to be done in userspace and by users policy. If they wanna
> map that key to ALL then that is fine. If they just wanna toggle WiFi,
> then that is also fine. If the wanna have to popup some UI, that is also
> reasonable.
My reasoning was that this conceptually maps to a key that controls all
of the radios in the system - whether a single press actually kills all
of them or not is kind of irrelevent (having the simple policy in
rfkill-input works fine for this, but userspace will obviously want
something more cunning). My concern with KEY_RFKILL is that it it's not
obvious that it refers to a specific type of key - ones that purely
control wifi should still be KEY_WLAN, for instance.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH 2/2] rfkill: Add support for KEY_RFKILL_ALL
From: Marcel Holtmann @ 2009-08-01 20:41 UTC (permalink / raw)
To: Bastien Nocera
Cc: Matthew Garrett, linux-input, johannes, linux-wireless,
dmitry.torokhov
In-Reply-To: <1249158328.28327.10654.camel@localhost.localdomain>
Hi Bastien,
> > + case KEY_RFKILL_ALL:
> > + rfkill_schedule_toggle(RFKILL_TYPE_WLAN);
> > + rfkill_schedule_toggle(RFKILL_TYPE_BLUETOOTH);
> > + rfkill_schedule_toggle(RFKILL_TYPE_UWB);
> > + rfkill_schedule_toggle(RFKILL_TYPE_WIMAX);
> > + break;
>
> RFKILL_TYPE_ALL?
this should be RFKILL_TYPE_ALL indeed. Even if rfkill-input is going to
be removed. For the time being it needs to toggle all. Especially since
the example above already forgets RFKILL_TYPE_WWAN.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/2] input: Add KEY_RFKILL_ALL
From: Marcel Holtmann @ 2009-08-01 20:38 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>
Hi Matthew,
> Most laptops have keys that are intended to toggle all device state, not
> just wifi. These are currently generally mapped to KEY_WLAN. As a result,
> rfkill will only kill or enable wifi in response to the key press. This
> confuses users and can make it difficult for them to enable bluetooth
> and wwan devices.
>
> This patch adds a new keycode, KEY_RFKILL_ALL. It indicates that the
> system should toggle the state of all rfkillable devices.
actually I would prefer if we name this key KEY_RFKILL and not put the
policy of ALL into the kernel. Since we wanna get rid of rfkill-input.
That needs to be done in userspace and by users policy. If they wanna
map that key to ALL then that is fine. If they just wanna toggle WiFi,
then that is also fine. If the wanna have to popup some UI, that is also
reasonable.
So just having a KEY_RFKILL is the better way here and policy free. You
can still for the short term have rfkill-input map this to an ALL policy
until we remove that piece and replace it with a proper userspace
solution (which thanks to /dev/rfkill is now possible).
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/2] rfkill: Add support for KEY_RFKILL_ALL
From: Bastien Nocera @ 2009-08-01 20:25 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-input, johannes, linux-wireless, dmitry.torokhov
In-Reply-To: <1249152859-14769-2-git-send-email-mjg@redhat.com>
On Sat, 2009-08-01 at 19:54 +0100, Matthew Garrett wrote:
>
> + case KEY_RFKILL_ALL:
> + rfkill_schedule_toggle(RFKILL_TYPE_WLAN);
> + rfkill_schedule_toggle(RFKILL_TYPE_BLUETOOTH);
> + rfkill_schedule_toggle(RFKILL_TYPE_UWB);
> + rfkill_schedule_toggle(RFKILL_TYPE_WIMAX);
> + break;
RFKILL_TYPE_ALL?
^ permalink raw reply
* [PATCH 4/5] drivers/net/wireless: Use DIV_ROUND_CLOSEST
From: Julia Lawall @ 2009-08-01 19:50 UTC (permalink / raw)
To: linux-wireless, netdev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d
but is perhaps more readable.
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@haskernel@
@@
#include <linux/kernel.h>
@depends on haskernel@
expression x,__divisor;
@@
- (((x) + ((__divisor) / 2)) / (__divisor))
+ DIV_ROUND_CLOSEST(x,__divisor)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/strip.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/strip.c b/drivers/net/wireless/strip.c
index 73300c2..8eabb56 100644
--- a/drivers/net/wireless/strip.c
+++ b/drivers/net/wireless/strip.c
@@ -1550,9 +1550,12 @@ static int strip_xmit(struct sk_buff *skb, struct net_device *dev)
if (time_after(jiffies, strip_info->pps_timer + HZ)) {
unsigned long t = jiffies - strip_info->pps_timer;
- unsigned long rx_pps_count = (strip_info->rx_pps_count * HZ * 8 + t / 2) / t;
- unsigned long tx_pps_count = (strip_info->tx_pps_count * HZ * 8 + t / 2) / t;
- unsigned long sx_pps_count = (strip_info->sx_pps_count * HZ * 8 + t / 2) / t;
+ unsigned long rx_pps_count =
+ DIV_ROUND_CLOSEST(strip_info->rx_pps_count*HZ*8, t);
+ unsigned long tx_pps_count =
+ DIV_ROUND_CLOSEST(strip_info->tx_pps_count*HZ*8, t);
+ unsigned long sx_pps_count =
+ DIV_ROUND_CLOSEST(strip_info->sx_pps_count*HZ*8, t);
strip_info->pps_timer = jiffies;
strip_info->rx_pps_count = 0;
^ permalink raw reply related
* [PATCH 1/2] input: Add KEY_RFKILL_ALL
From: Matthew Garrett @ 2009-08-01 18:54 UTC (permalink / raw)
To: linux-input; +Cc: johannes, linux-wireless, dmitry.torokhov, Matthew Garrett
Most laptops have keys that are intended to toggle all device state, not
just wifi. These are currently generally mapped to KEY_WLAN. As a result,
rfkill will only kill or enable wifi in response to the key press. This
confuses users and can make it difficult for them to enable bluetooth
and wwan devices.
This patch adds a new keycode, KEY_RFKILL_ALL. It indicates that the
system should toggle the state of all rfkillable devices.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
include/linux/input.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/input.h b/include/linux/input.h
index 8b3bc3e..0eff8ff 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -595,6 +595,8 @@ struct input_absinfo {
#define KEY_NUMERIC_STAR 0x20a
#define KEY_NUMERIC_POUND 0x20b
+#define KEY_RFKILL_ALL 0x20c
+
/* We avoid low common keys in module aliases so they don't get huge. */
#define KEY_MIN_INTERESTING KEY_MUTE
#define KEY_MAX 0x2ff
--
1.6.2.5
^ permalink raw reply related
* [PATCH 2/2] rfkill: Add support for KEY_RFKILL_ALL
From: Matthew Garrett @ 2009-08-01 18:54 UTC (permalink / raw)
To: linux-input; +Cc: johannes, linux-wireless, dmitry.torokhov, Matthew Garrett
In-Reply-To: <1249152859-14769-1-git-send-email-mjg@redhat.com>
Add support for handling KEY_RFKILL_ALL in the rfkill input module. This
simply toggles the state of all rfkill devices.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
net/rfkill/input.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/net/rfkill/input.c b/net/rfkill/input.c
index a7295ad..5517089 100644
--- a/net/rfkill/input.c
+++ b/net/rfkill/input.c
@@ -212,6 +212,12 @@ static void rfkill_event(struct input_handle *handle, unsigned int type,
case KEY_WIMAX:
rfkill_schedule_toggle(RFKILL_TYPE_WIMAX);
break;
+ case KEY_RFKILL_ALL:
+ rfkill_schedule_toggle(RFKILL_TYPE_WLAN);
+ rfkill_schedule_toggle(RFKILL_TYPE_BLUETOOTH);
+ rfkill_schedule_toggle(RFKILL_TYPE_UWB);
+ rfkill_schedule_toggle(RFKILL_TYPE_WIMAX);
+ break;
}
} else if (type == EV_SW && code == SW_RFKILL_ALL)
rfkill_schedule_evsw_rfkillall(data);
@@ -295,6 +301,11 @@ static const struct input_device_id rfkill_ids[] = {
.keybit = { [BIT_WORD(KEY_WIMAX)] = BIT_MASK(KEY_WIMAX) },
},
{
+ .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT,
+ .evbit = { BIT_MASK(EV_KEY) },
+ .keybit = { [BIT_WORD(KEY_RFKILL_ALL)] = BIT_MASK(KEY_RFKILL_ALL) },
+ },
+ {
.flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_SWBIT,
.evbit = { BIT(EV_SW) },
.swbit = { [BIT_WORD(SW_RFKILL_ALL)] = BIT_MASK(SW_RFKILL_ALL) },
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 1/4]: Check EEPROM before tweaking SERDES
From: Kalle Valo @ 2009-08-01 18:37 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Luis R. Rodriguez, ath5k-devel, linux-wireless, linville,
jirislaby, me, nbd
In-Reply-To: <40f31dec0907311127o4bc4de73u1b4b5dfeb66d55b9@mail.gmail.com>
Nick Kossifidis <mickflemm@gmail.com> writes:
>> Yes, but my point is a move can be done in one patch, changes to that
>> code in a separate patch, to help understand what is going on during
>> patch review.
>
> I think this will pollute the logs, it's a very simple change and commented.
I'm with Luis here. It makes a lot easier to read patches and find bugs
if the patches do one thing at a time. Don't worry about the number of
patches, usually that's not a problem.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] Fix SPARC64 unaligned access in zd_mac_rx
From: David Miller @ 2009-08-01 16:12 UTC (permalink / raw)
To: mb; +Cc: johannes, linuxrocks123, linux-wireless, dsd, kune
In-Reply-To: <200908011240.17229.mb@bu3sch.de>
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.
^ permalink raw reply
* Re: wpa_test not used in wpa.c
From: Gábor Stefanik @ 2009-08-01 15:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: Ben Greear, linux-wireless, Patrick McHardy
In-Reply-To: <1249110702.26584.7.camel@johannes.local>
On Sat, Aug 1, 2009 at 9:11 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Fri, 2009-07-31 at 14:42 -0700, Ben Greear wrote:
>> It seems to me that in this method (and others), wpa_test is not
>> actually assigned a useful value, but it's still tested in code
>> branches.
>
>>
>> Any idea on how this is supposed to work?
>
> It isn't really. It's some dead code that you can enable manually for
> testing or so. It used to be possible to use a private ioctl or so to
> set it, iirc, but that's long gone. I'd have no objections to just
> removing it.
>
> johannes
>
Also, it doesn't look like this is getting compiled in any build -
AFAIK "txrx" classes are long gone (since 2.6.26 or so)...
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH 000/002] Fix frequent reconnects caused by new conection monitor
From: Marcel Holtmann @ 2009-08-01 15:25 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: reinette chatre, linux-wireless, linville, Johannes Berg
In-Reply-To: <1249070739.25620.11.camel@maxim-laptop>
Hi Maxim,
> > > > > Hi, here is the updated version of these two patches that fix the
> > > > > $SUBJECT issue.
> > > > >
> > > > > I attach these (in case mailer mangles them), and reply with patches.
> > > > >
> > > > > Tested both with low quality signal, and beacon loss.
> > > > > Lack of TX is found, every 30 seconds now, and quite reliable.
> > > > > Lack of beacons, triggers probe like it did every 2 seconds.
> > > >
> > > > Thanks!
> > > >
> > > > I've been running with this for two hours now with no disconnects. This
> > > > is where before the patches I would get disconnected after a few
> > > > minutes. I did get two "No probe response from AP xx:xx:xx:xx:xx:xx
> > > > after 500ms, try 1" messages in my log.
> > > This is normal, or at least can be normal, I patched the driver to
> > > display this message, when there is a probe timeout, but instead of
> > > disconnect, it retries, currently 5 times, but this can be even further
> > > increased is necessarily.
> > > (these messages are only in logs when verbose mac debugging is enabled)
> > >
> > > I don't know exactly why probes aren't answered, but I strongly suspect
> > > that my AP sometimes 'goes out to lunch' and then answers, since
> > > typically after a failed probe it sends many replies.
> > > (Or it could be some buffering done by iwl3945 microcode). I currently
> > > can't monitor the connection from outside, but as soon as I can I see
> > > whether the above is true. Nevertheless if signal quality isn't great,
> > > there are valid reasons for probe loss, and it shouldn't cause all the
> > > fuzz (and since I use WPA2, every reconnection causes whole WPA
> > > handshake to be preformed, and this takes at least 2 seconds, and if a
> > > reconnection happens each 5 seconds, it gets very very annoying, and
> > > almost unusable.
> >
> > I am testing your patches and so far so good. Seems to be working
> > perfectly fine. I see this in the logs:
> >
> > [41027.333419] wlan0: detected beacon loss from AP - sending probe request
> > [41027.389260] wlan0: cancelling probereq poll due to a received beacon
> > [41027.793518] No probe response from AP 00:1c:f0:62:88:5b after 500ms, try 1
> > [41028.292731] No probe response from AP 00:1c:f0:62:88:5b after 500ms, try 2
> >
> > Need to watch out if this pattern emerges and if the beacon loss trigger
> > might give us an indication. Maybe the ucode is just not ready then.
> Here (on my system) I see no beacon losses at all, like I said there
> could be many reasons behind packet losses, and best way to mitigate
> them is to retry.
>
> Your logs indicate that beacons weren't recieved for 2 seconds, then
> mac80211 tried to send a probe, but a beacon is recieved before the
> probe answer, this probe is canceled (at least should be) then after a
> while, a probe request (same one?) is time outed, and retried twice,
> then finally answered.
it looked related, but it wasn't at all. I have this running for over 24
hours by now and the patches work perfectly fine. Today it saw for the
first time a try 4 message. Otherwise it only had to try up to three
times before it succeeded.
Tested-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 4/4] ath5k: Use SWI to trigger calibration
From: Nick Kossifidis @ 2009-08-01 13:31 UTC (permalink / raw)
To: Bob Copeland
Cc: Luis R. Rodriguez, ath5k-devel, linux-wireless, linville,
jirislaby, nbd
In-Reply-To: <20090801132253.GB15971@hash.localnet>
2009/8/1 Bob Copeland <me@bobcopeland.com>:
> On Fri, Jul 31, 2009 at 10:52:42PM +0300, Nick Kossifidis wrote:
>> > make the above true it needs to stop the queues etc when doing
>> > calibration.
>>
>> ACK, how do we do that ?
>> ieee80211_stop_queues / ieee80211_wake_queues
>
> Yup. And disabling (at least rx and swba) interrupts on the device
> is also probably a good idea.
>
I thought about calling ath5k_hw_stop_rx_pcu but i don't think it's
necessary i mean it won't receive anyway, why mess with pcu ?
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 4/4] ath5k: Use SWI to trigger calibration
From: Bob Copeland @ 2009-08-01 13:22 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Luis R. Rodriguez, ath5k-devel, linux-wireless, linville,
jirislaby, nbd
In-Reply-To: <40f31dec0907311252n76adfde7kb9f34bf8c6baf34c@mail.gmail.com>
On Fri, Jul 31, 2009 at 10:52:42PM +0300, Nick Kossifidis wrote:
> > make the above true it needs to stop the queues etc when doing
> > calibration.
>
> ACK, how do we do that ?
> ieee80211_stop_queues / ieee80211_wake_queues
Yup. And disabling (at least rx and swba) interrupts on the device
is also probably a good idea.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [rt2800pci] Problems with (and without) rfkill
From: Ivo van Doorn @ 2009-08-01 12:30 UTC (permalink / raw)
To: Darren Salt; +Cc: linux-wireless
In-Reply-To: <5088EED148%linux@youmustbejoking.demon.co.uk>
Hi,
> diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x
> index 8a22e65..f934325 100644
> --- a/drivers/net/wireless/rt2x00/rt2800pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2800pci.c
> @@ -380,7 +380,12 @@ static int rt2800pci_rfkill_poll(struct rt2x00_dev *rt2x00d
> u32 reg;
>
> rt2x00pci_register_read(rt2x00dev, GPIO_CTRL_CFG, ®);
> - return rt2x00_get_field32(reg, GPIO_CTRL_CFG_BIT2);
> + /*return rt2x00_get_field32(reg, GPIO_CTRL_CFG_BIT2);*/
> + if (rt2x00_get_field32(reg, GPIO_CTRL_CFG_BIT2)) {
> + rt2x00_set_field32(®, GPIO_CTRL_CFG_BIT2, 0);
> + rt2x00pci_register_write(rt2x00dev, GPIO_CTRL_CFG, reg);
> + }
> + return 0;
> }
Writing to the GPIO isn't the solution, the entire register is read-only, so
the chip will ignore it. The reason why the RFKILL bit is apparently set
while it shouldn't is that the device isn't initialized correctly and the
entire device isn't ready to handle anything at this time.
Ivo
^ permalink raw reply
* Re: rt2800usb: memory corruption?
From: Mike Galbraith @ 2009-08-01 10:55 UTC (permalink / raw)
To: linux-wireless; +Cc: LKML, John W. Linville
In-Reply-To: <1249104348.7146.60.camel@marge.simson.net>
On Sat, 2009-08-01 at 07:25 +0200, Mike Galbraith wrote:
> [ 1529.736962] rt2800usb 7-5:1.0: firmware: requesting rt2870.bin
> [ 1529.812574] input: rt2800usb as /devices/pci0000:00/0000:00:1a.7/usb7/7-5/7-5:1.0/input/input6
> [ 1530.011246] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 1532.575208] wlan0: authenticate with AP 00:1a:4f:9a:d0:12
> [ 1532.589467] wlan0: authenticated
> [ 1532.599358] wlan0: associate with AP 00:1a:4f:9a:d0:12
> [ 1532.616210] wlan0: RX AssocResp from 00:1a:4f:9a:d0:12 (capab=0x411 status=0 aid=1)
> [ 1532.629818] wlan0: associated
> [ 1532.647010] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 1534.905025] device wlan0 entered promiscuous mode
> [ 1535.202677] martian source 255.255.255.255 from 192.168.178.1, on dev wlan0
> [ 1535.206611] ll header: ff:ff:ff:ff:ff:ff:00:1a:4f:7b:e8:48:08:00
> [ 1535.298916] martian source 255.255.255.255 from 192.168.178.1, on dev wlan0
> [ 1535.306059] ll header: ff:ff:ff:ff:ff:ff:00:1a:4f:7b:e8:48:08:00
> [ 1536.512420] ------------[ cut here ]------------
> [ 1536.516065] kernel BUG at mm/slub.c:2929!
> [ 1536.516065] invalid opcode: 0000 [#1] SMP
> [ 1536.516065] last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
> [ 1536.516065] CPU 0
> [ 1536.516065] Modules linked in: rt2800usb xt_tcpudp xt_pkttype xt_limit snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs 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 nf_conntrack nf_defrag_ipv4 ip_tables cpufreq_conservative ip6table_filter cpufreq_ondemand ip6_tables cpufreq_userspace x_tables cpufreq_powersave acpi_cpufreq ipv6 microcode fuse loop dm_mod snd_hda_codec_realtek arc4 ecb snd_hda_intel snd_hda_codec rt2x00usb rt2x00lib firewire_ohci snd_hwdep snd_pcm led_class firewire_core snd_timer input_polldev crc_itu_t mac80211 snd ohci1394 usb_storage usbhid soundcore sr_mod rtc_cmos usb_libusual i2c_i801 cfg80211 snd_page_alloc rtc_core hid e1000e thermal processor ieee1394 i2c_core cdrom crc_ccitt intel_agp rtc_lib button sg uhci_hcd ehci_hcd sd_mod usbcore edd fan ext3 mbcache jbd ahci libata scsi_mod [last unloaded: rt2800usb]
> [ 1536.516065] Pid: 6982, comm: gam_server Not tainted 2.6.31-smp #1001 MS-7502
> [ 1536.516065] RIP: 0010:[<ffffffff810b7306>] [<ffffffff810b7306>] kfree+0x82/0x187
> [ 1536.516065] RSP: 0018:ffff8800ad1b5df8 EFLAGS: 00010246
> [ 1536.516065] RAX: 4000000000000000 RBX: ffff88009d7113a8 RCX: 0000000000000000
> [ 1536.516065] RDX: ffffea0000000000 RSI: ffffffff814b39f2 RDI: ffff88001818500b
> [ 1536.516065] RBP: ffff8800ad1b5e28 R08: 0000000000000000 R09: ffff8800ad1b5e48
> [ 1536.516065] R10: ffff8800ad1b5e48 R11: 0000000000000246 R12: ffffea0000545518
> [ 1536.516065] R13: 0000000000000010 R14: ffff88001818500b R15: 0000000001eeb460
> [ 1536.516065] FS: 00007f08d83726f0(0000) GS:ffff8800014e1000(0000) knlGS:0000000000000000
> [ 1536.516065] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1536.516065] CR2: 00007f05b5c4e048 CR3: 00000000ad1a8000 CR4: 00000000000006f0
> [ 1536.516065] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1536.516065] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 1536.516065] Process gam_server (pid: 6982, threadinfo ffff8800ad1b4000, task ffff8800be290cc0)
> [ 1536.516065] Stack:
> [ 1536.516065] ffff8800ad1b5e38 ffff88009d7113a8 ffff88009d7113a8 0000000000000010
> [ 1536.516065] <0> 0000000000000002 0000000001eeb460 ffff8800ad1b5e48 ffffffff810e3b4c
> [ 1536.516065] <0> ffff8800ad1b5e48 0000000000000020 ffff8800ad1b5f08 ffffffff810e5e3b
> [ 1536.516065] Call Trace:
> [ 1536.516065] [<ffffffff810e3b4c>] fsnotify_put_event+0x45/0x58
> [ 1536.891064] [<ffffffff810e5e3b>] inotify_read+0x1f0/0x282
> [ 1536.891064] [<ffffffff81050bba>] ? autoremove_wake_function+0x0/0x38
> [ 1536.891064] [<ffffffff810bc2ac>] vfs_read+0xab/0x167
> [ 1536.891064] [<ffffffff810bc42c>] sys_read+0x47/0x6f
> [ 1536.891064] [<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
> [ 1536.891064] Code: 00 ea ff ff 48 c1 e8 0c 48 6b c0 38 4c 8d 24 10 66 41 83 3c 24 00 79 05 4d 8b 64 24 10 49 8b 04 24 84 c0 78 17 66 a9 00 c0 75 04 <0f> 0b eb fe 4c 89 e7 e8 98 44 fe ff e9 e8 00 00 00 4d 8b 6c 24
> [ 1536.891064] RIP [<ffffffff810b7306>] kfree+0x82/0x187
> [ 1536.891064] RSP <ffff8800ad1b5df8>
> [ 1537.069331] ---[ end trace 432a664becb6485b ]---
> [ 1543.056005] wlan0: no IPv6 routers present
Enabled slub/pagealloc debugging. First down/rmmod said...
[ 129.028042] wlan0: deauthenticating by local choice (reason=3)
[ 140.015920] usbcore: deregistering interface driver rt2800usb
[ 140.132315] =============================================================================
[ 140.136190] BUG kmalloc-16: Redzone overwritten
[ 140.136190] -----------------------------------------------------------------------------
[ 140.136190]
[ 140.136190] INFO: 0xffff8800bcdfa538-0xffff8800bcdfa53b. First byte 0xb instead of 0xcc
[ 140.195773] INFO: Allocated in rt2x00usb_probe+0x127/0x1ad [rt2x00usb] age=31743 cpu=0 pid=1482
[ 140.195773] INFO: Slab 0xffffea0002950eb0 objects=46 used=29 fp=0xffff8800bcdfa790 flags=0x4000000000000083
[ 140.195773] INFO: Object 0xffff8800bcdfa528 @offset=1320 fp=0xffff8800bcdfa580
[ 140.195773]
[ 140.195773] Bytes b4 0xffff8800bcdfa518: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
[ 140.260506] Object 0xffff8800bcdfa528: 00 00 00 00 cc 2e 40 18 c6 47 4c 18 51 92 16 18 ....Ì.@.ÆGL.Q...
[ 140.260506] Redzone 0xffff8800bcdfa538: 0b 50 18 18 cc cc cc cc .P..ÌÌÌÌ
[ 140.260506] Padding 0xffff8800bcdfa578: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
[ 140.260506] Pid: 7812, comm: rmmod Not tainted 2.6.31-smp #1002
[ 140.260506] Call Trace:
[ 140.260506] [<ffffffff810b820a>] print_trailer+0x13b/0x144
[ 140.260506] [<ffffffff810b871a>] check_bytes_and_report+0xb2/0xf2
[ 140.260506] [<ffffffffa0305080>] ? rt2x00usb_free_reg+0x18/0x55 [rt2x00usb]
[ 140.260506] [<ffffffff810b87b6>] check_object+0x5c/0x207
[ 140.260506] [<ffffffff810b9037>] __slab_free+0x193/0x2bf
[ 140.260506] [<ffffffffa0305080>] ? rt2x00usb_free_reg+0x18/0x55 [rt2x00usb]
[ 140.260506] [<ffffffff810ba49d>] kfree+0xcf/0xd9
[ 140.260506] [<ffffffffa0305080>] rt2x00usb_free_reg+0x18/0x55 [rt2x00usb]
[ 140.260506] [<ffffffffa03050e8>] rt2x00usb_disconnect+0x2b/0x58 [rt2x00usb]
[ 140.260506] [<ffffffffa00c88b4>] usb_unbind_interface+0x5d/0xed [usbcore]
[ 140.260506] [<ffffffff811c6914>] __device_release_driver+0x7a/0xc0
[ 140.260506] [<ffffffff811c69d5>] driver_detach+0x7b/0xa1
[ 140.260506] [<ffffffff811c5c80>] bus_remove_driver+0x86/0xb6
[ 140.260506] [<ffffffff811c6ed4>] driver_unregister+0x66/0x6e
[ 140.260506] [<ffffffffa00c86c9>] usb_deregister+0x98/0xa6 [usbcore]
[ 140.260506] [<ffffffffa030fbe4>] rt2800usb_exit+0x10/0x12 [rt2800usb]
[ 140.260506] [<ffffffff8106248f>] sys_delete_module+0x1cf/0x243
[ 140.260506] [<ffffffff81020062>] ? __assign_irq_vector+0xf8/0x1bd
[ 140.260506] [<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
[ 140.260506] FIX kmalloc-16: Restoring 0xffff8800bcdfa538-0xffff8800bcdfa53b=0xcc
^ permalink raw reply
* Re: [PATCH] Fix SPARC64 unaligned access in zd_mac_rx
From: Michael Buesch @ 2009-08-01 10:40 UTC (permalink / raw)
To: David Miller; +Cc: johannes, linuxrocks123, linux-wireless, dsd, kune
In-Reply-To: <20090731.222350.254918321.davem@davemloft.net>
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.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] compat-2.6: Makefile: fixed test expressions for target install
From: Joerg Albert @ 2009-08-01 10:39 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Pavel Roskin, linux-wireless@vger.kernel.org
In-Reply-To: <43e72e890907311622u1059be72y7c833f888b11cf56@mail.gmail.com>
On 08/01/2009 01:22 AM, Luis R. Rodriguez wrote:
> Actually please do keep relying on /bin/bash, all the scripts on
> compat-wireless do depend on /bin/bash, I don't expect users of
> dash/etc to use compat-wireless.
>
> If we want to make compat-wireless be shell agnostic we'd need to
> address all the other scripts. I rather not deal with that now unless
> we really think that is also a good idea and someone is up for the
> task.
IMHO we could make bug fixes to the Makefile/scripts shell agnostic if it's not much effort and
doesn't break readability, which is neither the case here.
Regards,
Joerg.
^ permalink raw reply
* Re: zd1211rw with MIPS architecture: mysterious behavior with zd1211b and AL2230/AL2230S RF Chip
From: Mladen Horvat @ 2009-08-01 9:41 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4A733FF1.7050301@gmx.de>
Joerg Albert <jal2@...> writes:
>
> On 07/31/2009 03:11 PM, Mladen Horvat wrote:
>
> > the same stick runs flawless on a x86 pc with kernel 2.6.30.
> > as i said, also on the same machine with kernel 2.6.12 and the vendor driver
> > this stick works without problems.
> >
> > perhaps someone has an idea ?
>
> Just a wild guess, if your target runs MIPS in big endian: a missing endian
conversion in the zd1211rw driver?
> Wasn't USB little-endian based?
CONFIG_CPU_LITTLE_ENDIAN=y , so this should not be the problem i think
> If the stick runs on the same MIPS target with 2.6.12 and vendor driver, it
shouldn't be a USB 1.1 vs. 2.0
> problem - I guess the stick is a high speed device, as the zd1211b supports
802.11g.
if i remember the vendor driver correctly it uses 11g if usb2.0 is used and
switches automatically to 11b mode for usb1.1
perhaps its some sort of timing issue ?
regards
Mladen
^ permalink raw reply
* [PATCH 10/10] drivers/net/wireless: introduce missing kfree
From: Julia Lawall @ 2009-08-01 8:55 UTC (permalink / raw)
To: linville, linux-wireless, netdev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Error handling code following a kzalloc should free the allocated data.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
(
x->f1 = E
|
(x->f1 == NULL || ...)
|
f(...,x->f1,...)
)
...>
(
return \(0\|<+...x...+>\|ptr\);
|
return@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/iwmc3200wifi/commands.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/commands.c b/drivers/net/wireless/iwmc3200wifi/commands.c
index 0d66370..2bf9ef9 100644
--- a/drivers/net/wireless/iwmc3200wifi/commands.c
+++ b/drivers/net/wireless/iwmc3200wifi/commands.c
@@ -233,6 +233,7 @@ int iwm_store_rxiq_calib_result(struct iwm_priv *iwm)
eeprom_rxiq = iwm_eeprom_access(iwm, IWM_EEPROM_CALIB_RXIQ);
if (IS_ERR(eeprom_rxiq)) {
IWM_ERR(iwm, "Couldn't access EEPROM RX IQ entry\n");
+ kfree(rxiq);
return PTR_ERR(eeprom_rxiq);
}
^ permalink raw reply related
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