I've testing for another day and can now clarify/correct the description of the problem.

With the 22.24.8.0 firmware:
The AP disconnects don't seem to happen like I originally stated.
The iwconfig Link Quality and Signal Level metrics aren't low like I originally stated.
The command "ping -f -c 3000 192.168.1.1" takes more than a minute to complete with above 15% packet loss.

With the 22.1.7.0 firmware:
The command "ping -f -c 3000 192.168.1.1" takes under 6 seconds to complete with 0% packet loss.

After reading https://bugzilla.kernel.org/show_bug.cgi?id=72601, I attempted to get a iwlwifi driver trace, but it appears that support is not enabled in the fedora kernel.

There is no output to dmesg while the problem is occurring. The iwlwifi dmesg output looks exactly the same with either firmware version, other than the output specific to loading the firmware.

Again, the 22.1.7.0 firmware has not exhibited any issues.

Falling back to 22.1.7.0 has solved at least one other user's wifi problems with this hardware. https://bugzilla.kernel.org/show_bug.cgi?id=74591

After a bit more testing, it looks like the problem happens with the 22.24.8.0 firmware and any of the 3.13 and 3.14 kernels that I have tried. The 22.1.7.0 firmware does not have problems with any of these kernels.

I'm trying out 3.15.0-rc4 with 22.24.8.0 now. The 3.15 kernel appears to include at least one workaround for bugs in the 22.24.8.0 firmware. I'll post more info after working for a few more hours.

