From: James Cameron <quozl@laptop.org>
To: Bing Zhao <bzhao@marvell.com>
Cc: John Tobias <john.tobias.ph@gmail.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"John W. Linville" <linville@tuxdriver.com>,
Amitkumar Karwar <akarwar@marvell.com>,
Avinash Patil <patila@marvell.com>,
Maithili Hinge <maithili@marvell.com>,
Xinming Hu <huxm@marvell.com>
Subject: Re: [PATCH 2/2] mwifiex: don't clear cmd_sent flag in timeout handler
Date: Fri, 18 Apr 2014 14:46:19 +1000 [thread overview]
Message-ID: <20140418044619.GF24166@us.netrek.org> (raw)
In-Reply-To: <477F20668A386D41ADCC57781B1F70430F70686650@SC-VEXCH1.marvell.com>
On Thu, Apr 17, 2014 at 04:33:58PM -0700, Bing Zhao wrote:
> Hi John,
>
> > Hi Bing,
> >
> > Assuming the timeout happened due to a firmware bug. Does the
> > firmware able to recover after setting adapter->cmd_sent = false
> > and the firmware could accept a new commands without locking?.
>
> That "adapter->cmd_sent = false" was hoping the firmware is still
> alive and can respond to a new command. The reality is that the
> timeout usually indicates the firmware has already hung. Sending
> another command won't recover it in this case.
I'm dealing with a firmware hang when more than 13 nodes are in an
ad-hoc IBSS, and I've just found out isn't entirely a firmware hang;
in that we can see beacons and probe responses from the card, using
tcpdump and monitor mode.
I'm interested to know if the "firmware hangs" that you experiment
with prevent autonomous RF TX, or if RF TX typically proceeds.
> I guess you are using SDIO chip. If your host controller supports
> MMC_POWER_OFF/UP, you can reset the chip with this approach:
>
> mmc_remove_host(host);
> /* some delay */
> mmc_add_host(host);
Thanks, adding that to my list of things to try, as I am using SDIO too.
--
James Cameron
http://quozl.linux.org.au/
next prev parent reply other threads:[~2014-04-18 4:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-17 5:01 [PATCH 1/2] mwifiex: fix IE parsing issues Bing Zhao
2014-04-17 5:01 ` [PATCH 2/2] mwifiex: don't clear cmd_sent flag in timeout handler Bing Zhao
2014-04-17 21:41 ` John Tobias
2014-04-17 23:33 ` Bing Zhao
2014-04-18 4:46 ` James Cameron [this message]
2014-04-18 19:16 ` Bing Zhao
2014-04-19 0:34 ` James Cameron
2014-04-19 0:42 ` John Tobias
2014-04-19 0:48 ` James Cameron
2014-04-24 6:11 ` James Cameron
2014-04-24 7:28 ` Bing Zhao
2014-04-24 16:45 ` John Tobias
2014-04-24 20:48 ` James Cameron
2014-04-24 7:22 ` Bing Zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140418044619.GF24166@us.netrek.org \
--to=quozl@laptop.org \
--cc=akarwar@marvell.com \
--cc=bzhao@marvell.com \
--cc=huxm@marvell.com \
--cc=john.tobias.ph@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=maithili@marvell.com \
--cc=patila@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.