From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Jake Edge <jake@lwn.net>,
linux-wireless@vger.kernel.org,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Bisected 3.9 regression for iwl4965 connection problem to 1672c0e3
Date: Tue, 7 May 2013 10:42:42 +0200 [thread overview]
Message-ID: <20130507084241.GA1581@redhat.com> (raw)
In-Reply-To: <1367855046.8434.16.camel@jlt4.sipsolutions.net>
On Mon, May 06, 2013 at 05:44:06PM +0200, Johannes Berg wrote:
> On Mon, 2013-05-06 at 17:31 +0200, Johannes Berg wrote:
>
> > > But if so, I would also see
> > > the breakage on my setup, but I don't - it works quite well here.
> >
> > Are you testing on a passive channel? Try with a large beacon interval.
>
> I think most likely what happens is that it's on a passive channel, and
> the firmware drops the TX packet with a bad status. Before the patch,
> we'd just wait sitting on the channel for HZ/5 (200ms) before trying
> again, with the patch we immediately retransmit the packet, which will
> fail again and again until the firmware received a beacon.
>
> If you look at iwlwifi/dvm/, it has some passive_no_rx workaround for
> this, which I don't see in iwlegacy.
Can you explain why it is named passive_no_rx instead passive_no_tx ?
> I think the best way to solve this would be to do such a thing in
> iwlegacy as well, but until then and for stable maybe we should
> introduce another HW flag to restore the previous mac80211 behaviour?
I'm not sure if I like to add passive_no_rx to iwlegacy. Stopping queues
and waiting for beacon looks sticky, what happen if beacon will not be
received?
Perhaps I will just remove IEEE80211_HW_REPORTS_TX_ACK_STATUS from 4965,
it's simpler workaround ?
Stanislaw
next prev parent reply other threads:[~2013-05-07 8:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-05 20:38 Bisected 3.9 regression for iwl4965 connection problem to 1672c0e3 Jake Edge
2013-05-06 12:38 ` Stanislaw Gruszka
2013-05-06 14:37 ` Jake Edge
2013-05-06 15:30 ` Stanislaw Gruszka
2013-05-06 15:31 ` Johannes Berg
2013-05-06 15:44 ` Johannes Berg
2013-05-07 8:42 ` Stanislaw Gruszka [this message]
2013-05-07 8:46 ` Emmanuel Grumbach
2013-05-07 13:53 ` Johannes Berg
2013-05-07 15:35 ` Stanislaw Gruszka
2013-05-07 16:07 ` [PATCH 3.10] iwl4965: workaround connection regression on passive channel Stanislaw Gruszka
2013-05-22 11:59 ` Bisected 3.9 regression for iwl4965 connection problem to 1672c0e3 Stanislaw Gruszka
2013-05-24 20:28 ` Johannes Berg
2013-05-06 15:11 ` Johannes Berg
2013-05-06 15:21 ` Jake Edge
2013-05-06 15:24 ` Johannes Berg
2013-05-06 15:29 ` Jake Edge
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=20130507084241.GA1581@redhat.com \
--to=sgruszka@redhat.com \
--cc=jake@lwn.net \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
/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.