(More specifically, https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=a82dda6cd492b8c88952be6f6527f3656f7ac585 referenced in https://bugzilla.kernel.org/show_bug.cgi?id=74591.)

kernel-3.15.0-0.rc4.git0.1.fc21 has been well behaved with 22.24.8.0.

Emmanuel Grumbach announced firmware version 22.212.9.0 on linux-wireless about a week ago that addresses this issue.

http://www.spinics.net/lists/linux-wireless/msg121780.html

I will test 3.14.2 with the 22.212.9.0 firmware next.

I tried out Fedora's 3.14.3-200.fc20.x86_64 does not load the 22.212.9.0 firmware.

It looks like Fedora 20's kernel is still based on upstream linux-3.14.tar.xz and not more recent stable updates linux-3.14.[1-3].tar.xz where these fixes are found.

I'll stick to 3.15.0-0.rc4.git0.1.fc21 for now.

It turns out that I have been filling up my system logs with "Microcode SW error detected" errors and related Call Traces while running the 3.15.0-0.rc[345].git0.1.fc21 kernels with either the 22.24.8.0 or 23.214.9.0 firmwares. I have not otherwise noticed issues running in these configurations.

(Also, the firmware in iwlwifi-7260-ucode-22.212.9.0.tgz reports its version as 23.214.9.0. I'm not sure why there is a version number discrepancy.)

I'm falling back to 3.14.3-200.fc20.x86_64 with the 22.1.7.0 firmware for now. I don't have time to play with this more.

(In reply to Abrahm Scully from comment #5)
> I tried out Fedora's 3.14.3-200.fc20.x86_64 does not load the 22.212.9.0
> firmware.

Unfortunately, 22.212.9.0 isn't in the upstream linux-firmware tree.  Sigh.

> It looks like Fedora 20's kernel is still based on upstream
> linux-3.14.tar.xz and not more recent stable updates linux-3.14.[1-3].tar.xz
> where these fixes are found.

No, that's not correct.  We have the stable releases applied as patches in our process, so they should have whatever upstream stable has included.  The upstream stable maintainer is really behind on getting tagged fixes in 3.15-rcX applied to the stable releases at the moment.

If you have specific patches you've identified as fixing the issues other than the one highlighted in comment #3, please point them out.  However, without the updated firmware it seems those alone won't fix the problems if I've read your report correctly.

The commit highlighted in comment #3 should be added to the 3.14.4 upstream stable release, and we'll pick that up very soon after.

Josh,

(In reply to Josh Boyer from comment #7)
> (In reply to Abrahm Scully from comment #5)
> > I tried out Fedora's 3.14.3-200.fc20.x86_64 does not load the 22.212.9.0
> > firmware.
> 
> Unfortunately, 22.212.9.0 isn't in the upstream linux-firmware tree.  Sigh.

The tarball named iwlwifi-7260-ucode-22.212.9.0.tgz available from http://wireless.kernel.org/en/users/Drivers/iwlwifi contains firmware that identifies itself as version 23.214.9.0, plus 3.15 reports "Microcode SW error detected" frequently. My bet is the updated driver/firmware is not quite ready for prime-time.

> 
> > It looks like Fedora 20's kernel is still based on upstream
> > linux-3.14.tar.xz and not more recent stable updates linux-3.14.[1-3].tar.xz
> > where these fixes are found.
> 
> No, that's not correct.  We have the stable releases applied as patches in
> our process, so they should have whatever upstream stable has included.  The
> upstream stable maintainer is really behind on getting tagged fixes in
> 3.15-rcX applied to the stable releases at the moment.

Thank you for correcting me about this. I'm new to Fedora and upstream kernel development. I see the stable patch now. Apparently, I didn't actually look at the 3.14.y branch, I just took Emmanuel's statement that the fixes might be available for 3.14.2 to mean that it would be in 3.14.2. I'll be more careful next time.

> 
> If you have specific patches you've identified as fixing the issues other
> than the one highlighted in comment #3, please point them out.  However,
> without the updated firmware it seems those alone won't fix the problems if
> I've read your report correctly.

I think that the patch highlighted in comment #3 itself is enough to work around the problem for the 22.24.8.0 firmware, but I have not tested just that patch. The newer firmware also has fixes for the same issue. I think the uAPSD support will be re-enabled in the driver after the firmware is confirmed fixed.

> 
> The commit highlighted in comment #3 should be added to the 3.14.4 upstream
> stable release, and we'll pick that up very soon after.

I will test just that patch on top of 3.14.3 to confirm that it alone addresses my problem. I've just kicked off a build.

Thanks again,
Abrahm

Running 3.14.3-200.fc20.x86_64 plus the patch disabling uAPSD with the 22.24.8.0 firmware, the 7260 still exhibits intermittent throughput problems on my network.

Abrahm, can you please

Arghh...

bad comment above....

Abrahm, I'd be glad to see the logs of the Microcode errors you reported in #8.

Thanks.

Created attachment 895627 [details]
dmesg with Microcode SW error

Emmanuel,

Attachment #895627 [details] shows the "Microcode SW error" messages for one particular boot (3.15.0-rc4, fw 23.219.9.0). I have seen similar messages with fw version 22.24.8.0, and also running 3.14.3 (although less frequent).

I would be happy to provide you with additional information if necessary.

Abrahm

Hi Abrahm,

You are seeing:
0x00002B03 | ADVANCED_SYSASSERT 

This bug has been fixed in https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git

Patches are on their way upstream for 3.15
You can either merge my tree (above), or you can apply patches - here is the list of the relevant patches in the following order:

https://patchwork.kernel.org/patch/4131661/
https://patchwork.kernel.org/patch/4167731/
https://patchwork.kernel.org/patch/4167721/


I'd really appreciate if you could apply and test. First it will give us extra validation on the bug you are seeing on 3.15 (0x00002B03 | ADVANCED_SYSASSERT), but it will also give us an insight on the disconnection issues you see on 3.13 and 3.14. We can't repro neither of these bugs internally.

Thank you.

Emmanuel,

The patches fix the "Microcode SW error detected" messages in 3.15.0.

I'm not sure how to best help debug the issues I had with 22.24.8.0 and 3.13 and 3.14.

I will install Fedora's 3.14.4-200 and test that for a while.

Thanks,
Abrahm

Well, that was quick.

3.14.4-200 and 22.24.8.0 definitely have the problem. 3.14.4-200 has the uAPSD disable patch. I guess I can try to apply other fixes and see which helps.

I did notice that when download throughput is bad, it seems like doing "ping -f" to another local machine during the download helps the throughput to not totally bottom out.

Abrahm

(In reply to Abrahm Scully from comment #15)
> Emmanuel,
> 
> The patches fix the "Microcode SW error detected" messages in 3.15.0.
> 
> I'm not sure how to best help debug the issues I had with 22.24.8.0 and 3.13
> and 3.14.
> 
Good are you positive that with this configuration you don't see the original bug you reported? Or even with this kernel / firmware your connection is not reliable?

If this configuration is good, next step is to take this firmware (-9.ucode) with 3.13 / 3.14.
You can that with this patch:
http://www.spinics.net/lists/linux-wireless/msg121312.html

Thank you for your help

Emmanuel,

I've kicked off a build of 3.14.4 with the IWL7260_UCODE_API_MAX changed to 9.

In the meantime, I'm running 3.15.0 with 22.24.8.0.

Abrahm

Ok,

So I'd like to build the matrix of the combinations:

3.15 means 3.15 including the patch from comment #14.
3.14 means 3.14 including the patch that disables uAPSD (already merged by Greg).

1) 3.15 + 22.24.8.0 = GOOD (comment #4)
2) 3.15 + 23.219.9.0 = ?
3) 3.14 + 22.24.8.0 = BAD (comment #9)
4) 3.14 + patch from comment #17 + 23.219.9.0 = ?

So - I understand that:

1) I need to git log v3.14..v3.15 to see what might have fixed the behavior with 22.24.8.0. I'll do that.
2) If configuration 4 is working, I might very well skip the whole thing and have everybody upgrade their firmware. Note that that the patch that allows to load 23.219.9.0 firmware has been CCed to stable so that eventually, it'll hit 3.14. But Greg is very behind these days...

Thanks!

(In reply to Emmanuel Grumbach from comment #19)
> Ok,
> 
> So I'd like to build the matrix of the combinations:
> 
> 3.15 means 3.15 including the patch from comment #14.
> 3.14 means 3.14 including the patch that disables uAPSD (already merged by
> Greg).
> 
> 1) 3.15 + 22.24.8.0 = GOOD (comment #4)
> 2) 3.15 + 23.219.9.0 = ?
> 3) 3.14 + 22.24.8.0 = BAD (comment #9)
> 4) 3.14 + patch from comment #17 + 23.219.9.0 = ?

1) 3.15 + 22.24.8.0 = GOOD (comment #4)
2) 3.15 + 23.219.9.0 = GOOD
3) 3.14 + 22.24.8.0 = BAD (comment #9)
4) 3.14 + patch from comment #17 + 23.219.9.0 = BAD
5) 3.14 + 22.1.7.0 = GOOD

