After sending the first 2MB, scp over wireless becomes unbearably slow,
with frequent stalls: on this ThinkPad T420s running 3.8-rc4 or 3.7.3.
Not always, but often.
Bisection led to commit f590dcec944552f9a4a61155810f3abd17d6465d
"iwlwifi: fix the reclaimed packet tracking upon flush queue"
(below); and indeed backing that out brings them back to speed.
Here are the "iwlwifi" lines from my dmesg:
[ 1.936640] iwlwifi 0000:03:00.0: irq 44 for MSI/MSI-X
[ 8.384905] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1 build 25532
[ 8.406425] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG disabled
[ 8.427099] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[ 8.447888] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[ 8.468369] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
[ 8.489008] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P disabled
[ 8.509588] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74
[ 8.531309] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 9.891162] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 9.891399] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[ 10.260205] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 10.260405] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
Thanks,
Hugh
commit f590dcec944552f9a4a61155810f3abd17d6465d
Author: Emmanuel Grumbach <[email protected]>
Date: Mon Dec 31 09:26:10 2012 +0200
iwlwifi: fix the reclaimed packet tracking upon flush queue
There's a bug in the currently released firmware version,
the sequence control in the Tx response isn't updated in
all cases. Take it from the packet as a workaround.
Cc: [email protected]
Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
diff --git a/drivers/net/wireless/iwlwifi/dvm/tx.c b/drivers/net/wireless/iwlwifi/dvm/tx.c
index da21328..a790599 100644
--- a/drivers/net/wireless/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/dvm/tx.c
@@ -1151,13 +1151,6 @@ int iwlagn_rx_reply_tx(struct iwl_priv *priv, struct iwl_rx_cmd_buffer *rxb,
next_reclaimed = ssn;
}
- if (tid != IWL_TID_NON_QOS) {
- priv->tid_data[sta_id][tid].next_reclaimed =
- next_reclaimed;
- IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
- next_reclaimed);
- }
-
iwl_trans_reclaim(priv->trans, txq_id, ssn, &skbs);
iwlagn_check_ratid_empty(priv, sta_id, tid);
@@ -1208,11 +1201,28 @@ int iwlagn_rx_reply_tx(struct iwl_priv *priv, struct iwl_rx_cmd_buffer *rxb,
if (!is_agg)
iwlagn_non_agg_tx_status(priv, ctx, hdr->addr1);
+ /*
+ * W/A for FW bug - the seq_ctl isn't updated when the
+ * queues are flushed. Fetch it from the packet itself
+ */
+ if (!is_agg && status == TX_STATUS_FAIL_FIFO_FLUSHED) {
+ next_reclaimed = le16_to_cpu(hdr->seq_ctrl);
+ next_reclaimed =
+ SEQ_TO_SN(next_reclaimed + 0x10);
+ }
+
is_offchannel_skb =
(info->flags & IEEE80211_TX_CTL_TX_OFFCHAN);
freed++;
}
+ if (tid != IWL_TID_NON_QOS) {
+ priv->tid_data[sta_id][tid].next_reclaimed =
+ next_reclaimed;
+ IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
+ next_reclaimed);
+ }
+
WARN_ON(!is_agg && freed != 1);
/*
On Sun, 20 Jan 2013, Grumbach, Emmanuel wrote:
> >
> > On Sun, Jan 20, 2013 at 6:56 AM, Hugh Dickins <[email protected]> wrote:
> > > After sending the first 2MB, scp over wireless becomes unbearably
> > > slow, with frequent stalls: on this ThinkPad T420s running 3.8-rc4 or 3.7.3.
> > > Not always, but often.
> > >
> >
> > There is one pending iwlwifi-fixes, dunno if it will fix your issue.
> > [1] http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-
> > fixes.git;a=commitdiff;h=c3e5d7181afb66657393066bccce0956fab09ab3
>
> Right - so the 2 patches are unrelated, and the one Sedat is pointing at is relevant for 3.8 only. It fixes a bug that has been introduced in 3.8.
Yes, I have now given that one a try, but it does not affect my issue.
> Regarding the issue Hugh is suffering from, I have to say that I am a little confused since I am pretty sure the patch is right. Now, it might uncover other pre-existing bugs. All I can say is that I don't think that reverting the patch is *so* problematic since the patch really wants to solve a rare case. If it causes issues, we can simply revert it. It only means that when I will get a little bit of time, I might need to ask you a few logs. Thanks for the report (and the bisection).
Sure, let me know what to do, once you have time to investigate.
So far as I know, I'm the first to notice: so we can probably
leave it in 3.8-rc for now, until/unless it gives wider trouble.
But reverting from 3.7-stable soon would be a good idea,
regressions there being more tiresome.
Hugh
On Sun, Jan 20, 2013 at 6:56 AM, Hugh Dickins <[email protected]> wrote:
> After sending the first 2MB, scp over wireless becomes unbearably slow,
> with frequent stalls: on this ThinkPad T420s running 3.8-rc4 or 3.7.3.
> Not always, but often.
>
There is one pending iwlwifi-fixes, dunno if it will fix your issue.
- Sedat -
[1] http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-fixes.git;a=commitdiff;h=c3e5d7181afb66657393066bccce0956fab09ab3
> Bisection led to commit f590dcec944552f9a4a61155810f3abd17d6465d
> "iwlwifi: fix the reclaimed packet tracking upon flush queue"
> (below); and indeed backing that out brings them back to speed.
>
> Here are the "iwlwifi" lines from my dmesg:
> [ 1.936640] iwlwifi 0000:03:00.0: irq 44 for MSI/MSI-X
> [ 8.384905] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1 build 25532
> [ 8.406425] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG disabled
> [ 8.427099] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
> [ 8.447888] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
> [ 8.468369] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
> [ 8.489008] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P disabled
> [ 8.509588] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74
> [ 8.531309] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
> [ 9.891162] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
> [ 9.891399] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
> [ 10.260205] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
> [ 10.260405] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
>
> Thanks,
> Hugh
>
> commit f590dcec944552f9a4a61155810f3abd17d6465d
> Author: Emmanuel Grumbach <[email protected]>
> Date: Mon Dec 31 09:26:10 2012 +0200
>
> iwlwifi: fix the reclaimed packet tracking upon flush queue
>
> There's a bug in the currently released firmware version,
> the sequence control in the Tx response isn't updated in
> all cases. Take it from the packet as a workaround.
>
> Cc: [email protected]
> Signed-off-by: Emmanuel Grumbach <[email protected]>
> Signed-off-by: Johannes Berg <[email protected]>
>
> diff --git a/drivers/net/wireless/iwlwifi/dvm/tx.c b/drivers/net/wireless/iwlwifi/dvm/tx.c
> index da21328..a790599 100644
> --- a/drivers/net/wireless/iwlwifi/dvm/tx.c
> +++ b/drivers/net/wireless/iwlwifi/dvm/tx.c
> @@ -1151,13 +1151,6 @@ int iwlagn_rx_reply_tx(struct iwl_priv *priv, struct iwl_rx_cmd_buffer *rxb,
> next_reclaimed = ssn;
> }
>
> - if (tid != IWL_TID_NON_QOS) {
> - priv->tid_data[sta_id][tid].next_reclaimed =
> - next_reclaimed;
> - IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
> - next_reclaimed);
> - }
> -
> iwl_trans_reclaim(priv->trans, txq_id, ssn, &skbs);
>
> iwlagn_check_ratid_empty(priv, sta_id, tid);
> @@ -1208,11 +1201,28 @@ int iwlagn_rx_reply_tx(struct iwl_priv *priv, struct iwl_rx_cmd_buffer *rxb,
> if (!is_agg)
> iwlagn_non_agg_tx_status(priv, ctx, hdr->addr1);
>
> + /*
> + * W/A for FW bug - the seq_ctl isn't updated when the
> + * queues are flushed. Fetch it from the packet itself
> + */
> + if (!is_agg && status == TX_STATUS_FAIL_FIFO_FLUSHED) {
> + next_reclaimed = le16_to_cpu(hdr->seq_ctrl);
> + next_reclaimed =
> + SEQ_TO_SN(next_reclaimed + 0x10);
> + }
> +
> is_offchannel_skb =
> (info->flags & IEEE80211_TX_CTL_TX_OFFCHAN);
> freed++;
> }
>
> + if (tid != IWL_TID_NON_QOS) {
> + priv->tid_data[sta_id][tid].next_reclaimed =
> + next_reclaimed;
> + IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
> + next_reclaimed);
> + }
> +
> WARN_ON(!is_agg && freed != 1);
>
> /*
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
PiANCj4gT24gU3VuLCBKYW4gMjAsIDIwMTMgYXQgNjo1NiBBTSwgSHVnaCBEaWNraW5zIDxodWdo
ZEBnb29nbGUuY29tPiB3cm90ZToNCj4gPiBBZnRlciBzZW5kaW5nIHRoZSBmaXJzdCAyTUIsIHNj
cCBvdmVyIHdpcmVsZXNzIGJlY29tZXMgdW5iZWFyYWJseQ0KPiA+IHNsb3csIHdpdGggZnJlcXVl
bnQgc3RhbGxzOiBvbiB0aGlzIFRoaW5rUGFkIFQ0MjBzIHJ1bm5pbmcgMy44LXJjNCBvciAzLjcu
My4NCj4gPiBOb3QgYWx3YXlzLCBidXQgb2Z0ZW4uDQo+ID4NCj4gDQo+IFRoZXJlIGlzIG9uZSBw
ZW5kaW5nIGl3bHdpZmktZml4ZXMsIGR1bm5vIGlmIGl0IHdpbGwgZml4IHlvdXIgaXNzdWUuDQo+
IFsxXSBodHRwOi8vZ2l0Lmtlcm5lbC5vcmcvP3A9bGludXgva2VybmVsL2dpdC9pd2x3aWZpL2l3
bHdpZmktDQo+IGZpeGVzLmdpdDthPWNvbW1pdGRpZmY7aD1jM2U1ZDcxODFhZmI2NjY1NzM5MzA2
NmJjY2NlMDk1NmZhYjA5YWIzDQoNClJpZ2h0IC0gc28gdGhlIDIgcGF0Y2hlcyBhcmUgdW5yZWxh
dGVkLCBhbmQgdGhlIG9uZSBTZWRhdCBpcyBwb2ludGluZyBhdCBpcyByZWxldmFudCBmb3IgMy44
IG9ubHkuIEl0IGZpeGVzIGEgYnVnIHRoYXQgaGFzIGJlZW4gaW50cm9kdWNlZCBpbiAzLjguDQpS
ZWdhcmRpbmcgdGhlIGlzc3VlIEh1Z2ggaXMgc3VmZmVyaW5nIGZyb20sIEkgaGF2ZSB0byBzYXkg
dGhhdCBJIGFtIGEgbGl0dGxlIGNvbmZ1c2VkIHNpbmNlIEkgYW0gcHJldHR5IHN1cmUgdGhlIHBh
dGNoIGlzIHJpZ2h0LiBOb3csIGl0IG1pZ2h0IHVuY292ZXIgb3RoZXIgcHJlLWV4aXN0aW5nIGJ1
Z3MuIEFsbCBJIGNhbiBzYXkgaXMgdGhhdCBJIGRvbid0IHRoaW5rIHRoYXQgcmV2ZXJ0aW5nIHRo
ZSBwYXRjaCBpcyAqc28qIHByb2JsZW1hdGljIHNpbmNlIHRoZSBwYXRjaCByZWFsbHkgd2FudHMg
dG8gc29sdmUgYSByYXJlIGNhc2UuIElmIGl0IGNhdXNlcyBpc3N1ZXMsIHdlIGNhbiBzaW1wbHkg
cmV2ZXJ0IGl0LiBJdCBvbmx5IG1lYW5zIHRoYXQgd2hlbiBJIHdpbGwgZ2V0IGEgbGl0dGxlIGJp
dCBvZiB0aW1lLCBJIG1pZ2h0IG5lZWQgdG8gYXNrIHlvdSBhIGZldyBsb2dzLiBUaGFua3MgZm9y
IHRoZSByZXBvcnQgKGFuZCB0aGUgYmlzZWN0aW9uKS4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpBIG1lbWJlciBv
ZiB0aGUgSW50ZWwgQ29ycG9yYXRpb24gZ3JvdXAgb2YgY29tcGFuaWVzCgpUaGlzIGUtbWFpbCBh
bmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBtYXRlcmlhbCBmb3IK
dGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcgb3Ig
ZGlzdHJpYnV0aW9uCmJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJl
IG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFu
ZCBkZWxldGUgYWxsIGNvcGllcy4K
> > > > On Sun, Jan 20, 2013 at 6:56 AM, Hugh Dickins <[email protected]>
> wrote:
> > > > > After sending the first 2MB, scp over wireless becomes
> > > > > unbearably slow, with frequent stalls: on this ThinkPad T420s running
> 3.8-rc4 or 3.7.3.
> > > > > Not always, but often.
> > > > >
> > > >
> > > > There is one pending iwlwifi-fixes, dunno if it will fix your issue.
> > > > [1] http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-
> > > > fixes.git;a=commitdiff;h=c3e5d7181afb66657393066bccce0956fab09ab3
> > >
> > > Right - so the 2 patches are unrelated, and the one Sedat is pointing at is
> relevant for 3.8 only. It fixes a bug that has been introduced in 3.8.
> >
> > Yes, I have now given that one a try, but it does not affect my issue.
> >
> > > Regarding the issue Hugh is suffering from, I have to say that I am a little
> confused since I am pretty sure the patch is right. Now, it might uncover other
> pre-existing bugs. All I can say is that I don't think that reverting the patch is
> *so* problematic since the patch really wants to solve a rare case. If it causes
> issues, we can simply revert it. It only means that when I will get a little bit of
> time, I might need to ask you a few logs. Thanks for the report (and the
> bisection).
> >
> > Sure, let me know what to do, once you have time to investigate.
> >
> > So far as I know, I'm the first to notice: so we can probably leave it
> > in 3.8-rc for now, until/unless it gives wider trouble.
> >
> > But reverting from 3.7-stable soon would be a good idea, regressions
> > there being more tiresome.
>
> I'm seeing iwlwifi performance problems in 3.8 as well, and have heard from
> several other saying the same thing. Testing with iperf shows very little data
> getting through most of the time.
>
> Reverting f590dcec944552f9a4a61155810f3abd17d6465d on top of 3.8-rc6
> seems to have eliminated the problems for me, so far at least. I'll request some
> testing from others as well.
>
> Seth
So the revert patch is on its way: http://git.kernel.org/?p=linux/kernel/git/davem/net.git;a=commit;h=ae023b2795d36f0f077e157428eb7eafa29ee412
---------------------------------------------------------------------
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
On Sat, Jan 19, 2013 at 11:40:24PM -0800, Hugh Dickins wrote:
> On Sun, 20 Jan 2013, Grumbach, Emmanuel wrote:
> > >
> > > On Sun, Jan 20, 2013 at 6:56 AM, Hugh Dickins <[email protected]> wrote:
> > > > After sending the first 2MB, scp over wireless becomes unbearably
> > > > slow, with frequent stalls: on this ThinkPad T420s running 3.8-rc4 or 3.7.3.
> > > > Not always, but often.
> > > >
> > >
> > > There is one pending iwlwifi-fixes, dunno if it will fix your issue.
> > > [1] http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-
> > > fixes.git;a=commitdiff;h=c3e5d7181afb66657393066bccce0956fab09ab3
> >
> > Right - so the 2 patches are unrelated, and the one Sedat is pointing at is relevant for 3.8 only. It fixes a bug that has been introduced in 3.8.
>
> Yes, I have now given that one a try, but it does not affect my issue.
>
> > Regarding the issue Hugh is suffering from, I have to say that I am a little confused since I am pretty sure the patch is right. Now, it might uncover other pre-existing bugs. All I can say is that I don't think that reverting the patch is *so* problematic since the patch really wants to solve a rare case. If it causes issues, we can simply revert it. It only means that when I will get a little bit of time, I might need to ask you a few logs. Thanks for the report (and the bisection).
>
> Sure, let me know what to do, once you have time to investigate.
>
> So far as I know, I'm the first to notice: so we can probably
> leave it in 3.8-rc for now, until/unless it gives wider trouble.
>
> But reverting from 3.7-stable soon would be a good idea,
> regressions there being more tiresome.
I'm seeing iwlwifi performance problems in 3.8 as well, and have heard
from several other saying the same thing. Testing with iperf shows very
little data getting through most of the time.
Reverting f590dcec944552f9a4a61155810f3abd17d6465d on top of 3.8-rc6
seems to have eliminated the problems for me, so far at least. I'll
request some testing from others as well.
Seth