* Re: [PATCH] wireless: remove prism54
From: John W. Linville @ 2010-07-22 18:56 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Christian Lamparter
In-Reply-To: <AANLkTikWo6tjyYCDMgoA9WXvbNaWIe_oSp180jcdtWgy@mail.gmail.com>
On Wed, Jul 21, 2010 at 01:58:40PM -0700, Luis R. Rodriguez wrote:
> On Wed, Jul 21, 2010 at 11:05 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > This driver is no longer necessary due to p54pci. It has seen very
> > little maintenance for some time, and at least Fedora has had it
> > disabled without any user complaints.
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> Hm, we had a few users report back that only with prism54 and not
> p54pci could they get their device functional. IIRC Christian noted
> some issues with the EEPROM, and it seems the fault was on the
> manufacturer. My memory may be foggy but indeed I do remember a few
> users did complain about the feature removal plan. I can dig these
> e-mails up if needed.
I think I found some of that in the archive. Do we have any sort of
plan for resolving these EEPROM-related (i.e. missing and/or damaged
EEPROM) issue?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Wireless card on Debian squeeze
From: Nicholas Syrotiuk @ 2010-07-22 18:20 UTC (permalink / raw)
To: linux-wireless
Dear Linux Wireless users,
I'm having some trouble installing the correct driver on my laptop. I'm
slightly confused about the revision numbering of my wireless hardware;
that is, I'm not sure if it's revision 2 or 3.
My kernel is: 2.6.32-5
Relevant output from lspci is:
02:03.0 Network controller [0280]: Broadcom Corporation BCM4306
802.11b/g Wireless LAN Controller [14e4:4320] (rev 02)
Subsystem: Dell TrueMobile 1300 WLAN Mini-PCI Card [1028:0001]
Flags: bus master, fast devsel, latency 32, IRQ 5
Memory at fafee000 (32-bit, non-prefetchable) [size=8K]
Kernel driver in use: b43-pci-bridge
-----------------------------------------------
It looks like I need the b43legacy driver, which comes in a separate
Debian package called "firmware-b43legacy-installer." When I install
this package, computer says: "Not supported card. Use b43 firmware."
When I install b43 firmware, configure the interface and bring it up,
computer says: "Firmware file b43legacy/ucode4.fw not found or load failed."
So, I am slightly confounded. However, it has occurred to me that I may
be getting the packages from the wrong source, which are currently:
deb http://debian.man.ac.uk/debian squeeze main
deb http://ftp.us.debian.org/debian squeeze main contrib
Any ideas?
Cheers, Nick
^ permalink raw reply
* [PATCH] MAINTAINERS: orphan the zd1201 wireless driver
From: John W. Linville @ 2010-07-22 18:42 UTC (permalink / raw)
To: linux-wireless; +Cc: Jeroen Vreeken, linux-usb, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
MAINTAINERS | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 79b0679..220a4ba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5989,10 +5989,9 @@ F: Documentation/video4linux/zc0301.txt
F: drivers/media/video/zc0301/
USB ZD1201 DRIVER
-M: Jeroen Vreeken <pe1rxq@amsat.org>
-L: linux-usb@vger.kernel.org
+L: linux-wireless@vger.kernel.org
W: http://linux-lc100020.sourceforge.net
-S: Maintained
+S: Orphan
F: drivers/net/wireless/zd1201.*
USB ZR364XX DRIVER
--
1.7.1.1
^ permalink raw reply related
* [PATCH] MAINTAINERS: orphan the atmel wireless driver
From: John W. Linville @ 2010-07-22 18:31 UTC (permalink / raw)
To: linux-wireless; +Cc: Simon Kelley, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
MAINTAINERS | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3148b71..2911648 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1170,11 +1170,10 @@ S: Supported
F: drivers/usb/gadget/atmel_usba_udc.*
ATMEL WIRELESS DRIVER
-M: Simon Kelley <simon@thekelleys.org.uk>
L: linux-wireless@vger.kernel.org
W: http://www.thekelleys.org.uk/atmel
W: http://atmelwlandriver.sourceforge.net/
-S: Maintained
+S: Orphan
F: drivers/net/wireless/atmel*
AUDIT SUBSYSTEM
--
1.7.1.1
^ permalink raw reply related
* [PATCH] MAINTAINERS: orphan the raylink wireless driver
From: John W. Linville @ 2010-07-22 18:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Corey Thomas, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
MAINTAINERS | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2911648..79b0679 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4680,9 +4680,8 @@ S: Maintained
F: drivers/rapidio/
RAYLINK/WEBGEAR 802.11 WIRELESS LAN DRIVER
-M: Corey Thomas <coreythomas@charter.net>
L: linux-wireless@vger.kernel.org
-S: Maintained
+S: Orphan
F: drivers/net/wireless/ray*
RCUTORTURE MODULE
--
1.7.1.1
^ permalink raw reply related
* Re: iwlagn and many firmware restarts with Fedora kernel
From: Guy, Wey-Yi @ 2010-07-22 18:37 UTC (permalink / raw)
To: drago01; +Cc: Marcel Holtmann, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTilxa09Cqn3icsTRAULhKBPzv5evOVPTqI-GrYiU@mail.gmail.com>
Hi drago,
On Wed, 2010-07-21 at 14:00 -0700, drago01 wrote:
> On Wed, Jul 21, 2010 at 10:37 PM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
> > Hi drago,
> > On Wed, 2010-07-21 at 12:59 -0700, drago01 wrote:
> >> On Tue, Jul 20, 2010 at 1:56 AM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
> >> > Hi drago,
> >> >
> >> >
> >> > Are you using 5350? here I attach a "RFC patch", could you give a try to
> >> > see if it help?
> >>
> >> Not quite I am on 5300; your patch seem to only touch the 5350 code
> >> ... should I try the same change for 5300?
> >
> > Yes, please
>
> Hi,
>
> As there is no such field in .34 I patched the .35 driver which seems
> to be fine with the change ... I couldn't trigger it using the close
> lid (no suspend) and wait a bit trick ... but I have not used it for
> long enough to say for certain that its gone.
>
> But unfortunately the driver has a different issue it spams my log with tons of:
>
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>
Yes, I aware of this, this is introduced by a recent patch
commit d9763a384216336e180399b69461eae37f6c4f54
I will work on a new patch to help address this.
Thanks
Wey
^ permalink raw reply
* wl1271 with atmel-mci
From: Logan Gunthorpe @ 2010-07-22 18:33 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
Hi Luciano,
I've had the wl1271 working for the most part on an Atmel
micro-controller, but I've been fighting with a bug for the past couple
of days.
The problem happens whenever I try to transmit large packets of data
(using iperf, or nc, etc) the driver would hang and no longer be able to
send packets. tx_queue_len in the debugfs would then grow as I tried to
send packets but nothing would actually be sent to the device. At the
same time receiving packets would consistently work all of the time.
When this occurred I usually got the following messages:
atmel_mci atmel_mci.0: data CRC error
wl1271: ERROR sdio write failed (-84) - addr 0x14fd8, 1076 bytes, 1
(Note: I added the bit at the end of the wl1271 write failed message in
order to try and debug this problem.)
Upon further investigation I found that any calls to sdio_writesb with a
length greater than or equal to 1024 will occasionally fail with a data
CRC error and this would cause the device to stop working.
I have also found that the following ugly hack in wl1271_sdio_raw_write
seems to fix the problem:
if (len <= 1000) {
ret = sdio_writesb(func, addr, buf, len);
} else {
ret = sdio_writesb(func, addr, buf, 1000);
ret |= sdio_writesb(func, addr, &buf[1000], len-1000);
}
Based on the above, I am currently thinking there may be a bug in the
atmel-mci driver that causes this problem. Therefore, I will likely
contact that driver's maintainer next. I was just hoping to get your
insight in case there is something I am missing on the wl1271 side.
Thanks,
Logan
^ permalink raw reply
* [PATCH] atmel: silence sparse warnings
From: John W. Linville @ 2010-07-22 18:24 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK drivers/net/wireless/atmel.c
drivers/net/wireless/atmel.c:3694:30: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3695:31: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3696:30: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3697:32: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3698:30: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3699:31: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3700:30: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3701:32: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3702:32: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3703:30: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3704:32: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3705:32: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3706:28: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3707:29: warning: cast to restricted __le16
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
Is this any better than what we have now??
drivers/net/wireless/atmel.c | 73 ++++++++++++++++++++++++++++++++----------
1 files changed, 56 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/atmel.c b/drivers/net/wireless/atmel.c
index c8f7090..008d712 100644
--- a/drivers/net/wireless/atmel.c
+++ b/drivers/net/wireless/atmel.c
@@ -3617,6 +3617,7 @@ static void atmel_command_irq(struct atmel_private *priv)
static int atmel_wakeup_firmware(struct atmel_private *priv)
{
struct host_info_struct *iface = &priv->host_info;
+ u8 buf[sizeof(struct host_info_struct)];
u16 mr1, mr3;
int i;
@@ -3688,23 +3689,61 @@ static int atmel_wakeup_firmware(struct atmel_private *priv)
return -EIO;
}
- atmel_copy_to_host(priv->dev, (unsigned char *)iface,
- priv->host_info_base, sizeof(*iface));
-
- iface->tx_buff_pos = le16_to_cpu(iface->tx_buff_pos);
- iface->tx_buff_size = le16_to_cpu(iface->tx_buff_size);
- iface->tx_desc_pos = le16_to_cpu(iface->tx_desc_pos);
- iface->tx_desc_count = le16_to_cpu(iface->tx_desc_count);
- iface->rx_buff_pos = le16_to_cpu(iface->rx_buff_pos);
- iface->rx_buff_size = le16_to_cpu(iface->rx_buff_size);
- iface->rx_desc_pos = le16_to_cpu(iface->rx_desc_pos);
- iface->rx_desc_count = le16_to_cpu(iface->rx_desc_count);
- iface->build_version = le16_to_cpu(iface->build_version);
- iface->command_pos = le16_to_cpu(iface->command_pos);
- iface->major_version = le16_to_cpu(iface->major_version);
- iface->minor_version = le16_to_cpu(iface->minor_version);
- iface->func_ctrl = le16_to_cpu(iface->func_ctrl);
- iface->mac_status = le16_to_cpu(iface->mac_status);
+ atmel_copy_to_host(priv->dev, (unsigned char *)&buf,
+ priv->host_info_base, sizeof(buf));
+
+ iface->int_status = buf[offsetof(struct host_info_struct,
+ int_status)];
+ iface->int_mask = buf[offsetof(struct host_info_struct, int_mask)];
+ iface->lockout_host = buf[offsetof(struct host_info_struct,
+ lockout_host)];
+ iface->lockout_mac = buf[offsetof(struct host_info_struct,
+ lockout_mac)];
+ iface->tx_buff_pos =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ tx_buff_pos)]);
+ iface->tx_buff_size =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ tx_buff_size)]);
+ iface->tx_desc_pos =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ tx_desc_pos)]);
+ iface->tx_desc_count =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ tx_desc_count)]);
+ iface->rx_buff_pos =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ rx_buff_pos)]);
+ iface->rx_buff_size =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ rx_buff_size)]);
+ iface->rx_desc_pos =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ rx_desc_pos)]);
+ iface->rx_desc_count =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ rx_desc_count)]);
+ iface->build_version =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ build_version)]);
+ iface->command_pos =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ command_pos)]);
+ iface->major_version =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ major_version)]);
+ iface->minor_version =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ minor_version)]);
+ iface->func_ctrl =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ func_ctrl)]);
+ iface->mac_status =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ mac_status)]);
+ iface->generic_IRQ_type =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ generic_IRQ_type)]);
return 0;
}
--
1.7.1.1
^ permalink raw reply related
* [RFT] airo: silence sparse warnings
From: John W. Linville @ 2010-07-22 18:23 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK drivers/net/wireless/airo.c
drivers/net/wireless/airo.c:2053:24: warning: incorrect type in assignment (different base types)
drivers/net/wireless/airo.c:2053:24: expected restricted __le16 [usertype] status
drivers/net/wireless/airo.c:2053:24: got unsigned short [unsigned] [usertype] status
drivers/net/wireless/airo.c:3247:18: warning: cast to restricted __le16
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
My airo cards seem to have died...or maybe airo is just broken?
drivers/net/wireless/airo.c | 50 +++++++++++++++++++++---------------------
1 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index 053f90c..154554c 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -1042,43 +1042,43 @@ typedef struct {
} HostRidDesc;
typedef struct {
- u16 sw0;
- u16 sw1;
- u16 status;
- u16 len;
-#define HOST_SET (1 << 0)
-#define HOST_INT_TX (1 << 1) /* Interrupt on successful TX */
-#define HOST_INT_TXERR (1 << 2) /* Interrupt on unseccessful TX */
-#define HOST_LCC_PAYLOAD (1 << 4) /* LLC payload, 0 = Ethertype */
-#define HOST_DONT_RLSE (1 << 5) /* Don't release buffer when done */
-#define HOST_DONT_RETRY (1 << 6) /* Don't retry trasmit */
-#define HOST_CLR_AID (1 << 7) /* clear AID failure */
-#define HOST_RTS (1 << 9) /* Force RTS use */
-#define HOST_SHORT (1 << 10) /* Do short preamble */
- u16 ctl;
- u16 aid;
- u16 retries;
- u16 fill;
+ __le16 sw0;
+ __le16 sw1;
+ __le16 status;
+ __le16 len;
+#define HOST_SET cpu_to_le16(1 << 0)
+#define HOST_INT_TX cpu_to_le16(1 << 1) /* Interrupt on successful TX */
+#define HOST_INT_TXERR cpu_to_le16(1 << 2) /* Interrupt on unseccessful TX */
+#define HOST_LCC_PAYLOAD cpu_to_le16(1 << 4) /* LLC payload, 0 = Ethertype */
+#define HOST_DONT_RLSE cpu_to_le16(1 << 5) /* Don't release buffer when done */
+#define HOST_DONT_RETRY cpu_to_le16(1 << 6) /* Don't retry trasmit */
+#define HOST_CLR_AID cpu_to_le16(1 << 7) /* clear AID failure */
+#define HOST_RTS cpu_to_le16(1 << 9) /* Force RTS use */
+#define HOST_SHORT cpu_to_le16(1 << 10) /* Do short preamble */
+ __le16 ctl;
+ __le16 aid;
+ __le16 retries;
+ __le16 fill;
} TxCtlHdr;
typedef struct {
- u16 ctl;
- u16 duration;
+ __le16 ctl;
+ __le16 duration;
char addr1[6];
char addr2[6];
char addr3[6];
- u16 seq;
+ __le16 seq;
char addr4[6];
} WifiHdr;
typedef struct {
TxCtlHdr ctlhdr;
- u16 fill1;
- u16 fill2;
+ __le16 fill1;
+ __le16 fill2;
WifiHdr wifihdr;
- u16 gaplen;
- u16 status;
+ __le16 gaplen;
+ __le16 status;
} WifiCtlHdr;
static WifiCtlHdr wifictlhdr8023 = {
@@ -3244,7 +3244,7 @@ static void airo_handle_link(struct airo_info *ai)
u16 status;
/* Get new status and acknowledge the link change */
- status = le16_to_cpu(IN4500(ai, LINKSTAT));
+ status = IN4500(ai, LINKSTAT);
OUT4500(ai, EVACK, EV_LINK);
if ((status == STAT_FORCELOSS) && (ai->scan_timeout > 0))
--
1.7.1.1
^ permalink raw reply related
* [PATCH] MAINTAINERS: mark prism54 obsolete
From: John W. Linville @ 2010-07-22 18:27 UTC (permalink / raw)
To: linux-wireless; +Cc: Luis R. Rodriguez, John W. Linville
The prism54 driver had an entry in feature-removal-schedule.txt and it
sees very little activity other than API-change "bombing runs". The
mac80211-based p54 driver should be used instead.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
MAINTAINERS | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7faf729..3148b71 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4499,7 +4499,7 @@ PRISM54 WIRELESS DRIVER
M: "Luis R. Rodriguez" <mcgrof@gmail.com>
L: linux-wireless@vger.kernel.org
W: http://prism54.org
-S: Maintained
+S: Obsolete
F: drivers/net/wireless/prism54/
PROMISE DC4030 CACHING DISK CONTROLLER DRIVER
--
1.7.1.1
^ permalink raw reply related
* Re: wl1271 firmware
From: Luciano Coelho @ 2010-07-22 16:34 UTC (permalink / raw)
To: ext Pazzo Da Legare
Cc: linux-wireless@vger.kernel.org, Levi, Shahar, Logan Gunthorpe
In-Reply-To: <AANLkTilZhvGg2SUk5btpQQA3qj2k4rob4rTychDu7gXM@mail.gmail.com>
On Thu, 2010-07-22 at 17:41 +0200, ext Pazzo Da Legare wrote:
> I enabled the DEBUG_LEVEL as you advice me but I have no additional
> information....
>
> [ 186.230000] wl1271_sdio mmc0:0001:2: firmware: requesting
> wl1271-fw.bin
> [ 186.420000] wl1271_sdio mmc0:0001:2: firmware: requesting
> wl1271-nvs.bin
> [ 186.860000] wl1271: firmware booted (Rev 6.1.0.0.310)
> [ 186.880000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 187.380000] wl1271: ERROR ELP wakeup timeout!
> [ 187.880000] wl1271: ERROR ELP wakeup timeout!
There's something wrong. There should have been a lot more traces with
the DEBUG_LEVEL I proposed. Please try again.
--
Cheers,
Luca.
^ permalink raw reply
* How to Get Channel within iw-tool
From: Zhongliang Zhao @ 2010-07-22 16:30 UTC (permalink / raw)
To: linux-wireless; +Cc: Staub Thomas
Hi all,
We have a small system with iw-tool installed, and we wrote a program to
set the channel of wireless interface. However we're currently lost in
the iw web page about how to check the currently used channel of
certain interface, namely the "get channel" functionality.
Does anyone have experience on this or please give us a hint on how to
see which channel the wireless interface is currently using within iw-tool?
Many thanks in advance.
Zhongliang & Thomas
--
Zhongliang Zhao, Research Assistant
Institute of Computer Science and Applied Mathematics
University of Bern, Neubrueckstrasse 10, CH-3012 Bern, Switzerland
Email: zhao@iam.unibe.ch
Phone: +41 (0)31 511 2639
Fax: +41 (0)31 631 3261
^ permalink raw reply
* Re: wl1271 firmware
From: Pazzo Da Legare @ 2010-07-22 15:41 UTC (permalink / raw)
To: Luciano Coelho
Cc: linux-wireless@vger.kernel.org, Levi, Shahar, Logan Gunthorpe
In-Reply-To: <1279780848.2322.31.camel@powerslave>
Dear Luciano,
Dear All,
I enabled the DEBUG_LEVEL as you advice me but I have no additional
information....
[ 186.230000] wl1271_sdio mmc0:0001:2: firmware: requesting
wl1271-fw.bin
[ 186.420000] wl1271_sdio mmc0:0001:2: firmware: requesting
wl1271-nvs.bin
[ 186.860000] wl1271: firmware booted (Rev 6.1.0.0.310)
[ 186.880000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 187.380000] wl1271: ERROR ELP wakeup timeout!
[ 187.880000] wl1271: ERROR ELP wakeup timeout!
Pazzo
2010/7/22 Luciano Coelho <luciano.coelho@nokia.com>:
> Hi Pazzo,
>
>
> On Wed, 2010-07-21 at 19:27 +0200, ext Pazzo Da Legare wrote:
>> Dear All again,
>>
>> I've just test with compact-wireless-2010-07-20 but I've the same problem:
>>
>> root@hawkboard:~# ifconfig wlan0 192.168.0.1 up
>> [ 68.920000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-fw.bin
>> [ 69.100000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-nvs.bin
>> [ 69.510000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> root@hawkboard:~# [ 70.020000] wl1271: ERROR ELP wakeup timeout!
>> [ 70.520000] wl1271: ERROR ELP wakeup timeout!
>>
>>
>> looking at dmesg:
>>
>> [ 68.920000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-fw.bin
>> [ 69.100000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-nvs.bin
>> [ 69.500000] wl1271: firmware booted (Rev 6.1.0.0.310)
>> [ 69.510000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [ 70.020000] wl1271: ERROR ELP wakeup timeout!
>> [ 70.520000] wl1271: ERROR ELP wakeup timeout!
>>
>> [ 68.920000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-fw.bin
>> [ 69.100000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-nvs.bin
>> [ 69.500000] wl1271: firmware booted (Rev 6.1.0.0.310)
>> [ 70.020000] wl1271: ERROR ELP wakeup timeout!
>> [ 70.520000] wl1271: ERROR ELP wakeup timeout!
>>
>> Do you have any clue?
>
> I'm not sure what this is, but usually an ERROR ELP wakeup timeout means
> that the firmware has crashed.
>
> Could you enable the following DEBUG flags in wl1271.h and send the logs
> again? Maybe they provide more clues...
>
> #define DEBUG_LEVEL (DEBUG_BOOT | DEBUG_ACX | DEBUG_CMD | DEBUG_PSM | \
> DEBUG_IRQ | DEBUG_EVENT)
>
>
> --
> Cheers,
> Luca.
>
>
^ permalink raw reply
* [PATCH] mac80211: fix sta assignment
From: Johannes Berg @ 2010-07-22 15:11 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
I just had the following:
WARNING: at drivers/net/wireless/iwlwifi/iwl-agn-tx.c:574 iwlagn_tx_skb+0x1576/0x15f0 [iwlagn]()
Call Trace:
<IRQ> [<ffffffff8105c5df>] warn_slowpath_common+0x7f/0xc0
[<ffffffff8105c63a>] warn_slowpath_null+0x1a/0x20
[<ffffffffa0290b46>] iwlagn_tx_skb+0x1576/0x15f0 [iwlagn]
[<ffffffffa027076c>] iwl_mac_tx+0x5c/0x260 [iwlagn]
[<ffffffffa01bdf5b>] __ieee80211_tx+0x10b/0x1a0 [mac80211]
[<ffffffffa01bfb86>] ieee80211_tx_pending+0x186/0x2d0 [mac80211]
[<ffffffff81062ea5>] tasklet_action+0x125/0x130
[<ffffffff810634a6>] __do_softirq+0x106/0x270
[<ffffffff8100c09c>] call_softirq+0x1c/0x30
iwlagn 0000:02:00.0: Attempting to modify non-existing station 107
Note that 107 == 0x6b which is slab poison.
The reason is that mac80211 passed a freed station
pointer to mac80211, because as it happened iwlwifi
reset itself while mac80211 was disconnecting from
the network.
It turns out that we do take care to look up the
station pointer in ieee80211_tx_pending_skb, but
then don't use it, which obviously is a bug. Fix
this by removing the ieee80211_tx_h_sta handler
and assigning the station pointer directly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/tx.c | 17 +++++------------
1 file changed, 5 insertions(+), 12 deletions(-)
--- wireless-testing.orig/net/mac80211/tx.c 2010-07-22 16:55:47.000000000 +0200
+++ wireless-testing/net/mac80211/tx.c 2010-07-22 16:59:49.000000000 +0200
@@ -576,17 +576,6 @@ ieee80211_tx_h_select_key(struct ieee802
}
static ieee80211_tx_result debug_noinline
-ieee80211_tx_h_sta(struct ieee80211_tx_data *tx)
-{
- struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
-
- if (tx->sta && tx->sta->uploaded)
- info->control.sta = &tx->sta->sta;
-
- return TX_CONTINUE;
-}
-
-static ieee80211_tx_result debug_noinline
ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
@@ -1307,6 +1296,11 @@ static int __ieee80211_tx(struct ieee802
break;
}
+ if (sta && sta->uploaded)
+ info->control.sta = &sta->sta;
+ else
+ info->control.sta = NULL;
+
ret = drv_tx(local, skb);
if (WARN_ON(ret != NETDEV_TX_OK && skb->len != len)) {
dev_kfree_skb(skb);
@@ -1346,7 +1340,6 @@ static int invoke_tx_handlers(struct iee
CALL_TXH(ieee80211_tx_h_check_assoc);
CALL_TXH(ieee80211_tx_h_ps_buf);
CALL_TXH(ieee80211_tx_h_select_key);
- CALL_TXH(ieee80211_tx_h_sta);
if (!(tx->local->hw.flags & IEEE80211_HW_HAS_RATE_CONTROL))
CALL_TXH(ieee80211_tx_h_rate_ctrl);
^ permalink raw reply
* Re: minstrel_tx_status mac80211 WARNINGs in vanilla 2.6.34.1
From: John W. Linville @ 2010-07-22 14:47 UTC (permalink / raw)
To: Sven Geggus; +Cc: netdev, linux-wireless, nbd
In-Reply-To: <20100722123000.GA16657@geggus.net>
On Thu, Jul 22, 2010 at 02:30:01PM +0200, Sven Geggus wrote:
> Hello,
>
> running vanilla 2.6.34.1 I get the following warnings in kernel log:
>
> WARNING: at net/mac80211/rc80211_minstrel.c:70 minstrel_tx_status+0x67/0xd1 [mac80211]()
> Hardware name: SCENIC E300/E600
> Modules linked in: i915 drm_kms_helper drm video backlight output lp loop
> snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm
> snd_seq_dummy zd1211rw snd_seq_oss usbhid mac80211 option cfg80211
> snd_seq_midi usbserial snd_rawmidi snd_seq_midi_event snd_seq snd_timer
> snd_seq_device snd parport_pc ehci_hcd uhci_hcd soundcore intel_agp parport
> usbcore nls_base snd_page_alloc agpgart rng_core floppy sg
> Pid: 0, comm: swapper Tainted: G W 2.6.34.1 #3
> Call Trace:
> [<c102af25>] warn_slowpath_common+0x60/0x90
> [<c102af62>] warn_slowpath_null+0xd/0x10
> [<f83cbd48>] minstrel_tx_status+0x67/0xd1 [mac80211]
> [<f83b6eb1>] ieee80211_tx_status+0x1f6/0x5ac [mac80211]
> [<c1261533>] ? skb_dequeue+0x45/0x4c
> [<f83b6896>] ieee80211_tasklet_handler+0x61/0xd6 [mac80211]
> [<c102ed7d>] tasklet_action+0x62/0x9f
> [<c102f331>] __do_softirq+0x77/0xe5
> [<c102f3c5>] do_softirq+0x26/0x2b
> [<c102f52f>] irq_exit+0x29/0x66
> [<c1003e90>] do_IRQ+0x85/0x9b
> [<c1002d29>] common_interrupt+0x29/0x30
> [<c10083ac>] ? default_idle+0x2d/0x42
> [<c1001a9b>] cpu_idle+0x44/0x71
> [<c12e00de>] rest_init+0x96/0x98
> [<c1498862>] start_kernel+0x2a5/0x2aa
> [<c14980b7>] i386_start_kernel+0xb7/0xbf
> ---[ end trace f22ceacef336878f ]---
>
> Wireless driver is zd1211rw.
>
> Did not test with older kernel because this device has not been in user on
> this machine before.
>
> WLAN does however seem to work anyway.
Well, I just took a quick look -- so, I'm not 100% sure...
But, it looks to me like zd1211rw is reporting tx status on a rate
that minstrel didn't expect it to use. It seems like the hardware
is pre-wired to do retries on sequentially lower rates, which seems
a bit incompatible with minstrel's worldview.
Felix, can we accomodate this? The "WLAN does however seem to work
anyway" seems to suggest things work, so can we at least not yell
about it?
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: 2.6.35-rc5+ WARNING at net/mac80211/scan.c:262
From: Johannes Berg @ 2010-07-22 14:07 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: ilw, linux-wireless
In-Reply-To: <20100722134048.GA28231@isilmar-3.linta.de>
On Thu, 2010-07-22 at 15:40 +0200, Dominik Brodowski wrote:
> > http://johannes.sipsolutions.net/patches/kernel/all/LATEST/NNN-mac80211-hw-scan-locking.patch
>
> patching file drivers/net/wireless/iwlwifi/iwl-core.c
> Hunk #1 succeeded at 2103 (offset 102 lines).
> Hunk #2 FAILED at 2015.
> Hunk #3 succeeded at 2120 (offset 97 lines).
> 1 out of 3 hunks FAILED -- saving rejects to file
> drivers/net/wireless/iwlwifi/iwl-core.c.rej
Oh, it's against wireless-testing, which apparently has some other mods
there. I'll have to see if any other patch needs to go into .35 too.
johannes
^ permalink raw reply
* Re: 2.6.35-rc5+ WARNING at net/mac80211/scan.c:262
From: Dominik Brodowski @ 2010-07-22 13:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: ilw, linux-wireless
In-Reply-To: <1279802055.12439.16.camel@jlt3.sipsolutions.net>
>
> > [82970.511341] ------------[ cut here ]------------
> > [82970.511365] WARNING: at net/mac80211/scan.c:262 ieee80211_scan_completed+0x137/0x1d0()
>
> You don't happen to have a way of reproducing this? I have been
> suspecting races in this area, and came up with this patch to fix them,
No, but as it happened again today, I would be willing to test it out.
> but haven't really validated it yet:
>
> http://johannes.sipsolutions.net/patches/kernel/all/LATEST/NNN-mac80211-hw-scan-locking.patch
patching file drivers/net/wireless/iwlwifi/iwl-core.c
Hunk #1 succeeded at 2103 (offset 102 lines).
Hunk #2 FAILED at 2015.
Hunk #3 succeeded at 2120 (offset 97 lines).
1 out of 3 hunks FAILED -- saving rejects to file
drivers/net/wireless/iwlwifi/iwl-core.c.rej
:(
Best,
Dominik
^ permalink raw reply
* Re: [PATCH] wl1251: fix sparse-generated warnings
From: John W. Linville @ 2010-07-22 13:16 UTC (permalink / raw)
To: Bob Copeland; +Cc: Kalle Valo, Luciano Coelho, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTimh-2cuWdJKgf2TUkCQmGXDC0-86xVhbA-kiPGR@mail.gmail.com>
On Thu, Jul 22, 2010 at 08:04:02AM -0400, Bob Copeland wrote:
> On Thu, Jul 22, 2010 at 3:45 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> >>> @@ -191,11 +191,13 @@ static int wl1251_tx_send_packet(struct wl1251 *wl, struct sk_buff *skb,
> >>> if (control->control.hw_key &&
> >>> control->control.hw_key->alg == ALG_TKIP) {
> >>> int hdrlen;
> >>> - u16 fc;
> >>> + __le16 fc;
> >>> + u16 length;
> >>> u8 *pos;
> [...]
> >>> + length = le16_to_cpu(tx_hdr->length) + WL1251_TKIP_IV_SPACE;
> >>> + tx_hdr->length = cpu_to_le16(length);
> >>
> >> ...which is treated correctly here.
> >
> > This is different. Here we are adding something to a __le16 value, not
> > calculating with pointers.
>
> Just throwing in my 2 cents, unless there's some other reason to add the
> length temporary, here you can just do:
>
> le16_add_cpu(&tx_hdr->length, WL1251_TKIP_IV_SPACE);
Ah, thanks! I thought there was something like that, but I couldn't remember. :-)
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] wl1251: fix sparse-generated warnings
From: John W. Linville @ 2010-07-22 13:21 UTC (permalink / raw)
To: Kalle Valo; +Cc: Luciano Coelho, linux-wireless@vger.kernel.org
In-Reply-To: <4C47F706.4060102@iki.fi>
On Thu, Jul 22, 2010 at 09:45:10AM +0200, Kalle Valo wrote:
> On 07/22/2010 08:34 AM, Luciano Coelho wrote:
> >> @@ -467,7 +467,7 @@ static int wl1251_boot_upload_nvs(struct wl1251 *wl)
> >> val = (nvs_ptr[0] | (nvs_ptr[1] << 8)
> >> | (nvs_ptr[2] << 16) | (nvs_ptr[3] << 24));
> >>
> >> - val = cpu_to_le32(val);
> >> + val = (u32 __force) cpu_to_le32(val);
> >
> > This will work, but such casts always make me a bit suspicious. I think
> > this is fine for now
>
> This line was very suspicious already from beginning, I can't remember
> why it was added and I don't see why it's needed here.
It certainly is a bit strange, and rather ugly as well. I agree that
the write should probably just take the le32 instead, but I was more
interested in silencing sparse than in rewriting a driver for which
I have not hardware. :-)
I could drop that hunk for the time being?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: 2.6.35-rc5+ WARNING at net/mac80211/scan.c:262
From: Johannes Berg @ 2010-07-22 12:34 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: ilw, linux-wireless
In-Reply-To: <20100721184040.GA22968@comet.dominikbrodowski.net>
Hi,
> [82970.511341] ------------[ cut here ]------------
> [82970.511365] WARNING: at net/mac80211/scan.c:262 ieee80211_scan_completed+0x137/0x1d0()
You don't happen to have a way of reproducing this? I have been
suspecting races in this area, and came up with this patch to fix them,
but haven't really validated it yet:
http://johannes.sipsolutions.net/patches/kernel/all/LATEST/NNN-mac80211-hw-scan-locking.patch
johannes
^ permalink raw reply
* [patch -next] libertas: precedence bug
From: Dan Carpenter @ 2010-07-22 12:21 UTC (permalink / raw)
To: Dan Williams
Cc: John W. Linville, Holger Schurig, David S. Miller,
Amitkumar Karwar, Stephen Hemminger, libertas-dev, linux-wireless,
kernel-janitors
Negate has precedence over comparison so the original test was always
false. (Neither 0 nor 1 are equal to NL80211_IFTYPE_MONITOR).
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/wireless/libertas/tx.c b/drivers/net/wireless/libertas/tx.c
index 411a3bb..8000ca6 100644
--- a/drivers/net/wireless/libertas/tx.c
+++ b/drivers/net/wireless/libertas/tx.c
@@ -180,7 +180,7 @@ void lbs_send_tx_feedback(struct lbs_private *priv, u32 try_count)
{
struct tx_radiotap_hdr *radiotap_hdr;
- if (!priv->wdev->iftype == NL80211_IFTYPE_MONITOR ||
+ if (priv->wdev->iftype != NL80211_IFTYPE_MONITOR ||
priv->currenttxskb == NULL)
return;
^ permalink raw reply related
* Re: [PATCH] wl1251: fix sparse-generated warnings
From: Bob Copeland @ 2010-07-22 12:04 UTC (permalink / raw)
To: Kalle Valo
Cc: Luciano Coelho, ext John W. Linville,
linux-wireless@vger.kernel.org
In-Reply-To: <4C47F706.4060102@iki.fi>
On Thu, Jul 22, 2010 at 3:45 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
>>> @@ -191,11 +191,13 @@ static int wl1251_tx_send_packet(struct wl1251 *wl, struct sk_buff *skb,
>>> if (control->control.hw_key &&
>>> control->control.hw_key->alg == ALG_TKIP) {
>>> int hdrlen;
>>> - u16 fc;
>>> + __le16 fc;
>>> + u16 length;
>>> u8 *pos;
[...]
>>> + length = le16_to_cpu(tx_hdr->length) + WL1251_TKIP_IV_SPACE;
>>> + tx_hdr->length = cpu_to_le16(length);
>>
>> ...which is treated correctly here.
>
> This is different. Here we are adding something to a __le16 value, not
> calculating with pointers.
Just throwing in my 2 cents, unless there's some other reason to add the
length temporary, here you can just do:
le16_add_cpu(&tx_hdr->length, WL1251_TKIP_IV_SPACE);
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH] cfg80211: fix IBSS default management key
From: Johannes Berg @ 2010-07-22 11:59 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
When wireless extensions are used to control
an encrypted IBSS, we erroneously can try to
set the default management key. Fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/ibss.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- wireless-testing.orig/net/wireless/ibss.c 2010-07-22 12:28:15.000000000 +0200
+++ wireless-testing/net/wireless/ibss.c 2010-07-22 12:28:27.000000000 +0200
@@ -247,8 +247,10 @@ int cfg80211_ibss_wext_join(struct cfg80
if (!netif_running(wdev->netdev))
return 0;
- if (wdev->wext.keys)
+ if (wdev->wext.keys) {
wdev->wext.keys->def = wdev->wext.default_key;
+ wdev->wext.keys->defmgmt = wdev->wext.default_mgmt_key;
+ }
wdev->wext.ibss.privacy = wdev->wext.default_key != -1;
^ permalink raw reply
* [PATCH] mac80211: remove bogus rcu_read_lock()
From: Johannes Berg @ 2010-07-22 11:58 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
Another remnant of the previous key locking scheme
needs to be removed -- this causes a warning
otherwise as ieee80211_set_default_mgmt_key will
acquire a mutex.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/cfg.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
--- wireless-testing.orig/net/mac80211/cfg.c 2010-07-22 12:24:38.000000000 +0200
+++ wireless-testing/net/mac80211/cfg.c 2010-07-22 13:56:19.000000000 +0200
@@ -324,15 +324,10 @@ static int ieee80211_config_default_mgmt
struct net_device *dev,
u8 key_idx)
{
- struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
- rcu_read_lock();
-
- sdata = IEEE80211_DEV_TO_SUB_IF(dev);
ieee80211_set_default_mgmt_key(sdata, key_idx);
- rcu_read_unlock();
-
return 0;
}
^ permalink raw reply
* Re: [PATCH v2 18/20] mmc: sdio: enable a default power off mode of the card
From: Roger Quadros @ 2010-07-22 11:35 UTC (permalink / raw)
To: ext Ohad Ben-Cohen
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat, Tony Lindgren, Nicolas Pitre, Pandita Vikram,
Kalle Valo
In-Reply-To: <1279733634-21974-19-git-send-email-ohad@wizery.com>
On 07/21/2010 08:33 PM, ext Ohad Ben-Cohen wrote:
> Add support for an SDIO device to stay powered off even without
> the presence of an SDIO function driver. A host should explicitly
> ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO
> function driver should know it needs to call sdio_claim_power
> before accessing the device.
>
> Signed-off-by: Ohad Ben-Cohen<ohad@wizery.com>
Shouldn't this be the default behaviour? If there is no function driver for any
of the functions of the card, then sdio core shold power off the card.
I don't see a need for a special capability flag for this.
in fact MMC_CAP_DONT_POWER_CARD does not seem like an mmc host's capability
flag, it seems more like a request from the board to keep the card powered off.
regards,
-roger
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox