Whenever this problem occurs, the driver can not continue. Thus,
trigger a card reset to restart the module firmware. Other firmware
communication issues are resolved by this last resort.
Also dump registers, to eventually allow some diagnostics.
Signed-off-by: Florian Achleitner f...@fopen.at
Hi Florian,
Hi,
we are using a Marvell SD8787-based module by Lesswire, which is
connected to an imx28 through sdio. We are testing with the most recent
kernel from wireless-drivers-next and Firmware 14.66.35.p52.
Frequently, we see 'glitches' between driver and Firmware. The most
Hi Amit,
2015-04-13 12:27 GMT+02:00 Amitkumar Karwar akar...@marvell.com:
We had recently submitted a patch to address this issue. So these two patches
won't be needed now.
http://www.spinics.net/lists/linux-wireless/msg135146.html
Could you please check and let us know if you have any
Hi,
we are using a Marvell SD8787-based module by Lesswire, which is connected to
an imx28 through sdio. We are testing with the most recent kernel from
wireless-drivers-next and Firmware 14.66.35.p52.
Frequently, we see 'glitches' between driver and Firmware. The most recent
driver answers
On Thu, Apr 16, 2015 at 11:10:02AM +0200, Florian Achleitner wrote:
Is the necessity of frequent hardware resets a commonly known issue
with this chip/firmware? Anybody else experiencing these?
Yes, but how frequent?
Currently, we see three different scenarios. One of them is
currently not
On Thu, 2015-04-16 at 13:15 +0800, Chun-Yeow Yeoh wrote:
User managed peering has no way to block the plink state
for mesh peering setup by wpa_supp or authsae. Try to do
allow this in kernel space, so that we can use iw utility
to do that.
I have no idea what you're trying to say here.
Hi Florian,
On Thursday 16 April 2015 02:30:59 Amitkumar Karwar wrote:
[...]
We haven't seen this behavior yet. Could you please share complete
log?
Logs follow per scenario.
(1) mwifiex_cmd_timeout_func: Timeout cmd .. Ok, after reset.
[164276.211216] mwifiex_sdio mmc0:0001:1:
On Thursday 16 April 2015 20:19:13 James Cameron wrote:
On Thu, Apr 16, 2015 at 11:10:02AM +0200, Florian Achleitner wrote:
Is the necessity of frequent hardware resets a commonly known issue
with this chip/firmware? Anybody else experiencing these?
Yes, but how frequent?
Depends on the
On Thursday 16 April 2015 02:30:59 Amitkumar Karwar wrote:
[...]
We haven't seen this behavior yet. Could you please share complete log?
Logs follow per scenario.
(1) mwifiex_cmd_timeout_func: Timeout cmd .. Ok, after reset.
[164276.211216] mwifiex_sdio mmc0:0001:1: host_to_card, write iomem
On 2015-04-16 04:24, miaoq...@qti.qualcomm.com wrote:
From: Miaoqing Pan miaoq...@qca.qualcomm.com
BUG: soft lockup - CPU#0 stuck for 22s! [hostapd:965]
CPU: 0 PID: 965 Comm: hostapd Not tainted 3.14.0 #1
task: 82e29c40 ti: 82fb2000 task.ti: 82fb2000
$ 0 : 83281f90
On Wed, Apr 15, 2015 at 9:35 PM, Janusz Dziedzic
janusz.dzied...@tieto.com wrote:
On 15 April 2015 at 19:10, YanBo dreamfly...@gmail.com wrote:
On Tue, Apr 14, 2015 at 10:00 PM, Janusz Dziedzic
janusz.dzied...@tieto.com wrote:
On 15 April 2015 at 00:45, YanBo dreamfly...@gmail.com wrote:
On
Hi Avanish, Amitkumar,
Thx for your ideas to check the mmc interface.
On Thursday 16 April 2015 04:21:50 Amitkumar Karwar wrote:
host_to_card, write iomem (1) failed: -110 error indicates that MMC
subsystem's sdio_writesb() API failed with timeout error.
WLAN driver or FW has nothing to do
On 04/07/2015 08:25 PM, Sujith Manoharan wrote:
Ben Greear wrote:
For the third set, why limit to a single interface. Can't we run IBSS + AP
(and plus stations, for that matter), all at the same time with ath9k?
TSF would jump around since the HW would sync with the
received beacons and
13 matches
Mail list logo
