From: Solomon Peachy <pizza@shaftnet.org>
To: Bartosz Markowski <markowski.bartosz@gmail.com>
Cc: linux-wireless@vger.kernel.org, Pontus Fuchs <pontus.fuchs@gmail.com>
Subject: Re: [PATCH 06/17] cw1200: Mini-AP implementation
Date: Sun, 23 Dec 2012 11:44:09 -0500 [thread overview]
Message-ID: <20121223164408.GA3624@shaftnet.org> (raw)
In-Reply-To: <CAM8CFPj==UdTjCe0=hPRtT_BC1E4TvRFDjqBZUD4=c+PbkncVA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
On Sun, Dec 23, 2012 at 04:49:05PM +0100, Bartosz Markowski wrote:
> Are you using this bss loss evt subscription? It was under STE_EXTENSIONS
> if I good remember. This is part of STE CQM design. But answering to the
> question FW should not spam with loss/regained events like that and if I
> good remember (I do not work with this for more than 6 months now) this
> behave quite well those days. I do not know lmac internals however , Ive
> used to work with the driver only.
This "spamming" isn't a problem using the GPL driver thanks to its
hysterisis and delays.
From my own investigations into the LMAC sources, that event is
triggered by an internal LMAC timer if it hasn't received a beacon at
all in that time. Disabling powersave operation makes the problem go
away entirely, so I suspect what's happening is that the LMAC is
consistently waking up a little too late (or going back to sleep too
early) to hear the beacons.
My guess is that the LMAC is pushing its powersaving margins too close.
> Btw. how old is the fw bin you have?
I'm using WSM395 currently, dated June 18 2012. (It fixed a problem
that a client of ours observed with WSM392 and WSM385; the LMAC would
lock up on noisy environments when block acks were in use)
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Melbourne, FL ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
next prev parent reply other threads:[~2012-12-23 16:44 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-22 15:45 RFC: Driver ST-E cw1200 driver Solomon Peachy
2012-12-22 15:45 ` [PATCH 01/17] cw1200: Low-level hardware I/O functions Solomon Peachy
2012-12-22 15:45 ` [PATCH 02/17] cw1200: Internal tx queue tracking and handling Solomon Peachy
2012-12-22 15:45 ` [PATCH 03/17] cw1200: Scan implementation Solomon Peachy
2012-12-22 15:45 ` [PATCH 04/17] cw1200: Power management (ie psuedo-WoWLAN) Solomon Peachy
2012-12-22 15:45 ` [PATCH 05/17] cw1200: Firmware loading code Solomon Peachy
2012-12-22 15:45 ` [PATCH 06/17] cw1200: Mini-AP implementation Solomon Peachy
2012-12-22 19:59 ` Pontus Fuchs
2012-12-22 21:22 ` Solomon Peachy
2012-12-22 22:34 ` Solomon Peachy
[not found] ` <CAM8CFPgJu5CR9tU_mMw1_0yDUEj-dLk2G+6W91W1-H4LMa+BUw@mail.gmail.com>
2012-12-23 12:47 ` Solomon Peachy
[not found] ` <CAM8CFPj==UdTjCe0=hPRtT_BC1E4TvRFDjqBZUD4=c+PbkncVA@mail.gmail.com>
2012-12-23 16:44 ` Solomon Peachy [this message]
2012-12-27 8:48 ` Kalle Valo
2012-12-27 14:07 ` Solomon Peachy
2012-12-22 15:45 ` [PATCH 07/17] cw1200: debuging hooks (using debugfs) Solomon Peachy
2012-12-22 15:45 ` [PATCH 08/17] cw1200: Optional Hooks for one of ST-E's testing tools Solomon Peachy
2012-12-22 15:45 ` [PATCH 09/17] cw1200: 802.11 STA API Solomon Peachy
2012-12-22 15:45 ` [PATCH 10/17] cw1200: Packet transmit and receive handling Solomon Peachy
2012-12-22 15:45 ` [PATCH 11/17] cw1200: WSM (ie host-firmware) host interface Solomon Peachy
2012-12-22 15:45 ` [PATCH 12/17] cw1200: Main processing loop Solomon Peachy
2012-12-22 15:45 ` [PATCH 13/17] cw1200: common registration/setup code Solomon Peachy
2012-12-22 15:45 ` [PATCH 14/17] cw1200: driver state and definitions Solomon Peachy
2012-12-22 15:45 ` [PATCH 15/17] cw1200: SDIO and SPI glue code, plus platform data Solomon Peachy
2012-12-22 15:45 ` [PATCH 16/17] cw1200: Integration into the kernel build system Solomon Peachy
2012-12-22 20:19 ` Johannes Berg
2012-12-22 20:32 ` Solomon Peachy
2012-12-22 15:45 ` [PATCH 17/17] cw1200: Integrate into staging tree Solomon Peachy
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=20121223164408.GA3624@shaftnet.org \
--to=pizza@shaftnet.org \
--cc=linux-wireless@vger.kernel.org \
--cc=markowski.bartosz@gmail.com \
--cc=pontus.fuchs@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).