Bug 1046935 - iwlwifi: 7260 Wireless N - Microcode error ASSERT 14FC 22.0.7.0
Summary: iwlwifi: 7260 Wireless N - Microcode error ASSERT 14FC 22.0.7.0
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: fedora-kernel-wireless-iwl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1064646 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-27 14:18 UTC by pgaltieri
Modified: 2014-02-25 07:59 UTC (History)
12 users (show)

Fixed In Version: linux-firmware-20140131-34.gitd7f8a7c8.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-17 12:25:36 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Microcode SW error (23.71 KB, text/plain)
2013-12-27 14:18 UTC, pgaltieri
no flags Details
dmesg output (117.69 KB, text/x-log)
2014-02-12 13:10 UTC, Fabio Valentini
no flags Details
Log of Microcode SW error (2.21 MB, text/plain)
2014-02-13 00:37 UTC, pgaltieri
no flags Details
Redelmeier's dmesg (comment 28) (143.13 KB, text/plain)
2014-02-25 07:53 UTC, D. Hugh Redelmeier
no flags Details

Description pgaltieri 2013-12-27 14:18:37 UTC
Created attachment 842343 [details]
Microcode SW error

Description of problem:
Every day I see the following error in /var/log/messages

iwlwifi 0000:02:00.0: Microcode SW error detected.  Restarting 0x2000000. 

However the wifi continues to run.

Version-Release number of selected component (if applicable):
kernel-3.11.10-200.fc19.x86_64
iwl7260-firmware.noarch

How reproducible:
Happens several times every day

Steps to Reproduce:
1. Start 7260 wireless connection
2. monitor /var/log/messages
3.

Actual results:
Get error

Expected results:
No error

Additional info:
I have attached partial output from /var/log/messages

cat /var/log/messages | grep "Microcode SW error" | grep "Dec 27" | wc -l
223

Comment 1 Michele Baldessari 2013-12-27 17:57:19 UTC
According to http://www.spinics.net/lists/linux-wireless/msg112108.html it might be fixed via:
https://git.kernel.org/cgit/linux/kernel/git/egrumbach/linux-firmware.git/commit/?id=824994715e0276e64cdbf2badbe02921a78fb287

Hasn't hit the other main repos, yet but you could download the firmware by hand and give it a try and confirm if it fixes it for you.

hth,
Michele

Comment 2 Josh Boyer 2014-01-06 19:34:51 UTC
Stanislaw, does the commit Michele found seem like the correct fix?  If so, I'll move this to linux-firmware as that is where we'd pick that patch up eventually.

Comment 3 Stanislaw Gruszka 2014-01-07 08:22:38 UTC
Yes, that seems to be right fix.

Comment 4 Josh Boyer 2014-01-31 12:13:47 UTC
I've updated the firmware in Fedora git this morning.  An update will roll out to the releases shortly.

Comment 5 Fedora Update System 2014-01-31 14:26:42 UTC
linux-firmware-20140131-34.gitd7f8a7c8.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/linux-firmware-20140131-34.gitd7f8a7c8.fc19

Comment 6 Fedora Update System 2014-01-31 14:27:52 UTC
linux-firmware-20140131-35.gitd7f8a7c8.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/linux-firmware-20140131-35.gitd7f8a7c8.fc20

Comment 7 Fedora Update System 2014-02-01 04:02:26 UTC
Package linux-firmware-20140131-34.gitd7f8a7c8.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing linux-firmware-20140131-34.gitd7f8a7c8.fc19'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-1860/linux-firmware-20140131-34.gitd7f8a7c8.fc19
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2014-02-04 02:49:32 UTC
linux-firmware-20140131-35.gitd7f8a7c8.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Fabio Valentini 2014-02-07 20:22:09 UTC
I am on fedora rawhide, and I still see exactly the same Microcode SW error occurring _every 45 seconds_, which, quite frankly, spams every log including the systemd journal.

package versions installed:
linux-firmware-20140131-35.gitd7f8a7c8.fc21.noarch
iwl7260-firmware-22.15.8.0-35.fc21.noarch
kernel-3.14.0-0.rc1.git2.2.fc21.x86_64 from rawhide-kernel-nodebug repo

