How To: Fix Intel 8260 (rev 3a) slow / rubbish wireless issues in Linux

My laptop has an Intel Corporation Wireless 8260 (rev 3a) wireless card. It says so right in the lspci -v output:

02:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
	Subsystem: Intel Corporation Dual Band Wireless-AC 8260
	Flags: bus master, fast devsel, latency 0, IRQ 327
	Memory at dc400000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [40] Express Endpoint, MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Device Serial Number a4-34-d9-ff-ff-38-91-54
	Capabilities: [14c] Latency Tolerance Reporting
	Capabilities: [154] L1 PM Substates
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

However, in Linux it’s been dropping out and going slow and all sorts of rubbish. Looking in dmesg you can typically see stuff like (edited):

Loaded firmware version: 22.361476.0
iwlwifi 0000:02:00.0: 0x00000084 | NMI_INTERRUPT_UNKNOWN
Lots more red text here...

So can we fix it? Like Bob the Builder, yes we can – but it’s a two-step…

Part 1 – Kernel Modules

The 8260 card uses the iwlwifi kernel module, and the microcode for that is stored in /lib/firmware.

Specifically, you’re looking for the files: iwlwifi-8000C-SOME_NUMBER.ucode.

So for example, I see the following:

r3dux [ /lib/firmware ]$ ls -alh /lib/firmware/iwlwifi-8000C*
-rw-r--r-- 1 root root 1.7M Oct  5 21:35 /lib/firmware/iwlwifi-8000C-13.ucode
-rw-r--r-- 1 root root 2.3M Oct  5 21:35 /lib/firmware/iwlwifi-8000C-16.ucode
-rw-r--r-- 1 root root 2.3M Oct  5 21:35 /lib/firmware/iwlwifi-8000C-21.ucode
-rw-r--r-- 1 root root 2.1M Oct  5 21:35 /lib/firmware/iwlwifi-8000C-22.ucode

The kernel seems to pick the highest number in the 8000C range, so it’ll pick the 8000C-22 variant. Only this is borked. To revert to the previous 21 revision, simply rename the file extension of the 22 version to something different, for example:

sudo mv /lib/firmware/iwlwifi-8000C-22.ucode /lib/firmware/iwlwifi-8000C-22.ucode.BORKED

However, at least in my experience, this isn’t enough to stop the module crash/restart issues – so we need to…

Part 2 – Disable Wireless N

If I just do the above, I still get issues in dmesg where the wireless card’s crashing and resetting itself – so to bypass the failing code, we need to disable wireless N (and only use B/G). Sure, this is going to be slower than N, but it’s going to be faster than a borked version of N – so off we go…

The parameters to the iwlwifi module include one called 11n_disable – and to set that on boot we need to have a /etc/modprobe.d folder (create the directory if necessary), then into that put a file with any name ending in .conf such as iwlwifi.conf (makes sense, right?) with the following contents:

options iwlwifi 11n_disable=1

Once that’s in and saved, reboot and your wireless should work properly again – no dmesg crash data, no slow-downs, no bullshit.

There are actually a few different values that can be used, but “1” works for me. The array of valid values for the 11n_disable property can be seen by entering:

modinfo iwlwifi

And the current settings can be checked by hitting:

systool -v -m iwlwifi

With the 21 revision of the microcode and wireless-N disabled you should find your wireless card now works properly. Huzzah!


