* [PATCH 1/1] drivers:net:wireless return -ENOMEM if kzalloc fails
From: Jing Wang @ 2013-10-24 8:14 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: Jing Wang
From: Jing Wang <windsdaemon@gmail.com>
the original code used goto out if kzalloc fails,but the out include kfree,
so return -ENOMEME if kzalloc fails.
Signed-off-by: Jing Wang <windsdaemon@gmail.com>
---
drivers/net/wireless/ti/wl1251/acx.c | 207 +++++++++++-----------------------
1 files changed, 68 insertions(+), 139 deletions(-)
diff --git a/drivers/net/wireless/ti/wl1251/acx.c b/drivers/net/wireless/ti/wl1251/acx.c
index db6430c..bb0edc9 100644
--- a/drivers/net/wireless/ti/wl1251/acx.c
+++ b/drivers/net/wireless/ti/wl1251/acx.c
@@ -18,10 +18,8 @@ int wl1251_acx_frame_rates(struct wl1251 *wl, u8 ctrl_rate, u8 ctrl_mod,
wl1251_debug(DEBUG_ACX, "acx frame rates");
rates = kzalloc(sizeof(*rates), GFP_KERNEL);
- if (!rates) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!rates)
+ return -ENOMEM;
rates->tx_ctrl_frame_rate = ctrl_rate;
rates->tx_ctrl_frame_mod = ctrl_mod;
@@ -49,10 +47,8 @@ int wl1251_acx_station_id(struct wl1251 *wl)
wl1251_debug(DEBUG_ACX, "acx dot11_station_id");
mac = kzalloc(sizeof(*mac), GFP_KERNEL);
- if (!mac) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!mac)
+ return -ENOMEM;
for (i = 0; i < ETH_ALEN; i++)
mac->mac[i] = wl->mac_addr[ETH_ALEN - 1 - i];
@@ -74,10 +70,8 @@ int wl1251_acx_default_key(struct wl1251 *wl, u8 key_id)
wl1251_debug(DEBUG_ACX, "acx dot11_default_key (%d)", key_id);
default_key = kzalloc(sizeof(*default_key), GFP_KERNEL);
- if (!default_key) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!default_key)
+ return -ENOMEM;
default_key->id = key_id;
@@ -104,10 +98,8 @@ int wl1251_acx_wake_up_conditions(struct wl1251 *wl, u8 wake_up_event,
wl1251_debug(DEBUG_ACX, "acx wake up conditions");
wake_up = kzalloc(sizeof(*wake_up), GFP_KERNEL);
- if (!wake_up) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!wake_up)
+ return -ENOMEM;
wake_up->wake_up_event = wake_up_event;
wake_up->listen_interval = listen_interval;
@@ -132,10 +124,8 @@ int wl1251_acx_sleep_auth(struct wl1251 *wl, u8 sleep_auth)
wl1251_debug(DEBUG_ACX, "acx sleep auth");
auth = kzalloc(sizeof(*auth), GFP_KERNEL);
- if (!auth) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!auth)
+ return -ENOMEM;
auth->sleep_auth = sleep_auth;
@@ -154,10 +144,8 @@ int wl1251_acx_fw_version(struct wl1251 *wl, char *buf, size_t len)
wl1251_debug(DEBUG_ACX, "acx fw rev");
rev = kzalloc(sizeof(*rev), GFP_KERNEL);
- if (!rev) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!rev)
+ return -ENOMEM;
ret = wl1251_cmd_interrogate(wl, ACX_FW_REV, rev, sizeof(*rev));
if (ret < 0) {
@@ -191,10 +179,8 @@ int wl1251_acx_tx_power(struct wl1251 *wl, int power)
return -EINVAL;
acx = kzalloc(sizeof(*acx), GFP_KERNEL);
- if (!acx) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!acx)
+ return -ENOMEM;
acx->current_tx_power = power * 10;
@@ -217,10 +203,8 @@ int wl1251_acx_feature_cfg(struct wl1251 *wl)
wl1251_debug(DEBUG_ACX, "acx feature cfg");
feature = kzalloc(sizeof(*feature), GFP_KERNEL);
- if (!feature) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!feature)
+ return -ENOMEM;
/* DF_ENCRYPTION_DISABLE and DF_SNIFF_MODE_ENABLE are disabled */
feature->data_flow_options = 0;
@@ -261,10 +245,8 @@ int wl1251_acx_data_path_params(struct wl1251 *wl,
wl1251_debug(DEBUG_ACX, "acx data path params");
params = kzalloc(sizeof(*params), GFP_KERNEL);
- if (!params) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!params)
+ return -ENOMEM;
params->rx_packet_ring_chunk_size = DP_RX_PACKET_RING_CHUNK_SIZE;
params->tx_packet_ring_chunk_size = DP_TX_PACKET_RING_CHUNK_SIZE;
@@ -309,10 +291,8 @@ int wl1251_acx_rx_msdu_life_time(struct wl1251 *wl, u32 life_time)
wl1251_debug(DEBUG_ACX, "acx rx msdu life time");
acx = kzalloc(sizeof(*acx), GFP_KERNEL);
- if (!acx) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!acx)
+ return -ENOMEM;
acx->lifetime = life_time;
ret = wl1251_cmd_configure(wl, DOT11_RX_MSDU_LIFE_TIME,
@@ -335,10 +315,8 @@ int wl1251_acx_rx_config(struct wl1251 *wl, u32 config, u32 filter)
wl1251_debug(DEBUG_ACX, "acx rx config");
rx_config = kzalloc(sizeof(*rx_config), GFP_KERNEL);
- if (!rx_config) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!rx_config)
+ return -ENOMEM;
rx_config->config_options = config;
rx_config->filter_options = filter;
@@ -363,10 +341,8 @@ int wl1251_acx_pd_threshold(struct wl1251 *wl)
wl1251_debug(DEBUG_ACX, "acx data pd threshold");
pd = kzalloc(sizeof(*pd), GFP_KERNEL);
- if (!pd) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!pd)
+ return -ENOMEM;
/* FIXME: threshold value not set */
@@ -389,10 +365,8 @@ int wl1251_acx_slot(struct wl1251 *wl, enum acx_slot_type slot_time)
wl1251_debug(DEBUG_ACX, "acx slot");
slot = kzalloc(sizeof(*slot), GFP_KERNEL);
- if (!slot) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!slot)
+ return -ENOMEM;
slot->wone_index = STATION_WONE_INDEX;
slot->slot_time = slot_time;
@@ -416,10 +390,8 @@ int wl1251_acx_group_address_tbl(struct wl1251 *wl)
wl1251_debug(DEBUG_ACX, "acx group address tbl");
acx = kzalloc(sizeof(*acx), GFP_KERNEL);
- if (!acx) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!acx)
+ return -ENOMEM;
/* MAC filtering */
acx->enabled = 0;
@@ -444,10 +416,8 @@ int wl1251_acx_service_period_timeout(struct wl1251 *wl)
int ret;
rx_timeout = kzalloc(sizeof(*rx_timeout), GFP_KERNEL);
- if (!rx_timeout) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!rx_timeout)
+ return -ENOMEM;
wl1251_debug(DEBUG_ACX, "acx service period timeout");
@@ -475,10 +445,8 @@ int wl1251_acx_rts_threshold(struct wl1251 *wl, u16 rts_threshold)
wl1251_debug(DEBUG_ACX, "acx rts threshold");
rts = kzalloc(sizeof(*rts), GFP_KERNEL);
- if (!rts) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!rts)
+ return -ENOMEM;
rts->threshold = rts_threshold;
@@ -501,10 +469,8 @@ int wl1251_acx_beacon_filter_opt(struct wl1251 *wl, bool enable_filter)
wl1251_debug(DEBUG_ACX, "acx beacon filter opt");
beacon_filter = kzalloc(sizeof(*beacon_filter), GFP_KERNEL);
- if (!beacon_filter) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!beacon_filter)
+ return -ENOMEM;
beacon_filter->enable = enable_filter;
beacon_filter->max_num_beacons = 0;
@@ -530,10 +496,8 @@ int wl1251_acx_beacon_filter_table(struct wl1251 *wl)
wl1251_debug(DEBUG_ACX, "acx beacon filter table");
ie_table = kzalloc(sizeof(*ie_table), GFP_KERNEL);
- if (!ie_table) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!ie_table)
+ return -ENOMEM;
/* configure default beacon pass-through rules */
ie_table->num_ie = 1;
@@ -560,10 +524,8 @@ int wl1251_acx_conn_monit_params(struct wl1251 *wl)
wl1251_debug(DEBUG_ACX, "acx connection monitor parameters");
acx = kzalloc(sizeof(*acx), GFP_KERNEL);
- if (!acx) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!acx)
+ return -ENOMEM;
acx->synch_fail_thold = SYNCH_FAIL_DEFAULT_THRESHOLD;
acx->bss_lose_timeout = NO_BEACON_DEFAULT_TIMEOUT;
@@ -589,10 +551,8 @@ int wl1251_acx_sg_enable(struct wl1251 *wl)
wl1251_debug(DEBUG_ACX, "acx sg enable");
pta = kzalloc(sizeof(*pta), GFP_KERNEL);
- if (!pta) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!pta)
+ return -ENOMEM;
pta->enable = SG_ENABLE;
@@ -615,10 +575,8 @@ int wl1251_acx_sg_cfg(struct wl1251 *wl)
wl1251_debug(DEBUG_ACX, "acx sg cfg");
param = kzalloc(sizeof(*param), GFP_KERNEL);
- if (!param) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!param)
+ return -ENOMEM;
/* BT-WLAN coext parameters */
param->min_rate = RATE_INDEX_24MBPS;
@@ -669,10 +627,8 @@ int wl1251_acx_cca_threshold(struct wl1251 *wl)
wl1251_debug(DEBUG_ACX, "acx cca threshold");
detection = kzalloc(sizeof(*detection), GFP_KERNEL);
- if (!detection) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!detection)
+ return -ENOMEM;
detection->rx_cca_threshold = CCA_THRSH_DISABLE_ENERGY_D;
detection->tx_energy_detection = 0;
@@ -695,10 +651,8 @@ int wl1251_acx_bcn_dtim_options(struct wl1251 *wl)
wl1251_debug(DEBUG_ACX, "acx bcn dtim options");
bb = kzalloc(sizeof(*bb), GFP_KERNEL);
- if (!bb) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!bb)
+ return -ENOMEM;
bb->beacon_rx_timeout = BCN_RX_TIMEOUT_DEF_VALUE;
bb->broadcast_timeout = BROADCAST_RX_TIMEOUT_DEF_VALUE;
@@ -724,10 +678,8 @@ int wl1251_acx_aid(struct wl1251 *wl, u16 aid)
wl1251_debug(DEBUG_ACX, "acx aid");
acx_aid = kzalloc(sizeof(*acx_aid), GFP_KERNEL);
- if (!acx_aid) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!acx_aid)
+ return -ENOMEM;
acx_aid->aid = aid;
@@ -750,10 +702,8 @@ int wl1251_acx_event_mbox_mask(struct wl1251 *wl, u32 event_mask)
wl1251_debug(DEBUG_ACX, "acx event mbox mask");
mask = kzalloc(sizeof(*mask), GFP_KERNEL);
- if (!mask) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!mask)
+ return -ENOMEM;
/* high event mask is unused */
mask->high_event_mask = 0xffffffff;
@@ -805,10 +755,8 @@ int wl1251_acx_set_preamble(struct wl1251 *wl, enum acx_preamble_type preamble)
wl1251_debug(DEBUG_ACX, "acx_set_preamble");
acx = kzalloc(sizeof(*acx), GFP_KERNEL);
- if (!acx) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!acx)
+ return -ENOMEM;
acx->preamble = preamble;
@@ -832,10 +780,8 @@ int wl1251_acx_cts_protect(struct wl1251 *wl,
wl1251_debug(DEBUG_ACX, "acx_set_ctsprotect");
acx = kzalloc(sizeof(*acx), GFP_KERNEL);
- if (!acx) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!acx)
+ return -ENOMEM;
acx->ctsprotect = ctsprotect;
@@ -856,10 +802,8 @@ int wl1251_acx_tsf_info(struct wl1251 *wl, u64 *mactime)
int ret;
tsf_info = kzalloc(sizeof(*tsf_info), GFP_KERNEL);
- if (!tsf_info) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!tsf_info)
+ return -ENOMEM;
ret = wl1251_cmd_interrogate(wl, ACX_TSF_INFO,
tsf_info, sizeof(*tsf_info));
@@ -900,11 +844,8 @@ int wl1251_acx_rate_policies(struct wl1251 *wl)
wl1251_debug(DEBUG_ACX, "acx rate policies");
acx = kzalloc(sizeof(*acx), GFP_KERNEL);
-
- if (!acx) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!acx)
+ return -ENOMEM;
/* configure one default (one-size-fits-all) rate class */
acx->rate_class_cnt = 1;
@@ -932,10 +873,8 @@ int wl1251_acx_mem_cfg(struct wl1251 *wl)
wl1251_debug(DEBUG_ACX, "acx mem cfg");
mem_conf = kzalloc(sizeof(*mem_conf), GFP_KERNEL);
- if (!mem_conf) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!mem_conf)
+ return -ENOMEM;
/* memory config */
mem_conf->mem_config.num_stations = cpu_to_le16(DEFAULT_NUM_STATIONS);
@@ -979,10 +918,8 @@ int wl1251_acx_wr_tbtt_and_dtim(struct wl1251 *wl, u16 tbtt, u8 dtim)
wl1251_debug(DEBUG_ACX, "acx tbtt and dtim");
acx = kzalloc(sizeof(*acx), GFP_KERNEL);
- if (!acx) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!acx)
+ return -ENOMEM;
acx->tbtt = tbtt;
acx->dtim = dtim;
@@ -1008,10 +945,8 @@ int wl1251_acx_bet_enable(struct wl1251 *wl, enum wl1251_acx_bet_mode mode,
wl1251_debug(DEBUG_ACX, "acx bet enable");
acx = kzalloc(sizeof(*acx), GFP_KERNEL);
- if (!acx) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!acx)
+ return -ENOMEM;
acx->enable = mode;
acx->max_consecutive = max_consecutive;
@@ -1037,11 +972,8 @@ int wl1251_acx_ac_cfg(struct wl1251 *wl, u8 ac, u8 cw_min, u16 cw_max,
"aifs %d txop %d", ac, cw_min, cw_max, aifs, txop);
acx = kzalloc(sizeof(*acx), GFP_KERNEL);
-
- if (!acx) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!acx)
+ return -ENOMEM;
acx->ac = ac;
acx->cw_min = cw_min;
@@ -1073,11 +1005,8 @@ int wl1251_acx_tid_cfg(struct wl1251 *wl, u8 queue,
ps_scheme, ack_policy);
acx = kzalloc(sizeof(*acx), GFP_KERNEL);
-
- if (!acx) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!acx)
+ return -ENOMEM;
acx->queue = queue;
acx->type = type;
--
1.7.1
^ permalink raw reply related
* Corega WLUSB2GTST USB adapter + p54usb driver
From: Andrey @ 2013-10-24 9:40 UTC (permalink / raw)
To: linux-wireless
This post is for people, who tried to launch Corega WLUSB2GTST USB adapter
without success. In order to get it working you should recompile p54usb.c
module with adding to source code product vendor id 07aa:0020.
Then just do modprobe prism54usb, and you'll get something like this
[ 1239.859554] usb 1-2: new full-speed USB device number 4 using ohci_hcd
[ 1240.364465] usb 1-2: New USB device found, idVendor=07aa, idProduct=0020
[ 1240.365459] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1241.157609] cfg80211: Calling CRDA to update world regulatory domain
[ 1241.636004] cfg80211: World regulatory domain updated:
[ 1241.638846] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 1241.639005] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 1241.639011] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300
mBi, 2000 mBm)
[ 1241.639562] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300
mBi, 2000 mBm)
[ 1241.639724] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 1241.639730] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 1241.984610] usb 1-2: reset full-speed USB device number 4 using ohci_hcd
[ 1242.669750] usb 1-2: firmware: agent loaded isl3887usb into memory
[ 1242.669818] ieee80211 phy0: p54 detected a LM87 firmware
[ 1242.669822] p54: rx_mtu reduced from 3240 to 2384
[ 1242.669827] ieee80211 phy0: FW rev 2.13.25.0 - Softmac protocol 5.9
[ 1242.669832] ieee80211 phy0: cryptographic accelerator WEP:YES, TKIP:YES,
CCMP:YES
[ 1243.920119] ieee80211 phy0: hwaddr 00:0a:79:6a:90:87, MAC:isl3887 RF:Frisbee
[ 1244.201927] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 1244.204008] Registered led device: p54-phy0::assoc
[ 1244.206429] Registered led device: p54-phy0::tx
[ 1244.206535] Registered led device: p54-phy0::rx
[ 1244.206855] Registered led device: p54-phy0::radio
[ 1244.207523] usb 1-2: is registered as 'phy0'
^ permalink raw reply
* Re: Edimax EW-7733UnD
From: Stanislaw Gruszka @ 2013-10-24 11:22 UTC (permalink / raw)
To: Gianfranco Costamagna; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1382538469.7892.YahooMailNeo@web171805.mail.ir2.yahoo.com>
On Wed, Oct 23, 2013 at 03:27:49PM +0100, Gianfranco Costamagna wrote:
> Hi Kernel Wireless developers, I write here since I have an issue with this module.
>
>
> We bought 2 of them since they are both 2.4 and 5Ghz capable, and they seem to be powerful enough for our pourposes
> http://www.edimax.com/au/produce_detail.php?pd_id=399&pl1_id=1&pl2_id=44
>
>
> Anyway there is a problem, that the linux kernel seems to be not supporting them
>
> I tried following this guide
> http://wikidevi.com/wiki/Edimax_EW-7733UnD
> rt3573sta, possibly rt5572sta, and future support in rt2800usb "uhosg's patchset adding support, may be in by k3.12"
> but at this moment it is showing an interface with one of them (I cannot connect to anything, the interface shown seems to be incorrect), with another I get a kernel anic and with the third one doesn't work at all.
>
> lsusb |grep Edimax
>
> Bus 002 Device 002: ID 7392:7733 Edimax Technology Co., Ltd
I have that exect device and it works ok here, but I'm using
wireless-testing tree. So perhaps you should try install that
tree or use backports .
Stanislaw
^ permalink raw reply
* Re: iwl3945 filling kern.log when HW switch is off
From: Stanislaw Gruszka @ 2013-10-24 11:27 UTC (permalink / raw)
To: Dietmar Rudolph; +Cc: linux-wireless
In-Reply-To: <526795E1.90701@crlf.de>
On Wed, Oct 23, 2013 at 11:24:49AM +0200, Dietmar Rudolph wrote:
> Hello, I hope this is the correct place to put a bug report in. I do
> not subscribe to this mailing list, but feel free to send PM in case
> you need additional info. You shoudn't :-)
>
> After installing Ubuntu 13.10, I noticed kern.log growing faster
> than you could look at. Within a few working hours, kern.log was
> >6GB!
>
> The reason is that I intentionally disabled WiFi on this laptop by
> turning the HW switch off. However, this makes iwl3945 write a log
> entry into kern.log every few microseconds!
>
> The workaround is to turn the HW switch on. The bug fix would be to
> write just a single line to kern.log.
This message is printed when someone try to UP device when RF kill
switch is on. Either you did not compile kernel with CONFIG_RFKILL or
your user space network management software does not handle rfkill .
Stanislaw
^ permalink raw reply
* Re: Edimax EW-7733UnD
From: Gianfranco Costamagna @ 2013-10-24 11:32 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20131024112206.GB1677@redhat.com>
Il Giovedì 24 Ottobre 2013 13:25, Stanislaw Gruszka <sgruszka@redhat.com> ha scritto:
On Wed, Oct 23, 2013 at 03:27:49PM +0100, Gianfranco Costamagna wrote:
>
>> Hi Kernel Wireless developers, I write here since I have an issue with this module.
>>
>>
>> We bought 2 of them since they are both 2.4 and 5Ghz capable, and they seem to be powerful enough for our pourposes
>> http://www.edimax.com/au/produce_detail.php?pd_id=399&pl1_id=1&pl2_id=44
>>
>>
>> Anyway there is a problem, that the linux kernel seems to be not supporting them
>>
>> I tried following this guide
>> http://wikidevi.com/wiki/Edimax_EW-7733UnD
>> rt3573sta, possibly rt5572sta, and future support in rt2800usb "uhosg's patchset adding support, may be in by k3.12"
>> but at this moment it is showing an interface with one of them (I cannot connect to anything, the interface shown seems to be incorrect), with another I get a kernel anic and with the third one doesn't work at all.
>>
>> lsusb |grep Edimax
>>
>> Bus 002 Device 002: ID 7392:7733 Edimax Technology Co., Ltd
>
>I have that exect device and it works ok here, but I'm using
>wireless-testing tree. So perhaps you should try install that
>tree or use backports .
Wonderful! I don't really understand what do you mean with backports, are you referring to "linux kernel backports" right?
So I can choose the backport source or to checkout and build the wireless-testing tree.
Just as information, how long will it take to have it into the stable mainline?
How does the merge works?
(just because I don't want to build a custom kernel if not really needed I use the rc kernels packaged by ubuntu team
http://kernel.ubuntu.com/~kernel-ppa/mainline/ )
many thanks
Gianfranco
>
>Stanislaw
>
>
>
>
^ permalink raw reply
* Re: Edimax EW-7733UnD
From: Stanislaw Gruszka @ 2013-10-24 11:37 UTC (permalink / raw)
To: Gianfranco Costamagna; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1382614336.89589.YahooMailNeo@web171804.mail.ir2.yahoo.com>
On Thu, Oct 24, 2013 at 12:32:16PM +0100, Gianfranco Costamagna wrote:
>
>
> Il Giovedì 24 Ottobre 2013 13:25, Stanislaw Gruszka <sgruszka@redhat.com> ha scritto:
>
> On Wed, Oct 23, 2013 at 03:27:49PM +0100, Gianfranco Costamagna wrote:
> >
> >> Hi Kernel Wireless developers, I write here since I have an issue with this module.
> >>
> >>
> >> We bought 2 of them since they are both 2.4 and 5Ghz capable, and they seem to be powerful enough for our pourposes
> >> http://www.edimax.com/au/produce_detail.php?pd_id=399&pl1_id=1&pl2_id=44
> >>
> >>
> >> Anyway there is a problem, that the linux kernel seems to be not supporting them
> >>
> >> I tried following this guide
> >> http://wikidevi.com/wiki/Edimax_EW-7733UnD
> >> rt3573sta, possibly rt5572sta, and future support in rt2800usb "uhosg's patchset adding support, may be in by k3.12"
> >> but at this moment it is showing an interface with one of them (I cannot connect to anything, the interface shown seems to be incorrect), with another I get a kernel anic and with the third one doesn't work at all.
> >>
> >> lsusb |grep Edimax
> >>
> >> Bus 002 Device 002: ID 7392:7733 Edimax Technology Co., Ltd
> >
> >I have that exect device and it works ok here, but I'm using
> >wireless-testing tree. So perhaps you should try install that
> >tree or use backports .
>
>
> Wonderful! I don't really understand what do you mean with backports, are you referring to "linux kernel backports" right?
Yes.
> So I can choose the backport source or to checkout and build the wireless-testing tree.
>
> Just as information, how long will it take to have it into the stable mainline?
Current wireless-testing content will be available on 3.13 ,
though I think that device should also work on 3.12 .
Stanislaw
^ permalink raw reply
* Re: ar5523 Gigaset USB Adapter 108 issue
From: Yannik Völker @ 2013-10-24 12:46 UTC (permalink / raw)
To: Oleksij Rempel, linux-wireless@vger.kernel.org, pontus.fuchs
In-Reply-To: <5266C7BF.20503@rempel-privat.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 22.10.2013 20:45, schrieb Oleksij Rempel:> Am 22.10.2013 20:32,
schrieb Yannik Völker:
>> Am 19.10.2013 18:59, schrieb Oleksij Rempel:
>>> Am 19.10.2013 14:18, schrieb Yannik Völker:
>>>> Am 18.10.2013 19:16, schrieb Oleksij Rempel:
>>>>> Am 18.10.2013 18:33, schrieb Yannik Völker:
>>>>>> Am 18.10.2013 18:16, schrieb Oleksij Rempel:
>>>>>>> Am 18.10.2013 17:38, schrieb Yannik Völker:
>>>>>>>> Am 18.10.2013 17:07, schrieb Oleksij Rempel:
>>>>>>>>> Am 18.10.2013 16:49, schrieb Alan Stern:
>>>>>>>>>> Yannik, you should always use Reply-To-All so
>>>>>>>>>> that your messages get sent to the mailing list
>>>>>>>>>> and not just to me.
>>>>>>>>>>
>>>>>>>>>> On Thu, 17 Oct 2013, Yannik Völker wrote:
>>>>>>>>>>
>>>>>>>>>>> Am 07.08.2013 19:34, schrieb Alan Stern:
>>>>>>>>>>>> Please post two usbmon traces, one showing
>>>>>>>>>>>> the failure on your current system and the
>>>>>>>>>>>> other showing the adapter running correctly
>>>>>>>>>>>> under a 32-bit kernel. Instructions for
>>>>>>>>>>>> usbmon are in the kernel source file
>>>>>>>>>>>> Documentation/usb/usbmon.txt.
>>>>>>>>>>> I never got it to work under a 32-bit kernel,
>>>>>>>>>>> i was just able to utilize a windows32 driver
>>>>>>>>>>> using ndiswrapper.
>>>>>>>>>>>
>>>>>>>>>>> Now i got it to "work". I randomly found out
>>>>>>>>>>> that the ar5523 driver actually works when you
>>>>>>>>>>> load it after you unload ndiswrapper so the
>>>>>>>>>>> following steps make it work: 1. modprobe
>>>>>>>>>>> ndiswrapper 2. plug in device 3. connect to
>>>>>>>>>>> wlan using ndiswrapper and disconnect again
>>>>>>>>>>> (might be optional) 4. modprobe -r ndiswrapper
>>>>>>>>>>> 5. modprobe ar5523 6. connect to wlan log for
>>>>>>>>>>> that is attatched as wlanthennative2.log
>>>>>>>>
>>>>>>>>
>>>>>>>>> It sounds like linux driver didn't recognised usb
>>>>>>>>> id and didn't uploaded firmware, or there was no
>>>>>>>>> firmware to upload.
>>>>>>>> there is firmware (/lib/firmware/ar5523.bin exists)
>>>>>>>> but it does not even get touched (i renamed the file
>>>>>>>> and the error did not change at all)
>>>>>>
>>>>>>> find first usbid of your adapter (it will be changed
>>>>>>> after firmware upload). And try to force driver to use
>>>>>>> this id: modprobe -v ar5523 echo 07d1 3a0d >
>>>>>>> /sys/bus/usb/drivers/ar5523/new_id
>>>>>>
>>>>>>> instead of "07d1 3a0d" use your id.
>>>>>>
>>>>>>
>>>>>> # lsusb … Bus 003 Device 011: ID 129b:160c CyberTAN
>>>>>> Technology Siemens S30853-S1038-R351 802.11g Wireless
>>>>>> Adapter [Atheros AR5523] …
>>>>>>
>>>>>> # modprobe ar5523 # echo 129b 160c >
>>>>>> /sys/bus/usb/drivers/ar5523/new_id <plugging device in>
>>>>>> syslog: Oct 18 18:27:47 yannik-desktop kernel: [
>>>>>> 8751.447784] usbcore: registered new interface driver
>>>>>> ar5523 Oct 18 18:28:25 yannik-desktop kernel: [
>>>>>> 8789.036912] usb 3-14: new high-speed USB device number
>>>>>> 12 using xhci_hcd Oct 18 18:28:25 yannik-desktop kernel:
>>>>>> [ 8789.053995] usb 3-14: New USB device found,
>>>>>> idVendor=129b, idProduct=160c Oct 18 18:28:25
>>>>>> yannik-desktop kernel: [ 8789.054005] usb 3-14: New USB
>>>>>> device strings: Mfr=1, Product=2, SerialNumber=3 Oct 18
>>>>>> 18:28:25 yannik-desktop kernel: [ 8789.054010] usb 3-14:
>>>>>> Product: AR5523 Oct 18 18:28:25 yannik-desktop kernel: [
>>>>>> 8789.054015] usb 3-14: Manufacturer: Atheros
>>>>>> Communications Inc Oct 18 18:28:25 yannik-desktop kernel:
>>>>>> [ 8789.054019] usb 3-14: SerialNumber: 1.0 Oct 18
>>>>>> 18:28:27 yannik-desktop kernel: [ 8791.052313] usb 3-14:
>>>>>> timeout waiting for command 01 reply Oct 18 18:28:27
>>>>>> yannik-desktop kernel: [ 8791.052323] usb 3-14: could not
>>>>>> initialize adapter Oct 18 18:28:27 yannik-desktop kernel:
>>>>>> [ 8791.052359] usb 3-14: RX USB error -2. Oct 18 18:28:27
>>>>>> yannik-desktop kernel: [ 8791.052378] usb 3-14: error -1
>>>>>> when submitting rx urb Oct 18 18:28:27 yannik-desktop
>>>>>> kernel: [ 8791.052504] ar5523: probe of 3-14:1.0 failed
>>>>>> with error -110
>>>>>>
>>>>>>> Besidy, what kernel version are you using? May be it
>>>>>>> is too old..
>>>>>>
>>>>>> 3.11.0-12-generic it is my understanding that the ar5523
>>>>>> driver was included from 3.8 on.
>>>>
>>>>> please test attached patch.
>>>> Stopped the error from appearing but it looks like it would
>>>> not even try to upload the firmware to me:
>>
>>> Hi Yannik,
>>
>>> please use this patch instead of previous. It will provide
>>> some more info. And send me complete dmesg.
>>
>> I have to correct myself: I got the sources via apt-get source
>> (as opposed to git) this time. applied patch, worked.
>
>
> Thank you for update. Can you please send us dmesg with working
> result.
sure:
[ 9594.050560] usb 3-14: USB disconnect, device number 31
[ 9594.158932] wlan0: deauthenticating from 00:04:0e:d8:dd:56 by local
choice (reason=3)
[ 9594.254929] cfg80211: Calling CRDA to update world regulatory domain
[ 9594.261826] cfg80211: World regulatory domain updated:
[ 9594.261828] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 9594.261830] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 9594.261831] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 9594.261832] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz),
(300 mBi, 2000 mBm)
[ 9594.261833] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 9594.261834] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 9596.032401] e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
[ 9596.136438] e1000e 0000:00:19.0: irq 42 for MSI/MSI-X
[ 9596.136603] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 9596.616166] usb 3-14: new high-speed USB device number 32 using
xhci_hcd
[ 9596.633336] usb 3-14: New USB device found, idVendor=129b,
idProduct=160c
[ 9596.633345] usb 3-14: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 9596.633351] usb 3-14: Product: AR5523
[ 9596.633355] usb 3-14: Manufacturer: Atheros Communications Inc
[ 9596.633360] usb 3-14: SerialNumber: 1.0
[ 9596.634037] ar5523: start probe
[ 9596.729806] ar5523: firmware uploaded
[ 9596.877982] usb 3-14: USB disconnect, device number 32
[ 9597.148034] usb 3-14: new high-speed USB device number 33 using
xhci_hcd
[ 9597.165114] usb 3-14: New USB device found, idVendor=129b,
idProduct=160b
[ 9597.165123] usb 3-14: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 9597.165129] usb 3-14: Product: AR5523
[ 9597.165134] usb 3-14: Manufacturer: Atheros Communications Inc
[ 9597.165138] usb 3-14: SerialNumber: 1.0
[ 9597.165785] ar5523: start probe
[ 9597.212580] usb 3-14: Cap: CAP_TARGET_VERSION=0x00000006
[ 9597.212865] usb 3-14: Cap: CAP_TARGET_REVISION=0x00000001
[ 9597.213155] usb 3-14: Cap: CAP_MAC_VERSION=0x00000008
[ 9597.213420] usb 3-14: Cap: CAP_MAC_REVISION=0x00000001
[ 9597.213669] usb 3-14: Cap: CAP_PHY_REVISION=0x00000046
[ 9597.213939] usb 3-14: Cap: CAP_ANALOG_5GHz_REVISION=0x00000046
[ 9597.214188] usb 3-14: Cap: CAP_ANALOG_2GHz_REVISION=0x00000000
[ 9597.214459] usb 3-14: Cap: CAP_REG_DOMAIN=0x00000030
[ 9597.214699] usb 3-14: Cap: CAP_REG_CAP_BITS=0x00000000
[ 9597.214925] usb 3-14: Cap: CAP_WIRELESS_MODES=0x00000000
[ 9597.215238] usb 3-14: Cap: CAP_CHAN_SPREAD_SUPPORT=0x0000001c
[ 9597.215482] usb 3-14: Cap: CAP_COMPRESS_SUPPORT=0x00000001
[ 9597.215754] usb 3-14: Cap: CAP_BURST_SUPPORT=0x00000001
[ 9597.216025] usb 3-14: Cap: CAP_FAST_FRAMES_SUPPORT=0x00000001
[ 9597.216316] usb 3-14: Cap: CAP_CHAP_TUNING_SUPPORT=0x00000001
[ 9597.216563] usb 3-14: Cap: CAP_TURBOG_SUPPORT=0x00000001
[ 9597.216814] usb 3-14: Cap: CAP_TURBO_PRIME_SUPPORT=0x00000001
[ 9597.217084] usb 3-14: Cap: CAP_DEVICE_TYPE=0x00000001
[ 9597.217333] usb 3-14: Cap: CAP_WME_SUPPORT=0x00000001
[ 9597.217593] usb 3-14: Cap: CAP_TOTAL_QUEUES=0x00000001
[ 9597.217844] usb 3-14: Cap: CAP_CONNECTION_ID_MAX=0x0000000a
[ 9597.218112] usb 3-14: Cap: CAP_LOW_5GHZ_CHAN=0x00000004
[ 9597.218362] usb 3-14: Cap: CAP_HIGH_5GHZ_CHAN=0x00001338
[ 9597.218611] usb 3-14: Cap: CAP_LOW_2GHZ_CHAN=0x000017d4
[ 9597.218862] usb 3-14: Cap: CAP_HIGH_2GHZ_CHAN=0x00000908
[ 9597.219111] usb 3-14: Cap: CAP_TWICE_ANTENNAGAIN_5G=0x00000001
[ 9597.219376] usb 3-14: Cap: CAP_TWICE_ANTENNAGAIN_2G=0x00000004
[ 9597.219605] usb 3-14: Cap: CAP_CIPHER_AES_CCM=0x00000001
[ 9597.219861] usb 3-14: Cap: CAP_CIPHER_TKIP=0x00000000
[ 9597.220158] usb 3-14: Cap: CAP_MIC_TKIP=0x00000000
[ 9597.220732] usb 3-14: MAC/BBP AR5523, RF AR2112
[ 9597.221376] usb 3-14: Found and initialized AR5523 device
[ 9597.332462] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 9599.371152] wlan0: authenticate with 00:04:0e:d8:dd:56
[ 9599.380705] wlan0: send auth to 00:04:0e:d8:dd:56 (try 1/3)
[ 9599.382768] wlan0: authenticated
[ 9599.386282] wlan0: associate with 00:04:0e:d8:dd:56 (try 1/3)
[ 9599.395019] wlan0: RX AssocResp from 00:04:0e:d8:dd:56 (capab=0x411
status=0 aid=1)
[ 9599.395786] wlan0: associated
[ 9599.395820] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
as reported the connection sometimes breakes down, when that happens
the dmesg contains multiple repetitions of the line
[ 9577.930431] usb 3-14: ar5523_data_rx_cb: USB err: -2
- --
Yannik Völker
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAEBAgAGBQJSaRapAAoJEDqk81AiCyXKvxkQAJPrAEx7E/YPEJEMVzIPsBQw
e9YyGkMJPfHRLJghtVAofKxmprohoq+NDNN5LHjMbm60q/TgKYlbQyHW4dDBc5yG
sV8L2A6/uDECi+5nq1ONUIsBIroWRIyXbfmcfDICCiGeO/z0Y/HraIsJtxNVu4Bx
gNMOgpKWV61nu/HeKQLLT52ShXnLfTOi+sqZape5PVm2YxHVS7DypfQ4q+qXdgEa
Rr5UxuItzYuIl0FrjxuVcMzgOwbMvP02tZZu+jnDU9XlQLf69C/TDjVDlGbvN9V3
nJh9bdeLqfz3IwLq1ojmEuqyF2rDTbHY/ccvw9ZbO7GfoWfo21EN23BXU/Codqnk
kr+GgMWX3Or8nQnJs0xZE7Rvaso2Xg6EEsbtlNyTz9BH85m0md+jCrtY6kYq93UT
U4S3CvtO+6gr2RYbR7WEIl+T67SQAZP0CPHQ6/VOhD5zkUIY5RGNoPTpekaKYKVG
m//6WXU50EZIcqHbIjpWQ3wGvYQ+GcZDmNA7b64Suc9G2HKJTyJhwZtjm4ql1FBL
k6zAcyF2TRG8bAm0+FudhhsTjJCmgcDVjWuJjrmWA46HgRj9ISLvbg8P0Pqo9792
PUEZbRXy9oWu77py9KmBwueomGIK2gM/14t/arXa82VXfryIv+Y2RxpNUlY3cXgB
3RoqQbe2+hh9nPM2fg65
=YL+I
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] mac80211: do not compute offset from ssn in Rx AMPDU reordering buffer
From: Karl Beldan @ 2013-10-24 13:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Karl Beldan, Karl Beldan
From: Karl Beldan <karl.beldan@rivierawaves.com>
ATM, frames with SN sn are mapped into the sta reordering buffer
sta->ampdu_mlme->tid_rx->reorder_buf at index
ieee80211_sn_sub(sn, tid_rx->ssn) % tid_rx->buf_size.
This offset calculation is useless, and this change replaces the index
with sn % tid_rx->buf_size.
Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
---
net/mac80211/rx.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 23f49e8..3cec926 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -729,9 +729,7 @@ static void ieee80211_release_reorder_frames(struct ieee80211_sub_if_data *sdata
lockdep_assert_held(&tid_agg_rx->reorder_lock);
while (ieee80211_sn_less(tid_agg_rx->head_seq_num, head_seq_num)) {
- index = ieee80211_sn_sub(tid_agg_rx->head_seq_num,
- tid_agg_rx->ssn) %
- tid_agg_rx->buf_size;
+ index = tid_agg_rx->head_seq_num % tid_agg_rx->buf_size;
ieee80211_release_reorder_frame(sdata, tid_agg_rx, index,
frames);
}
@@ -757,8 +755,7 @@ static void ieee80211_sta_reorder_release(struct ieee80211_sub_if_data *sdata,
lockdep_assert_held(&tid_agg_rx->reorder_lock);
/* release the buffer until next missing frame */
- index = ieee80211_sn_sub(tid_agg_rx->head_seq_num,
- tid_agg_rx->ssn) % tid_agg_rx->buf_size;
+ index = tid_agg_rx->head_seq_num % tid_agg_rx->buf_size;
if (!tid_agg_rx->reorder_buf[index] &&
tid_agg_rx->stored_mpdu_num) {
/*
@@ -793,15 +790,11 @@ static void ieee80211_sta_reorder_release(struct ieee80211_sub_if_data *sdata,
} else while (tid_agg_rx->reorder_buf[index]) {
ieee80211_release_reorder_frame(sdata, tid_agg_rx, index,
frames);
- index = ieee80211_sn_sub(tid_agg_rx->head_seq_num,
- tid_agg_rx->ssn) %
- tid_agg_rx->buf_size;
+ index = tid_agg_rx->head_seq_num % tid_agg_rx->buf_size;
}
if (tid_agg_rx->stored_mpdu_num) {
- j = index = ieee80211_sn_sub(tid_agg_rx->head_seq_num,
- tid_agg_rx->ssn) %
- tid_agg_rx->buf_size;
+ j = index = tid_agg_rx->head_seq_num % tid_agg_rx->buf_size;
for (; j != (index - 1) % tid_agg_rx->buf_size;
j = (j + 1) % tid_agg_rx->buf_size) {
@@ -861,8 +854,7 @@ static bool ieee80211_sta_manage_reorder_buf(struct ieee80211_sub_if_data *sdata
/* Now the new frame is always in the range of the reordering buffer */
- index = ieee80211_sn_sub(mpdu_seq_num,
- tid_agg_rx->ssn) % tid_agg_rx->buf_size;
+ index = mpdu_seq_num % tid_agg_rx->buf_size;
/* check if we already stored this frame */
if (tid_agg_rx->reorder_buf[index]) {
--
1.8.2
^ permalink raw reply related
* Re: iwl3945 filling kern.log when HW switch is off
From: Dan Williams @ 2013-10-24 14:48 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Dietmar Rudolph, linux-wireless
In-Reply-To: <20131024112750.GC1677@redhat.com>
On Thu, 2013-10-24 at 13:27 +0200, Stanislaw Gruszka wrote:
> On Wed, Oct 23, 2013 at 11:24:49AM +0200, Dietmar Rudolph wrote:
> > Hello, I hope this is the correct place to put a bug report in. I do
> > not subscribe to this mailing list, but feel free to send PM in case
> > you need additional info. You shoudn't :-)
> >
> > After installing Ubuntu 13.10, I noticed kern.log growing faster
> > than you could look at. Within a few working hours, kern.log was
> > >6GB!
> >
> > The reason is that I intentionally disabled WiFi on this laptop by
> > turning the HW switch off. However, this makes iwl3945 write a log
> > entry into kern.log every few microseconds!
> >
> > The workaround is to turn the HW switch on. The bug fix would be to
> > write just a single line to kern.log.
>
> This message is printed when someone try to UP device when RF kill
> switch is on. Either you did not compile kernel with CONFIG_RFKILL or
> your user space network management software does not handle rfkill .
Though maybe it shouldn't actually print a dmesg error when that
happens? Lots of software (scripts included) might try to open the
device but not really know much about rfkill... Is there a way to print
it once-per-rfkill instead maybe?
Dan
^ permalink raw reply
* Re: [rt2x00-users] [PATCH] rt2x00: rt2800lib: update RF registers for RT5390
From: Andreas Hartmann @ 2013-10-24 16:40 UTC (permalink / raw)
To: Kevin Lo, John Linville; +Cc: linux-wireless, users
In-Reply-To: <20131024052408.GA7828@ns.kevlo.org>
Hi Kevin,
Kevin Lo wrote:
> Mirror the latest MediaTek/Ralink driver with respect to RT5390 RF register
> programming. The PCI and USB devices use different init values.
If you (and others here) really want to improve anything for rt2800usb,
change your development system and use a raspberry pi (PI).
Why PI? Because the PI doesn't cover any broken code / concept / driver
architecture with hardware resources.
You want to have an example?
This device[1] achieves 140 MBit/s (data receiving) on the PI, measured
with netperf and rt5572sta compared to rt2800usb, which achieves very
very very poor 30 MBit/s(! - even w/ best radio conditions can't be
achieved any more) but an extremely high CPU load at the same time!
If you compare the basic behaviour of rt5572sta and rt2800usb, you will
see, that rt5572sta uses a completely different usb handling, which
doesn't need that much CPU resources as the one used by rt2800usb.
Therefore: If you really want to improve rt2800usb, at first take a
serious look at how usb is handled by rt5572sta and how to save CPU
resources.
In a nutshell: Use a few, but big USB packets instead of a lot of small
ones, which needs a lot of interrupts / s and therefore needs a lot of
CPU resources - which aren't available on the PI at all.
Kind regards,
Andreas
[1] http://wikidevi.com/wiki/Linksys_AE3000
^ permalink raw reply
* [Patch v2 1/3] net: wireless: replace printk with netdev_warn in adm8211.c
From: Georgiana Rodica Chelu @ 2013-10-24 21:30 UTC (permalink / raw)
To: opw-kernel; +Cc: linux-wireless
WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then pr_warn(...
to printk(KERN_WARNING ...
Signed-off-by: Georgiana Rodica Chelu <georgiana.chelu93@gmail.com>
---
drivers/net/wireless/adm8211.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
index f9a24e5..0d0dcba 100644
--- a/drivers/net/wireless/adm8211.c
+++ b/drivers/net/wireless/adm8211.c
@@ -151,8 +151,9 @@ static int adm8211_read_eeprom(struct ieee80211_hw *dev)
else
priv->rf_type = ADM8211_TYPE_AIROHA;
- printk(KERN_WARNING "%s (adm8211): Unknown RFtype %d\n",
- pci_name(priv->pdev), (cr49 >> 3) & 0x7);
+ netdev_warn(priv->pdev, "(adm8211): Unknown RFtype %d\n",
+ pci_name(priv->pdev), (cr49 >> 3) & 0x7);
+
}
priv->bbp_type = cr49 & 0x7;
--
1.8.1.2
^ permalink raw reply related
* Fw: [Bug 63601] New: Since kernel 3.7.0 rfkill switch is no longer working on Dell E5530
From: Stephen Hemminger @ 2013-10-24 21:31 UTC (permalink / raw)
To: linux-wireless
Begin forwarded message:
Date: Wed, 23 Oct 2013 22:22:21 -0700
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 63601] New: Since kernel 3.7.0 rfkill switch is no longer working on Dell E5530
https://bugzilla.kernel.org/show_bug.cgi?id=63601
Bug ID: 63601
Summary: Since kernel 3.7.0 rfkill switch is no longer working
on Dell E5530
Product: Networking
Version: 2.5
Kernel Version: 3.7.0 - 3.11.6
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: low
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: vaclav@bohata.net
Regression: No
Created attachment 112171
--> https://bugzilla.kernel.org/attachment.cgi?id=112171&action=edit
.config file
Since kernel 3.7.0 rfkill switch on my Dell E5530 is no longer working. Rfkill
command is working well, but laptop switch not. Even no message in dmesg since
3.7.0 when switching between ON/OFF. Tested on kernel 3.7.0, ubuntu-3.8, 3.10,
3.11.6.
lspci:
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller
(rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family
USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series
Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family
USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family
High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI
Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI
Express Root Port 2 (rev c4)
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI
Express Root Port 3 (rev c4)
00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI
Express Root Port 4 (rev c4)
00:1c.5 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI
Express Root Port 6 (rev c4)
00:1c.6 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI
Express Root Port 7 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family
USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM77 Express Chipset LPC Controller (rev
04)
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller
[RAID mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus
Controller (rev 04)
02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor
Peak] (rev 34)
0b:00.0 SD Host controller: O2 Micro, Inc. Device 8221 (rev 05)
0c:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5761 Gigabit
Ethernet PCIe (rev 10)
lsusb:
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 002: ID 09da:054f A4 Tech Co., Ltd
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 413c:8197 Dell Computer Corp.
Bus 001 Device 004: ID 0c45:648b Microdia
Bus 001 Device 005: ID 08ff:2810 AuthenTec, Inc. AES2810
lsmod (from 3.7.0):
Module Size Used by
pci_stub 12623 1
vboxpci 23237 0
vboxnetadp 25671 0
vboxnetflt 27613 0
vboxdrv 320275 3 vboxpci,vboxnetadp,vboxnetflt
nfsd 277655 2
nfs_acl 12838 1 nfsd
auth_rpcgss 45138 1 nfsd
nfs 180537 0
fscache 61011 1 nfs
lockd 93923 2 nfsd,nfs
sunrpc 269856 6 nfsd,nfs_acl,auth_rpcgss,nfs,lockd
rfcomm 42652 12
bnep 18182 2
arc4 12574 2
binfmt_misc 17432 1
iwldvm 241721 0
xt_hl 12522 6
snd_hda_codec_hdmi 36805 1
snd_hda_codec_idt 70197 1
ip6t_rt 12559 3
nf_conntrack_ipv6 14161 7
nf_defrag_ipv6 13231 1 nf_conntrack_ipv6
snd_hda_intel 33817 3
mac80211 558626 1 iwldvm
ipt_REJECT 12542 1
xt_LOG 17401 9
nls_iso8859_1 12714 1
snd_hda_codec 134873 3
snd_hda_codec_hdmi,snd_hda_codec_idt,snd_hda_intel
xt_limit 12712 12
xt_tcpudp 12604 22
xt_addrtype 12636 4
snd_hwdep 13564 1 snd_hda_codec
nf_conntrack_ipv4 14488 7
nf_defrag_ipv4 12730 1 nf_conntrack_ipv4
xt_state 12579 14
snd_pcm 97487 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_seq_midi 13325 0
iwlwifi 165764 1 iwldvm
snd_rawmidi 30571 1 snd_seq_midi
ip6table_filter 12816 1
snd_seq_midi_event 14900 1 snd_seq_midi
ip6_tables 27165 2 ip6t_rt,ip6table_filter
snd_seq 61555 2 snd_seq_midi,snd_seq_midi_event
coretemp 13358 0
snd_timer 29533 2 snd_pcm,snd_seq
nf_conntrack_netbios_ns 12666 0
snd_seq_device 14498 3 snd_seq_midi,snd_rawmidi,snd_seq
kvm_intel 136540 0
kvm 428528 1 kvm_intel
i8k 14301 0
ppdev 17031 0
nf_conntrack_broadcast 12590 1 nf_conntrack_netbios_ns
nf_conntrack_ftp 13339 0
nf_conntrack 83444 6
nf_conntrack_ipv6,nf_conntrack_ipv4,xt_state,nf_conntrack_netbios_ns,nf_conntrack_broadcast,nf_conntrack_ftp
dell_laptop 17426 0
dell_wmi 12682 0
iptable_filter 12811 1
snd 78959 16
snd_hda_codec_hdmi,snd_hda_codec_idt,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
soundcore 15048 1 snd
btusb 18292 0
ip_tables 26953 1 iptable_filter
bluetooth 206157 24 rfcomm,bnep,btusb
snd_page_alloc 18711 2 snd_hda_intel,snd_pcm
cfg80211 211955 3 iwldvm,mac80211,iwlwifi
x_tables 29758 12
xt_hl,ip6t_rt,ipt_REJECT,xt_LOG,xt_limit,xt_tcpudp,xt_addrtype,xt_state,ip6table_filter,ip6_tables,iptable_filter,ip_tables
psmouse 86392 0
lp 17760 0
sparse_keymap 13891 1 dell_wmi
joydev 17378 0
serio_raw 13216 0
lpc_ich 17062 0
dcdbas 14439 1 dell_laptop
mei 40696 0
parport_pc 32689 0
parport 46355 3 ppdev,lp,parport_pc
microcode 22894 0
mac_hid 13206 0
dm_crypt 22801 1
hid_generic 12541 0
usbhid 46983 0
hid 100136 2 hid_generic,usbhid
ghash_clmulni_intel 13260 0
aesni_intel 55400 5
ablk_helper 13598 1 aesni_intel
cryptd 20361 4 ghash_clmulni_intel,aesni_intel,ablk_helper
lrw 13287 1 aesni_intel
aes_x86_64 17256 1 aesni_intel
xts 12915 1 aesni_intel
gf128mul 14952 2 lrw,xts
wmi 19071 1 dell_wmi
ahci 25732 3
libahci 31395 1 ahci
i915 571649 3
drm_kms_helper 46589 1 i915
drm 280738 4 i915,drm_kms_helper
i2c_algo_bit 13414 1 i915
sdhci_pci 18621 0
video 19098 1 i915
sdhci 32646 1 sdhci_pci
tg3 149251 0
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [Patch v2 2/3] net: wireless: replace printk with netdev_warn in adm8211.c
From: Georgiana Rodica Chelu @ 2013-10-24 22:17 UTC (permalink / raw)
To: opw-kernel; +Cc: linux-wireless
WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then pr_warn(...
to printk(KERN_WARNING ...
Signed-off-by: Georgiana Rodica Chelu <georgiana.chelu93@gmail.com>
---
drivers/net/wireless/adm8211.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
index 0d0dcba..1910ea7 100644
--- a/drivers/net/wireless/adm8211.c
+++ b/drivers/net/wireless/adm8211.c
@@ -170,13 +170,14 @@ static int adm8211_read_eeprom(struct ieee80211_hw *dev)
else
priv->bbp_type = ADM8211_TYPE_ADMTEK;
- printk(KERN_WARNING "%s (adm8211): Unknown BBPtype: %d\n",
- pci_name(priv->pdev), cr49 >> 3);
+ netdev_warn(priv->pdev, "(adm8211): Unknown BBPtype: %d\n",
+ pci_name(priv->pdev), cr49 >> 3);
}
if (priv->eeprom->country_code >= ARRAY_SIZE(cranges)) {
- printk(KERN_WARNING "%s (adm8211): Invalid country code (%d)\n",
- pci_name(priv->pdev), priv->eeprom->country_code);
+ netdev_warn(priv->eeprom, "(adm8211): Invalid country code ",
+ "(%d)\n", pci_name(priv->pdev),
+ priv->eeprom->country_code);
chan_range = cranges[2];
} else
@@ -210,8 +211,9 @@ static int adm8211_read_eeprom(struct ieee80211_hw *dev)
else
priv->specific_bbptype = ADM8211_BBP_ADM8011;
- printk(KERN_WARNING "%s (adm8211): Unknown specific BBP: %d\n",
- pci_name(priv->pdev), priv->eeprom->specific_bbptype);
+ netdev_warn(priv->pdev, "(adm8211): Unknown specific BBP: %d",
+ "\n", pci_name(priv->pdev),
+ priv->eeprom->specific_bbptype);
}
switch (priv->eeprom->specific_rftype) {
@@ -231,8 +233,9 @@ static int adm8211_read_eeprom(struct ieee80211_hw *dev)
else if (priv->pdev->revision == ADM8211_REV_AB)
priv->transceiver_type = ADM8211_RFMD2948;
- printk(KERN_WARNING "%s (adm8211): Unknown transceiver: %d\n",
- pci_name(priv->pdev), priv->eeprom->specific_rftype);
+ netdev_warn(priv->pdev, "(adm8211): Unknown transceiver: %d\n",
+ pci_name(priv->pdev),
+ priv->eeprom->specific_rftype);
break;
}
--
1.8.1.2
^ permalink raw reply related
* [Patch v2 3/3] net: wireless: replace printk with netdev_warn in adm8211.c
From: Georgiana Rodica Chelu @ 2013-10-24 22:25 UTC (permalink / raw)
To: opw-kernel; +Cc: linux-wireless
WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then
pr_warn(... to printk(KERN_WARNING ...
Signed-off-by: Georgiana Rodica Chelu <georgiana.chelu93@gmail.com>
---
drivers/net/wireless/adm8211.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
index 1910ea7..3eee517 100644
--- a/drivers/net/wireless/adm8211.c
+++ b/drivers/net/wireless/adm8211.c
@@ -1859,8 +1859,8 @@ static int adm8211_probe(struct pci_dev *pdev,
cpu_to_le16(ADM8211_CSR_READ(PAR1) & 0xFFFF);
if (!is_valid_ether_addr(perm_addr)) {
- printk(KERN_WARNING "%s (adm8211): Invalid hwaddr in EEPROM!\n",
- pci_name(pdev));
+ netdev_warn(dev->priv, "(adm8211): Invalid hwaddr in EEPROM!",
+ "\n", pci_name(pdev));
eth_random_addr(perm_addr);
}
SET_IEEE80211_PERM_ADDR(dev, perm_addr);
--
1.8.1.2
^ permalink raw reply related
* Re: [Patch v2 1/3] net: wireless: replace printk with netdev_warn in adm8211.c
From: Joe Perches @ 2013-10-24 22:46 UTC (permalink / raw)
To: Georgiana Rodica Chelu; +Cc: opw-kernel, linux-wireless
In-Reply-To: <20131024213026.GA3569@fireworks>
On Fri, 2013-10-25 at 00:30 +0300, Georgiana Rodica Chelu wrote:
> WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then pr_warn(...
> to printk(KERN_WARNING ...
Hi Georgiana.
Please compile and test your patches before submitting them.
> diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
> @@ -151,8 +151,9 @@ static int adm8211_read_eeprom(struct ieee80211_hw *dev)
> else
> priv->rf_type = ADM8211_TYPE_AIROHA;
>
> - printk(KERN_WARNING "%s (adm8211): Unknown RFtype %d\n",
> - pci_name(priv->pdev), (cr49 >> 3) & 0x7);
> + netdev_warn(priv->pdev, "(adm8211): Unknown RFtype %d\n",
> + pci_name(priv->pdev), (cr49 >> 3) & 0x7);
> +
> }
>
> priv->bbp_type = cr49 & 0x7;
netdev_warn 1st arg is a struct net_device *
priv->pdev is a struct pci_dev *
^ permalink raw reply
* Re: [OPW kernel] [Patch v2 2/3] net: wireless: replace printk with netdev_warn in adm8211.c
From: Rusty Russell @ 2013-10-25 1:18 UTC (permalink / raw)
To: Georgiana Rodica Chelu, opw-kernel; +Cc: linux-wireless
In-Reply-To: <20131024221712.GA4175@fireworks>
Georgiana Rodica Chelu <georgiana.chelu93@gmail.com> writes:
> WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then pr_warn(...
> to printk(KERN_WARNING ...
>
> Signed-off-by: Georgiana Rodica Chelu <georgiana.chelu93@gmail.com>
I don't think this will compile.
Please test your patches,
Rusty.
> ---
> drivers/net/wireless/adm8211.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
> index 0d0dcba..1910ea7 100644
> --- a/drivers/net/wireless/adm8211.c
> +++ b/drivers/net/wireless/adm8211.c
> @@ -170,13 +170,14 @@ static int adm8211_read_eeprom(struct ieee80211_hw *dev)
> else
> priv->bbp_type = ADM8211_TYPE_ADMTEK;
>
> - printk(KERN_WARNING "%s (adm8211): Unknown BBPtype: %d\n",
> - pci_name(priv->pdev), cr49 >> 3);
> + netdev_warn(priv->pdev, "(adm8211): Unknown BBPtype: %d\n",
> + pci_name(priv->pdev), cr49 >> 3);
> }
>
> if (priv->eeprom->country_code >= ARRAY_SIZE(cranges)) {
> - printk(KERN_WARNING "%s (adm8211): Invalid country code (%d)\n",
> - pci_name(priv->pdev), priv->eeprom->country_code);
> + netdev_warn(priv->eeprom, "(adm8211): Invalid country code ",
> + "(%d)\n", pci_name(priv->pdev),
> + priv->eeprom->country_code);
>
> chan_range = cranges[2];
> } else
> @@ -210,8 +211,9 @@ static int adm8211_read_eeprom(struct ieee80211_hw *dev)
> else
> priv->specific_bbptype = ADM8211_BBP_ADM8011;
>
> - printk(KERN_WARNING "%s (adm8211): Unknown specific BBP: %d\n",
> - pci_name(priv->pdev), priv->eeprom->specific_bbptype);
> + netdev_warn(priv->pdev, "(adm8211): Unknown specific BBP: %d",
> + "\n", pci_name(priv->pdev),
> + priv->eeprom->specific_bbptype);
> }
>
> switch (priv->eeprom->specific_rftype) {
> @@ -231,8 +233,9 @@ static int adm8211_read_eeprom(struct ieee80211_hw *dev)
> else if (priv->pdev->revision == ADM8211_REV_AB)
> priv->transceiver_type = ADM8211_RFMD2948;
>
> - printk(KERN_WARNING "%s (adm8211): Unknown transceiver: %d\n",
> - pci_name(priv->pdev), priv->eeprom->specific_rftype);
> + netdev_warn(priv->pdev, "(adm8211): Unknown transceiver: %d\n",
> + pci_name(priv->pdev),
> + priv->eeprom->specific_rftype);
>
> break;
> }
> --
> 1.8.1.2
>
> --
> You received this message because you are subscribed to the Google Groups "opw-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to opw-kernel+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [rt2x00-users] [PATCH] rt2x00: rt2800lib: update RF registers for RT5390
From: Kevin Lo @ 2013-10-25 2:03 UTC (permalink / raw)
To: Andreas Hartmann, John Linville; +Cc: linux-wireless, users
In-Reply-To: <52694D8B.1030308@01019freenet.de>
Andreas Hartmann wrote:
> Hi Kevin,
Hi Andreas,
> Kevin Lo wrote:
>> Mirror the latest MediaTek/Ralink driver with respect to RT5390 RF register
>> programming. The PCI and USB devices use different init values.
> If you (and others here) really want to improve anything for rt2800usb,
> change your development system and use a raspberry pi (PI).
>
> Why PI? Because the PI doesn't cover any broken code / concept / driver
> architecture with hardware resources.
>
> You want to have an example?
>
> This device[1] achieves 140 MBit/s (data receiving) on the PI, measured
> with netperf and rt5572sta compared to rt2800usb, which achieves very
> very very poor 30 MBit/s(! - even w/ best radio conditions can't be
> achieved any more) but an extremely high CPU load at the same time!
>
> If you compare the basic behaviour of rt5572sta and rt2800usb, you will
> see, that rt5572sta uses a completely different usb handling, which
> doesn't need that much CPU resources as the one used by rt2800usb.
>
> Therefore: If you really want to improve rt2800usb, at first take a
> serious look at how usb is handled by rt5572sta and how to save CPU
> resources.
>
> In a nutshell: Use a few, but big USB packets instead of a lot of small
> ones, which needs a lot of interrupts / s and therefore needs a lot of
> CPU resources - which aren't available on the PI at all.
I have a lot of embedded devices (Freescale imx5/imx6, Marvell armanda xp
... etc) here and I've also noticed usb performance issues.
Firstly, I want to sync register settings, which is obtained from the
vendor driver. When it's done, I will take a look at how usb is handled by
the vendor driver and fix performance issues. Since I don't have
datasheets,
I'm not sure updating register values won't help much...
>
>
> Kind regards,
> Andreas
>
>
>
> [1] http://wikidevi.com/wiki/Linksys_AE3000
Kevin
^ permalink raw reply
* Re: Centrino Wireless-N 2200 authentication time-outs and unexpected deauthentication
From: Kenneth Berland @ 2013-10-25 2:53 UTC (permalink / raw)
To: linux-wireless, ilw
In-Reply-To: <alpine.LFD.2.00.1310171107460.9527@hero.com>
I've turned off "SmartSelect" on the Ruckus ZoneFlex 7982 and picked a
static channel. The connection is now more stable, at least no
de-associations today.
It makes me think that rapid or very frequent channel switching by the AP
is exposing a problem in the driver that one would otherwise never see.
-KB
On Thu, 17 Oct 2013, Kenneth Berland wrote:
> All,
>
> I'm having a hard time keeping a connection to a Ruckus ZoneFlex 7982 AP. The
> SSID is running WPA2/PSK/AES. I'm running a recent iwlwifi kernel
> (3.12.0-rc3-wl+) and have a Centrino chipset. After an hour or so, the
> interface is disconnected. It can only reauthenticate when the iwlwifi
> module is removed and re-inserted.
>
> Thanks in advance,
> Ken
>
> I'm running a recent wpa_supplicant with nl80211 like this:
>
> /sbin/wpa_supplicant -Dnl80211 -s -i wlan0 -c ./gr-test.conf
>
> The relevant log output is the following (I think):
>
> Oct 17 10:39:26 ken-x230 wpa_supplicant[15828]: Successfully initialized
> wpa_supplicant
> Oct 17 10:39:26 ken-x230 kernel: [19456.093074] iwlwifi 0000:03:00.0: L1
> Enabled; Disabling L0S
> Oct 17 10:39:26 ken-x230 kernel: [19456.100991] iwlwifi 0000:03:00.0: Radio
> type=0x2-0x0-0x0
> Oct 17 10:39:26 ken-x230 kernel: [19456.173751] IPv6: ADDRCONF(NETDEV_UP):
> wlan0: link is not ready
> Oct 17 10:39:27 ken-x230 wpa_supplicant[15828]: wlan0: SME: Trying to
> authenticate with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
> Oct 17 10:39:27 ken-x230 kernel: [19456.930480] wlan0: authenticate with
> 2c:e6:cc:84:8d:98
> Oct 17 10:39:27 ken-x230 kernel: [19456.935141] wlan0: send auth to
> 2c:e6:cc:84:8d:98 (try 1/3)
> Oct 17 10:39:28 ken-x230 kernel: [19458.156795] wlan0: send auth to
> 2c:e6:cc:84:8d:98 (try 2/3)
> Oct 17 10:39:29 ken-x230 kernel: [19459.169462] wlan0: send auth to
> 2c:e6:cc:84:8d:98 (try 3/3)
> Oct 17 10:39:30 ken-x230 kernel: [19460.170078] wlan0: authentication with
> 2c:e6:cc:84:8d:98 timed out
> Oct 17 10:39:31 ken-x230 wpa_supplicant[15828]: wlan0: SME: Trying to
> authenticate with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
> Oct 17 10:39:31 ken-x230 kernel: [19460.932095] wlan0: authenticate with
> 2c:e6:cc:84:8d:98
> Oct 17 10:39:31 ken-x230 kernel: [19460.935224] wlan0: send auth to
> 2c:e6:cc:84:8d:98 (try 1/3)
> Oct 17 10:39:32 ken-x230 kernel: [19462.159432] wlan0: send auth to
> 2c:e6:cc:84:8d:98 (try 2/3)
> Oct 17 10:39:33 ken-x230 kernel: [19463.148066] wlan0: send auth to
> 2c:e6:cc:84:8d:98 (try 3/3)
> Oct 17 10:39:34 ken-x230 kernel: [19464.148711] wlan0: authentication with
> 2c:e6:cc:84:8d:98 timed out
> Oct 17 10:39:35 ken-x230 wpa_supplicant[15828]: wlan0: SME: Trying to
> authenticate with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
> Oct 17 10:39:35 ken-x230 kernel: [19465.307056] wlan0: authenticate with
> 2c:e6:cc:84:8d:98
> Oct 17 10:39:35 ken-x230 kernel: [19465.311719] wlan0: send auth to
> 2c:e6:cc:84:8d:98 (try 1/3)
> Oct 17 10:39:36 ken-x230 kernel: [19466.162056] wlan0: send auth to
> 2c:e6:cc:84:8d:98 (try 2/3)
> Oct 17 10:39:37 ken-x230 kernel: [19467.162688] wlan0: send auth to
> 2c:e6:cc:84:8d:98 (try 3/3)
> Oct 17 10:39:38 ken-x230 kernel: [19468.139372] wlan0: authentication with
> 2c:e6:cc:84:8d:98 timed out
>
> or, sometimes, like this:
>
> Oct 16 18:35:20 ken-x230 wpa_supplicant[5490]: wlan0: CTRL-EVENT-CONNECTED -
> Connection to 2c:e6:cc:84:8d:98 completed [id=0 id_str=]
> Oct 16 18:35:22 ken-x230 kernel: [ 5141.751420] wlan0: deauthenticated from
> 2c:e6:cc:84:8d:98 (Reason: 6)
> Oct 16 18:35:22 ken-x230 wpa_supplicant[5490]: wlan0: CTRL-EVENT-DISCONNECTED
> bssid=2c:e6:cc:84:8d:98 reason=6
> Oct 16 18:35:22 ken-x230 wpa_supplicant[5490]: wlan0: SME: Trying to
> authenticate with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
> Oct 16 18:35:22 ken-x230 kernel: [ 5141.806347] wlan0: authenticate with
> 2c:e6:cc:84:8d:98
> Oct 16 18:35:22 ken-x230 wpa_supplicant[5490]: wlan0: Trying to associate
> with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
> Oct 16 18:35:22 ken-x230 kernel: [ 5141.810436] wlan0: send auth to
> 2c:e6:cc:84:8d:98 (try 1/3)
> Oct 16 18:35:22 ken-x230 kernel: [ 5141.812469] wlan0: authenticated
> Oct 16 18:35:22 ken-x230 kernel: [ 5141.813760] wlan0: associate with
> 2c:e6:cc:84:8d:98 (try 1/3)
> Oct 16 18:35:22 ken-x230 kernel: [ 5141.817635] wlan0: RX AssocResp from
> 2c:e6:cc:84:8d:98 (capab=0x431 status=0 aid=3)
> Oct 16 18:35:22 ken-x230 wpa_supplicant[5490]: wlan0: Associated with
> 2c:e6:cc:84:8d:98
> Oct 16 18:35:22 ken-x230 kernel: [ 5141.836654] wlan0: associated
> Oct 16 18:35:22 ken-x230 wpa_supplicant[5490]: wlan0: WPA: Key negotiation
> completed with 2c:e6:cc:84:8d:98 [PTK=CCMP GTK=CCMP]
> Oct 16 18:35:22 ken-x230 wpa_supplicant[5490]: wlan0: CTRL-EVENT-CONNECTED -
> Connection to 2c:e6:cc:84:8d:98 completed [id=0 id_str=]
> Oct 16 18:35:25 ken-x230 kernel: [ 5144.220601] wlan0: deauthenticated from
> 2c:e6:cc:84:8d:98 (Reason: 6)
> Oct 16 18:35:25 ken-x230 wpa_supplicant[5490]: wlan0: CTRL-EVENT-DISCONNECTED
> bssid=2c:e6:cc:84:8d:98 reason=6
> Oct 16 18:35:25 ken-x230 wpa_supplicant[5490]: wlan0: SME: Trying to
> authenticate with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
> Oct 16 18:35:25 ken-x230 kernel: [ 5144.263904] wlan0: authenticate with
> 2c:e6:cc:84:8d:98
> Oct 16 18:35:25 ken-x230 wpa_supplicant[5490]: wlan0: Trying to associate
> with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
> Oct 16 18:35:25 ken-x230 kernel: [ 5144.268060] wlan0: send auth to
> 2c:e6:cc:84:8d:98 (try 1/3)
> Oct 16 18:35:25 ken-x230 kernel: [ 5144.269809] wlan0: authenticated
> Oct 16 18:35:25 ken-x230 kernel: [ 5144.271371] wlan0: associate with
> 2c:e6:cc:84:8d:98 (try 1/3)
> Oct 16 18:35:25 ken-x230 kernel: [ 5144.275280] wlan0: RX AssocResp from
> 2c:e6:cc:84:8d:98 (capab=0x431 status=0 aid=3)
> Oct 16 18:35:25 ken-x230 wpa_supplicant[5490]: wlan0: Associated with
> 2c:e6:cc:84:8d:98
> Oct 16 18:35:25 ken-x230 kernel: [ 5144.294692] wlan0: associated
> Oct 16 18:35:25 ken-x230 wpa_supplicant[5490]: wlan0: WPA: Key negotiation
> completed with 2c:e6:cc:84:8d:98 [PTK=CCMP GTK=CCMP]
> Oct 16 18:35:25 ken-x230 wpa_supplicant[5490]: wlan0: CTRL-EVENT-CONNECTED -
> Connection to 2c:e6:cc:84:8d:98 completed [id=0 id_str=]
> Oct 16 18:35:26 ken-x230 kernel: [ 5145.809824] wlan0: deauthenticated from
> 2c:e6:cc:84:8d:98 (Reason: 6)
> Oct 16 18:35:26 ken-x230 wpa_supplicant[5490]: wlan0: CTRL-EVENT-DISCONNECTED
> bssid=2c:e6:cc:84:8d:98 reason=6
>
> Here is the other, I hope relevant, info:
>
> $ uname -a
> Linux ken-x230 3.12.0-rc3-wl+ #1 SMP Tue Oct 8 11:47:43 PDT 2013 x86_64
> x86_64 x86_64 GNU/Linux # git-sha 1f117d
>
> # wpa_supplicant version:
> $ git remote -v | head -1
> origin git://w1.fi/srv/git/hostap.git (fetch)
> $ git log --decorate | head -1
> commit 5bfd7e91685e65977c8db72afdca0cab310f8667 (HEAD, origin/master,
> origin/HEAD, master)
>
> $ lspci -v # edited
> 03:00.0 Network controller: Intel Corporation Centrino Wireless-N 2200 (rev
> c4)
> Subsystem: Intel Corporation Centrino Wireless-N 2200 BGN
> Flags: bus master, fast devsel, latency 0, IRQ 46
> Memory at f1c00000 (64-bit, non-prefetchable) [size=8K]
> Capabilities: <access denied>
> Kernel driver in use: iwlwifi
> Kernel modules: iwlwifi
>
> $ iw dev wlan0 info # before it locks up
> Interface wlan0
> ifindex 14
> type managed
> wiphy 0
> $ iw dev wlan0 link #again, before it locks up
> Connected to 2c:e6:cc:84:8d:98 (on wlan0)
> SSID: GR-Test
> freq: 2457
> RX: 14757340 bytes (45075 packets)
> TX: 2596610 bytes (8879 packets)
> signal: -37 dBm
> tx bitrate: 130.0 MBit/s MCS 14 short GI
>
> bss flags: short-preamble short-slot-time
> dtim period: 0
> beacon int: 100
>
> $ iw list
>
> Wiphy phy0
> Band 1:
> Capabilities: 0x1072
> HT20/HT40
> Static SM Power Save
> RX Greenfield
> RX HT20 SGI
> RX HT40 SGI
> No RX STBC
> Max AMSDU length: 3839 bytes
> DSSS/CCK HT40
> Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
> Minimum RX AMPDU time spacing: 4 usec (0x05)
> HT TX/RX MCS rate indexes supported: 0-15, 32
> Frequencies:
> * 2412 MHz [1] (15.0 dBm)
> * 2417 MHz [2] (15.0 dBm)
> * 2422 MHz [3] (15.0 dBm)
> * 2427 MHz [4] (15.0 dBm)
> * 2432 MHz [5] (15.0 dBm)
> * 2437 MHz [6] (15.0 dBm)
> * 2442 MHz [7] (15.0 dBm)
> * 2447 MHz [8] (15.0 dBm)
> * 2452 MHz [9] (15.0 dBm)
> * 2457 MHz [10] (16.0 dBm)
> * 2462 MHz [11] (15.0 dBm)
> * 2467 MHz [12] (15.0 dBm) (passive scanning, no IBSS)
> * 2472 MHz [13] (15.0 dBm) (passive scanning, no IBSS)
> Bitrates (non-HT):
> * 1.0 Mbps
> * 2.0 Mbps (short preamble supported)
> * 5.5 Mbps (short preamble supported)
> * 11.0 Mbps (short preamble supported)
> * 6.0 Mbps
> * 9.0 Mbps
> * 12.0 Mbps
> * 18.0 Mbps
> * 24.0 Mbps
> * 36.0 Mbps
> * 48.0 Mbps
> * 54.0 Mbps
> max # scan SSIDs: 20
> max scan IEs length: 195 bytes
> Coverage class: 0 (up to 0m)
> Supported Ciphers:
> * WEP40 (00-0f-ac:1)
> * WEP104 (00-0f-ac:5)
> * TKIP (00-0f-ac:2)
> * CCMP (00-0f-ac:4)
> Available Antennas: TX 0 RX 0
> Supported interface modes:
> * IBSS
> * managed
> * AP
> * AP/VLAN
> * monitor
> software interface modes (can always be added):
> * AP/VLAN
> * monitor
> valid interface combinations:
> * #{ managed } <= 1, #{ AP } <= 1,
> total <= 2, #channels <= 1, STA/AP BI must match
> * #{ managed } <= 2,
> total <= 2, #channels <= 1
> Supported commands:
> * new_interface
> * set_interface
> * new_key
> * new_beacon
> * new_station
> * new_mpath
> * set_mesh_params
> * set_bss
> * authenticate
> * associate
> * deauthenticate
> * disassociate
> * join_ibss
> * join_mesh
> * set_tx_bitrate_mask
> * action
> * frame_wait_cancel
> * set_wiphy_netns
> * set_channel
> * set_wds_peer
> * Unknown command (84)
> * Unknown command (87)
> * Unknown command (85)
> * Unknown command (89)
> * Unknown command (92)
> * testmode
> * connect
> * disconnect
> Supported TX frame types:
> * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0
> 0xc0 0xd0 0xe0 0xf0
> * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0
> 0xb0 0xc0 0xd0 0xe0 0xf0
> * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0
> 0xc0 0xd0 0xe0 0xf0
> * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0
> 0xb0 0xc0 0xd0 0xe0 0xf0
> * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0
> 0xb0 0xc0 0xd0 0xe0 0xf0
> * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0
> 0xb0 0xc0 0xd0 0xe0 0xf0
> * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0
> 0xb0 0xc0 0xd0 0xe0 0xf0
> * Unknown mode (10): 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80
> 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> Supported RX frame types:
> * IBSS: 0x40 0xb0 0xc0 0xd0
> * managed: 0x40 0xd0
> * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
> * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
> * mesh point: 0xb0 0xc0 0xd0
> * P2P-client: 0x40 0xd0
> * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
> * Unknown mode (10): 0x40 0xd0
> Device supports RSN-IBSS.
> WoWLAN support:
> * wake up on disconnect
> * wake up on magic packet
> * wake up on pattern match, up to 20 patterns of 16-128 bytes
> * can do GTK rekeying
> * wake up on GTK rekey failure
> * wake up on EAP identity request
> * wake up on rfkill release
> HT Capability overrides:
> * MCS: ff ff ff ff ff ff ff ff ff ff
> * maximum A-MSDU length
> * supported channel width
> * short GI for 40 MHz
> * max A-MPDU length exponent
> * min MPDU start spacing
> Device supports TX status socket option.
> Device supports HT-IBSS.
>
> $ lsmod | grep iwlwifi
> iwlwifi 165203 1 iwldvm
> cfg80211 494159 3 iwldvm,mac80211,iwlwifi
>
>
^ permalink raw reply
* Monitor mode stopped working after kernel upgrade
From: Piotr Kaczorek @ 2013-10-25 8:02 UTC (permalink / raw)
To: linux-wireless
Hello,
So far I was using monitor mode on my Debian Lenny with custom 3.2.24
kernel.
I needed support for new hardware so I've compiled a new kernel version
(3.10.12).
I've used the config from old kernel version and set up new kernel
modules (mostly default).
After recompiling the kernel and installing it the monitor mode stopped
returning packets that I got before.
I can see only Beacons, Probe Requests and Probe Responses now (no Data
packets etc...).
The monitor mode is created with airmon-ng start wlan0 (I know there is
already mon.wlan0 at start but I need also the extra headers which the
airmon-ng enables).
Anyway - on both interfaces (mon.wlan0 and mon0) I don't see the
required packets anymore.
The WiFi cards I tried are based on Atheros 2413 (ath5k) or Prism
(p54pci) chipsets.
Both worked before upgrade, none of them works after upgrade.
Any ideas what have changed ?
Maybe I've chosen wrong option in case of one of the new kernel
modules/options ?
Regards,
Piotr
^ permalink raw reply
* Re: iwl3945 filling kern.log when HW switch is off
From: Stanislaw Gruszka @ 2013-10-25 10:04 UTC (permalink / raw)
To: Dan Williams; +Cc: Dietmar Rudolph, linux-wireless
In-Reply-To: <1382626081.4328.3.camel@dcbw.foobar.com>
On Thu, Oct 24, 2013 at 09:48:01AM -0500, Dan Williams wrote:
> On Thu, 2013-10-24 at 13:27 +0200, Stanislaw Gruszka wrote:
> > On Wed, Oct 23, 2013 at 11:24:49AM +0200, Dietmar Rudolph wrote:
> > > Hello, I hope this is the correct place to put a bug report in. I do
> > > not subscribe to this mailing list, but feel free to send PM in case
> > > you need additional info. You shoudn't :-)
> > >
> > > After installing Ubuntu 13.10, I noticed kern.log growing faster
> > > than you could look at. Within a few working hours, kern.log was
> > > >6GB!
> > >
> > > The reason is that I intentionally disabled WiFi on this laptop by
> > > turning the HW switch off. However, this makes iwl3945 write a log
> > > entry into kern.log every few microseconds!
> > >
> > > The workaround is to turn the HW switch on. The bug fix would be to
> > > write just a single line to kern.log.
> >
> > This message is printed when someone try to UP device when RF kill
> > switch is on. Either you did not compile kernel with CONFIG_RFKILL or
> > your user space network management software does not handle rfkill .
>
> Though maybe it shouldn't actually print a dmesg error when that
> happens? Lots of software (scripts included) might try to open the
> device but not really know much about rfkill... Is there a way to print
> it once-per-rfkill instead maybe?
I'll just remove this message. We can return ERFKILL error instead.
That will allow user to identify problem without message.
Thanks
Stanislaw
^ permalink raw reply
* Re: ar5523 Gigaset USB Adapter 108 issue
From: Pontus Fuchs @ 2013-10-25 10:31 UTC (permalink / raw)
To: Yannik Völker, Oleksij Rempel,
linux-wireless@vger.kernel.org
In-Reply-To: <526916A9.2050002@yahoo.de>
> as reported the connection sometimes breakes down, when that happens
> the dmesg contains multiple repetitions of the line
> [ 9577.930431] usb 3-14: ar5523_data_rx_cb: USB err: -2
Hi,
Can you reproduce your problem with debugging enabled for the ar5523 driver:
As root execute:
echo "module ar5523 +p" > /sys/kernel/debug/dynamic_debug/control
Cheers,
Pontus
^ permalink raw reply
* [PATCH] iwl3945: do not print RFKILL message
From: Stanislaw Gruszka @ 2013-10-25 10:37 UTC (permalink / raw)
To: linux-wireless; +Cc: Dietmar Rudolph
We can mess logs if user space try to open device again and again if
RFKILL switch is on. Do not print message and return ERFKILL error
instead to indicate where the problem is.
Note that iwl4965 handle this problem differently, it allows to open
device when radio is disabled.
Reported-by: Dietmar Rudolph <dietmar@crlf.de>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/iwlegacy/3945-mac.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlegacy/3945-mac.c b/drivers/net/wireless/iwlegacy/3945-mac.c
index dea3b50..f7c2145 100644
--- a/drivers/net/wireless/iwlegacy/3945-mac.c
+++ b/drivers/net/wireless/iwlegacy/3945-mac.c
@@ -2396,8 +2396,7 @@ __il3945_up(struct il_priv *il)
clear_bit(S_RFKILL, &il->status);
else {
set_bit(S_RFKILL, &il->status);
- IL_WARN("Radio disabled by HW RF Kill switch\n");
- return -ENODEV;
+ return -ERFKILL;
}
_il_wr(il, CSR_INT, 0xFFFFFFFF);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] iwl3945: do not print RFKILL message
From: Johannes Berg @ 2013-10-25 11:17 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Dietmar Rudolph
In-Reply-To: <20131025103751.GB16384@redhat.com>
On Fri, 2013-10-25 at 12:37 +0200, Stanislaw Gruszka wrote:
> We can mess logs if user space try to open device again and again if
> RFKILL switch is on. Do not print message and return ERFKILL error
> instead to indicate where the problem is.
Are you maybe not calling wiphy_rfkill_set_hw_state() in the right
places?
johannes
^ permalink raw reply
* [PATCH -next 1/2] cw1200: Make the "scan failed" message into a warning
From: Solomon Peachy @ 2013-10-25 22:15 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
The reason that a scan failed for some reason (typically bad
parameters) should be logged even when debugging is turned off.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
drivers/net/wireless/cw1200/scan.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/cw1200/scan.c b/drivers/net/wireless/cw1200/scan.c
index ee3c190..84755ab 100644
--- a/drivers/net/wireless/cw1200/scan.c
+++ b/drivers/net/wireless/cw1200/scan.c
@@ -173,8 +173,9 @@ void cw1200_scan_work(struct work_struct *work)
cw1200_set_pm(priv, &priv->powersave_mode);
if (priv->scan.status < 0)
- wiphy_dbg(priv->hw->wiphy, "[SCAN] Scan failed (%d).\n",
- priv->scan.status);
+ wiphy_warn(priv->hw->wiphy,
+ "[SCAN] Scan failed (%d).\n",
+ priv->scan.status);
else if (priv->scan.req)
wiphy_dbg(priv->hw->wiphy,
"[SCAN] Scan completed.\n");
--
1.8.3.1
^ permalink raw reply related
* [PATCH -next 2/2] wireless: cw1200: Use consistent internal locking conventions
From: Solomon Peachy @ 2013-10-25 22:15 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
In-Reply-To: <1382739343-5727-1-git-send-email-pizza@shaftnet.org>
The cw1200_irq_handler() function expects the hwbus lock to be held when
it is called. On the SDIO platform, this lock is implemented in terms
of sdio_claim_host/sdio_release_host.
This trivial patch makes it explicit that we are performing the hwbus
lock rather than something SDIO-specific.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
drivers/net/wireless/cw1200/cw1200_sdio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/cw1200/cw1200_sdio.c b/drivers/net/wireless/cw1200/cw1200_sdio.c
index ebdcdf4..d3acc85 100644
--- a/drivers/net/wireless/cw1200/cw1200_sdio.c
+++ b/drivers/net/wireless/cw1200/cw1200_sdio.c
@@ -108,9 +108,9 @@ static irqreturn_t cw1200_gpio_irq(int irq, void *dev_id)
struct hwbus_priv *self = dev_id;
if (self->core) {
- sdio_claim_host(self->func);
+ cw1200_sdio_lock(self);
cw1200_irq_handler(self->core);
- sdio_release_host(self->func);
+ cw1200_sdio_unlock(self);
return IRQ_HANDLED;
} else {
return IRQ_NONE;
--
1.8.3.1
^ 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