Comment 10 Stanislaw Gruszka 2014-02-12 08:19:43 UTC
Fabio, plese provide dmesg output.

Comment 11 Fabio Valentini 2014-02-12 13:10:17 UTC
Created attachment 862281 [details]
dmesg output

Dmesg log, collected about 5 minutes after system start.

dmesg | grep Microcode:

[   12.589414] iwlwifi 0000:01:00.0: Microcode SW error detected.  Restarting 0x2000000.
[   13.379334] iwlwifi 0000:01:00.0: Microcode SW error detected.  Restarting 0x2000000.
[   36.182166] iwlwifi 0000:01:00.0: Microcode SW error detected.  Restarting 0x2000000.
[   79.239809] iwlwifi 0000:01:00.0: Microcode SW error detected.  Restarting 0x2000000.
[  142.267208] iwlwifi 0000:01:00.0: Microcode SW error detected.  Restarting 0x2000000.
[  225.279114] iwlwifi 0000:01:00.0: Microcode SW error detected.  Restarting 0x2000000.
[  328.377956] iwlwifi 0000:01:00.0: Microcode SW error detected.  Restarting 0x2000000.
[  448.413425] iwlwifi 0000:01:00.0: Microcode SW error detected.  Restarting 0x2000000.

This continues to happen after hours of system uptime.

Sometimes the the wifi is rendered completely unusable (needs hardware disable / enable to start working again). If that happens again, I will collect data of that as well (but it might be a seperate problem).

Comment 12 Emmanuel Grumbach 2014-02-12 14:22:03 UTC
commit 35d77b5e57bca703ca4b9fb3acca124c93c18b12
Author: Emmanuel Grumbach <emmanuel.grumbach>
Date:   Thu Dec 5 22:42:55 2013 +0200

    iwlwifi: mvm: don't allow A band if SKU forbids it

    The driver wasn't reading the NVM properly. While this
    did'nt lead to any issue until now, it seems that there
    is an old version of the NVM in the wild.
    In this version, the A band channels appear to be valid
    but the SKU capabilities (another field of the NVM) says
    that A band isn't supported at all.
    With this specific version of the NVM, the driver would
    think that A band is supported while the HW / firmware
    don't. This leads to asserts.

    Cc: <stable.org> [3.10+]
    Reviewed-by: Johannes Berg <johannes.berg>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach>

This one should fix the issue

Comment 13 pgaltieri 2014-02-12 16:49:33 UTC
The last firmware (linux-firmware-20140131-34.gitd7f8a7c8.fc19.noarch) change appeared to have fixed it for me, but I'm now seeing the error again.

Comment 14 Emmanuel Grumbach 2014-02-12 17:32:52 UTC
Please share the dmesg output after with the new firmware.
I would like to make sure it is exactly the same bug.

I can say for sure that the bug you originally filed (ASSERT 14FC) is solved by 22.1.7.0.
*Another bug* (ASSERT 14F4 with Wireless N NIC) is solved by the patch I quoted in comment 12.

So we have already 2 bugs on the same bugzilla entry.

Comment 15 pgaltieri 2014-02-13 00:37:47 UTC
Created attachment 862579 [details]
Log of Microcode SW error