> 
> So - I understand that:
> 
> 1) I need to git log v3.14..v3.15 to see what might have fixed the behavior
> with 22.24.8.0. I'll do that.
> 2) If configuration 4 is working, I might very well skip the whole thing and
> have everybody upgrade their firmware. Note that that the patch that allows
> to load 23.219.9.0 firmware has been CCed to stable so that eventually,
> it'll hit 3.14. But Greg is very behind these days...
> 
> Thanks!

I'd like to say that what I call "BAD" at this point in testing is just a subset of what I described in the first post. The patches have helped. The "BAD" behavior that remains is intermittent slow or stalled throughput.

Abrahm

Created attachment 896808 [details]
disable beacon filtering

can you please test the patch attached?
It is a fix candidate for 3.13 / 3.14.

Thank you.

3.14.4 + patch from comment #17 + attachment 896808 [details] + 23.219.9.0 = BAD
3.14.4 + patch from comment #17 + attachment 896808 [details] + 22.1.7.0 = GOOD

ouch.

can I logs of the failure?
Another user reported that it solved his issues (until he failed on another weird thing):
https://bugzilla.kernel.org/show_bug.cgi?id=72601

Emmanuel,

There is no information printed to dmesg when this happens. I do not get disconnected from the AP (ASUS RT-16 running a recent Shibby Tomato K26, configured as 802.11n only). Application connections don't break.

The "BAD" combinations of kernel/firmware are most evident as:

1. additional latency and hiccups while using remote desktop client.
2. inconsistent/fluctuating throughput speeds.
3. sustained throughput speed is about half that of the "GOOD" combinations.
4. sometimes speed slows so much the connection is unusable.

The issue only bothers me too much when using a remote desktop client to do real work. It's pretty tolerable or not always noticeable for casual network use.

When I created this bug report, I was having much more trouble than I currently experience.

I will try to get better logs and a better test-case. Would remote access to this laptop be helpful?