You may want to know that I did this on an Arch Linux system (kernel: 4.8.13-1-ARCH linux-firmware: 20161005.9c71af9-1), and that I also set my regulatory authority code which controls allowable wireless frequencies/channels (via installing the crda package and setting the config to my local country, which is Australia, so “AU” – further reading: – although I’m not sure if changing the regulatory domain actually did anything to the above fix instructions. Thought I’d mention it all the same.


8 thoughts on “How To: Fix Intel 8260 (rev 3a) slow / rubbish wireless issues in Linux”

  1. Thank you so much for this post! It fixed the abysmal wireless speeds. However, it’s still rather slow because of the switch to Wireless N. Is there a chance this will be fixed in the future?

    Wireless card: Intel Corporation Wireless 8260 (rev 3a)
    Kernel version: 4.9.12-200.fc25.x86_64

    1. You’re welcome! As for whether it gets fixed, you’d think it would considering that the wireless chipset in question is still quite modern (i.e. it came with the laptop I bought less than 12 months ago).

      The iwlwifi module is part of the ‘linux-firmware’ package, and on Arch that now contains a iwlwifi-8000C-27.ucode file:

      $ls -l /lib/firmware/iwlwifi-8000C*
      -rw-r--r-- 1 root root 1745176 Feb 23 17:54 /lib/firmware/iwlwifi-8000C-13.ucode
      -rw-r--r-- 1 root root 2351636 Feb 23 17:54 /lib/firmware/iwlwifi-8000C-16.ucode
      -rw-r--r-- 1 root root 2394060 Feb 23 17:54 /lib/firmware/iwlwifi-8000C-21.ucode
      -rw-r--r-- 1 root root 2120860 Feb 23 17:54 /lib/firmware/iwlwifi-8000C-22.ucode
      -rw-r--r-- 1 root root 2227284 Feb 23 17:54 /lib/firmware/iwlwifi-8000C-27.ucode

      But… I don’t think that’s getting used for our chipset because hitting up dmesg | grep iwlwifi gives output like:

      [    2.807609] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-26.ucode failed with error -2
      [    2.807619] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-25.ucode failed with error -2
      [    2.807627] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-24.ucode failed with error -2
      [    2.807635] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-23.ucode failed with error -2
      [    2.811147] iwlwifi 0000:02:00.0: loaded firmware version 22.391740.0 op_mode iwlmvm
      [    2.868526] iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
      [    2.870677] iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled
      [    2.871555] iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled
      [    3.017989] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
      [    3.021230] iwlwifi 0000:02:00.0 wlp2s0: renamed from wlan0
      [    4.186498] iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled

      Which I take to mean that the 27 version doesn’t support us, then it’s working backwards 26/25/24/23 (which don’t exist) before hitting 22 which does. Also note from the above “loaded firmware version” line that the version that got picked (22) is now at a later revision than when I wrote this article… so for all I know it might already be fixed.

      I guess it might come down to every time you see the linux-firmware package updated you could move that N-disabling conf file from /etc/modprobe into your home folder, reboot and see if you have any joy with AC or N. If so great, and if not then just sling the conf to disable N back so you at least have wireless G going without it crashing and grinding to a halt.


  2. Simply deleting all ucode except 16 fixed it, though I wouldn’t have fixed it without your insight and this article thanks!
    440mbps is the max i can get now, vs 514 on windows not bad.
    No DC so far. Uptime of 2 days.
    22 with n-disable also works but too slow, ~8mbit max!

  3. Have any of you had problems with the signal strength? The speed is fine for me, but signal strength is really bad, about half to 1/3 of what it should be.

  4. I have the 8260 in my laptop running Kubuntu 17.04 (with kernel 4.12.5). Unfortunately, firmware prior to 27 doesn’t work with kernel 4.12.

    My WiFi has always been rock solid (i.e. no drop-outs), but it’s slow compared to Windows 10 (three time slower – can transfer a 10GB file at 34MB/s on Windows, only getting 10MB/s on Linux).

    I’m currently looking for a new M.2 WiFi card (preferably something not Intel, and that plays nice with Linux). Any suggestions?

  5. My 8260 on a ThinkPad T460P has recently been causing me terrible problems; at around lunchtime, in a particular office, I’d get the red kernel crash messages every 3 seconds, and it would periodically hard-lock my laptop. This is with up-to-date kernels etc on two different linux distributions. Not great at work! Setting that 11n option seems to have stopped the crash and is letting me get back to work. Thanks very much!

  6. Hey, this might be old but I want to let you know that it worked for me on the exact same issue with the same chipset.
    However I wouldn’t say it fixed it because all it does is limiting the wireless speed by disabling 802.11n.
    According to my tests, my interface was crashing when it was going “too fast”, but when I limited the bandwith using specific command line arguments (e.g. rsync –bwlimit ) it wouldn’t crash.
    So this fix kinda gives me peace of mind but now the wifi maximum speed I can attain is 2MB/sec …
    Thanks for this idea though !

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.