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>, Chris Ball <cjb@laptop.org>
Subject: Re: [PATCH 2/2] mwifiex: don't clear cmd_sent flag in timeout handler
Date: Thu, 24 Apr 2014 16:11:37 +1000 [thread overview]
Message-ID: <20140424061137.GN1947@us.netrek.org> (raw)
In-Reply-To: <20140419003410.GB14606@us.netrek.org>
On Sat, Apr 19, 2014 at 10:34:10AM +1000, James Cameron wrote:
> On Fri, Apr 18, 2014 at 12:16:07PM -0700, Bing Zhao wrote:
> > Hi James,
> >
> > > > 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.
> >
> > It depends. Even if firmware hangs the hardware is still alive.
> > So you could see beacons and probe responses from the card if
> > hardware has been programmed before firmware hangs.
>
> Thanks. I neglected to mention the time period; beacons and probe
> responses are seen for many minutes after the timeout report by the
> driver, and I have not yet tested for how long this lasts. The
> probe responses are in reply to new probe requests. It makes me
> think the card is working fine, apart from not communicating with
> the host.
Downgrading wireless firmware to 14.66.9.p80 has fixed this problem.
--
James Cameron
http://quozl.linux.org.au/
next prev parent reply other threads:[~2014-04-24 6:11 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
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 [this message]
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=20140424061137.GN1947@us.netrek.org \
--to=quozl@laptop.org \
--cc=akarwar@marvell.com \
--cc=bzhao@marvell.com \
--cc=cjb@laptop.org \
--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.