Thanks for your effort,
Abrahm

Hi,

if nothing gets printed to the dmesg, then it is not a disconnection.
What bothers me is that you don't seem to see this with older firmware, and this is the the right way to encourage people to upgrade to latest firmware...

But since it seems to work with 3.15 and latest firmware, I think I'll leave it for now. We made lots of work in 3.15 in the power area, and it is probably related. Old firmware with 3.15 means that the power features are disabled.
I guess a last test can be:

3.14.4 + patch from comment #17 + attachment 896808 [details] + 23.219.9.0 + power save disabled (can be done with iw wlan0 set power_save off).

Regarding accessing your laptop, this is not an offer I can refuse, but since it seems to reproduce only from time to time, and the effect isn't very clear, I am afraid I won't be able to get any valuable information from this.

(In reply to Emmanuel Grumbach from comment #25)
> I guess a last test can be:
> 
> 3.14.4 + patch from comment #17 + attachment 896808 [details] + 23.219.9.0 +
> power save disabled (can be done with iw wlan0 set power_save off).
> 

3.14.4 + patch from comment #17 + attachment 896808 [details] + 23.219.9.0 + power save disabled = BAD.

Thank you for your help,
Abrahm

BTW - issues have been reported with supplicant v2.1

just FYI

Emmanuel,

Thanks for the heads up.

I haven't noticed any wifi issues on my 802.11n 2.4Ghz WPA2-AES network running Fedora's kernel 3.15.0-0.rc5.git0.1 + the 3 patches from comment #14 + firmware 23.214.9.0 + Fedora's wpa_supplicant-2.0-8. I'll be sticking with that combination while I concentrate on other issues and let patches trickle back down to me.

Again, thanks for your help,

Abrahm

I have the same problem here on Dell Vostro 5470 and firmware version 2.24.8.0. Firmware version 22.0.7.0 does not have problem with kernel 3.14.4-200. 

$ lspci
08:00.0 Network controller: Intel Corporation Wireless 7260 (rev 93)

(In reply to Elder Marco from comment #29)
> I have the same problem here on Dell Vostro 5470 and firmware version
> 2.24.8.0. Firmware version 22.0.7.0 does not have problem with kernel
> 3.14.4-200. 
> 
> $ lspci
> 08:00.0 Network controller: Intel Corporation Wireless 7260 (rev 93)

I have published a patch for 3.15 that will be backported to 3.14.
https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi-fixes.git/commit/?id=7bacc782270ff7db3b9f29fa5d24ad2ee1e8e81d

From my point of view - this issue has been solved.
I am hence removing myself from this bug.
Please re-add me if you are sure that you have an issue with the patch above applied.

Hi Emmanuel,

Thanks. Waiting for this update.

The patch Emmanuel pointed to is queued for 3.14.6.  I'm also updating the 7260 firmware to the latest in linux-firmware.git today, which is 23.214.9.0.

linux-firmware-20140605-38.gita4f3bc03.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/linux-firmware-20140605-38.gita4f3bc03.fc20

linux-firmware-20140605-36.gita4f3bc03.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/linux-firmware-20140605-36.gita4f3bc03.fc19

linux-firmware-20140605-38.gita4f3bc03.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Both the firmware and 3.14.6 are in stable updates now.  Closing.

This updat

Ops, sorry.

This update (23.214.9.0-38.fc20) is not working for me. I'm using Dell Vostro 5470. After update, the system take a long time to connect. After connected, the connection is very slow. Only the version version 22.0.7.0-31 is working.

My I reopen the bugreport?

Elder, you probably hit different issue, please open a new bug report.

Thanks Stanislaw. I will open a new bug report.

I agree with Elder -- the update to the new firmware and kernel 3.14.7 does NOT fix these issues for me (on a Thinkpad Yoga, Intel 7260). I'll try to find the new bug report.

Just to confirm Elder's experience.  Long delays, random drops with latest kernel and firmware.  Dropping the firmware version down fixes all issues.

what firmware is good, which one is bad?

Hello,

The package 22.0.7.0-31.fc20 is good. The latest version (and the others after the version version 22.0.7.0) is bad. I opened a new bug report here:

https://bugzilla.redhat.com/show_bug.cgi?id=1110522