Comment 16 Emmanuel Grumbach 2014-02-13 06:04:28 UTC
(In reply to pgaltieri from comment #15)
> Created attachment 862579 [details]
> Log of Microcode SW error

This is still with 22.0.7.0.
Please update your firmware and update.

Comment 17 Stanislaw Gruszka 2014-02-13 11:28:46 UTC
*** Bug 1064646 has been marked as a duplicate of this bug. ***

Comment 18 pgaltieri 2014-02-13 19:57:09 UTC
I did a yum -y update this morning on the system that had the failure and there were no updates, so I'm running the latest firmware that is available.

Comment 19 Emmanuel Grumbach 2014-02-13 21:18:59 UTC
You can check the version of the firmware that is loaded in dmesg:
you need to see 22.1.7.0 - in your log with error, I saw you still had the old version.

Comment 20 Fabio Valentini 2014-02-13 21:23:58 UTC
I updated to the latest packages and I can confirm that the error no longer occurs. (22.15.8.0)

Comment 21 Stanislaw Gruszka 2014-02-17 12:24:59 UTC
Latest updated firmware should be iwl7260-firmware-22.15.8.0-35.fc20.noarch.rpm

Comment 22 Stanislaw Gruszka 2014-02-17 12:25:36 UTC
Closing per comment 20

Comment 23 Emmanuel Grumbach 2014-02-17 12:41:54 UTC
(In reply to Stanislaw Gruszka from comment #21)
> Latest updated firmware should be
> iwl7260-firmware-22.15.8.0-35.fc20.noarch.rpm


Cool - but have you updated iwlwifi-7260-7.ucode too? You'll need it for 3.10 -> 3.12 kernels.
Also have you updated the firmware for 3160?

Comment 24 Stanislaw Gruszka 2014-02-17 13:06:27 UTC
Yes, I've just checked.

Comment 25 Fedora Update System 2014-02-20 00:45:00 UTC
linux-firmware-20140131-34.gitd7f8a7c8.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 26 pgaltieri 2014-02-20 20:02:12 UTC
Updated system tp linux-firmware 20140131-34.gitd7f8a7c8.fc19 and I'm still having issues with wireless.  I'm running a Linksys AE1000 v1 802.11n [Ralink RT3572] USB wireless device. It starts off working fine, but after a few minutes I get lots of these messages:

Feb 20 11:50:29 jackstraw kernel: [44804.576617] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71
Feb 20 11:50:29 jackstraw kernel: [44804.580862] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71
Feb 20 11:50:29 jackstraw kernel: [44804.585115] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71

I'm not sure if these are related to the firmware or driver issues.

Comment 27 Emmanuel Grumbach 2014-02-20 20:05:17 UTC
This bug is about Intel adapter, not about Ralink...

Comment 28 D. Hugh Redelmeier 2014-02-25 07:50:41 UTC
I'm a bit confused about whether I should be piggy-backing on this bz, or create a new one, or just recognize that there's a fix that I'm missing.

I am running Fedora 20 + all current updates on a Lenovo Yoga 2 pro.  
This has a single-band Intel 7260 wireless card.
Emmanuel Grumbach has said that this card's NVM claims that it supports dual band.

I'm getting in my dmesg:
iwlwifi 0000:01:00.0: Microcode SW error detected.  Restarting 0x2000000.


I thought that this was fixed in what I'm running:

[    0.000000] Linux version 3.13.3-201.fc20.x86_64 (mockbuild@bkernel02) (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) ) #1 SMP F!

[    4.073897] iwlwifi 0000:01:00.0: loaded firmware version 22.15.8.0 op_mode iwlmvm

What have I missed?

PS: has intel produced and released a fixed for the NVM?

PPS: I actually bought a 7260 with dual band and AC support but don't want to install it just yet.

Comment 29 D. Hugh Redelmeier 2014-02-25 07:53:36 UTC
Created attachment 867272 [details]
Redelmeier's dmesg (comment 28)

Comment 30 Emmanuel Grumbach 2014-02-25 07:59:26 UTC
(In reply to D. Hugh Redelmeier from comment #28)
> I'm a bit confused about whether I should be piggy-backing on this bz, or
> create a new one, or just recognize that there's a fix that I'm missing.

There are already another bz on this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1069403

It is not the same bug: this bz (1046935) show ASSERT 14FC and your assert is 14F4.
Close but not the same - and yes - both occur only on BGN SKU.

> 
> 
> I thought that this was fixed in what I'm running:
> 
> [    0.000000] Linux version 3.13.3-201.fc20.x86_64 (mockbuild@bkernel02)
> (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) ) #1 SMP F!
> 
> [    4.073897] iwlwifi 0000:01:00.0: loaded firmware version 22.15.8.0
> op_mode iwlmvm

As I wrote in the other bz - the patch that fixes 14F4 is in 3.13.5.

> 
> PS: has intel produced and released a fixed for the NVM?

NVM is not writable - it won't be changed. Driver fixes this. Details in the bz I pointed to.

> 
> PPS: I actually bought a 7260 with dual band and AC support but don't want
> to install it just yet.

Enjoy


Note You need to log in before you can comment on or make changes to this bug.