Linux firmware for iwlwifi ucode failed with error -2

A couple weeks ago, I decided to update my primary laptop’s kernel from 4.0 to 4.5. Everything went smoothly with the exception of my wireless networking. This particular laptop uses the a wifi chipset that is controlled by the Intel Wireless DVM Firmware:


#lspci | grep 'Network controller'
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)

According to Intel Linux support for wireless networking page, I need kernel support for the ‘iwlwifi’ driver. I remembered this requirement from building the previous kernel, so I included it in the new 4.5 kernel. The new kernel had some additional options, though, and they were:


[*] Intel devices
...
< > Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate-N (iwlwifi)
< > Intel Wireless WiFi DVM Firmware support
< > Intel Wireless WiFi MVM Firmware support
Debugging Options --->

As previously mentioned, the Kernel page for iwlwifi indicates that I need the DVM module for my particular chipset, so I selected it. Previously, I chose to build support for the driver into the kernel, and then use the firmware for the device. However, this time, I noticed that it wasn’t loading:


[ 3.962521] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[ 3.970843] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000g2a-6.ucode failed with error -2
[ 3.976457] iwlwifi 0000:03:00.0: loaded firmware version 18.168.6.1 op_mode iwldvm
[ 3.996628] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled
[ 3.996640] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[ 3.996647] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING enabled
[ 3.996656] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Advanced-N 6205 AGN, REV=0xB0
[ 3.996828] iwlwifi 0000:03:00.0: L1 Enabled - LTR Disabled
[ 4.306206] iwlwifi 0000:03:00.0 wlp3s0: renamed from wlan0
[ 9.632778] iwlwifi 0000:03:00.0: L1 Enabled - LTR Disabled
[ 9.633025] iwlwifi 0000:03:00.0: L1 Enabled - LTR Disabled
[ 9.633133] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0
[ 9.898531] iwlwifi 0000:03:00.0: L1 Enabled - LTR Disabled
[ 9.898803] iwlwifi 0000:03:00.0: L1 Enabled - LTR Disabled
[ 9.898906] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0
[ 20.605734] iwlwifi 0000:03:00.0: L1 Enabled - LTR Disabled
[ 20.605983] iwlwifi 0000:03:00.0: L1 Enabled - LTR Disabled
[ 20.606082] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0
[ 20.873465] iwlwifi 0000:03:00.0: L1 Enabled - LTR Disabled
[ 20.873831] iwlwifi 0000:03:00.0: L1 Enabled - LTR Disabled
[ 20.873971] iwlwifi 0000:03:00.0: Radio type=0x1-0x2-0x0

The strange thing, though, is that the firmware was right where it should be:


# ls -lh /lib/firmware/
total 664K
-rw-r--r-- 1 root root 662K Mar 26 13:30 iwlwifi-6000g2a-6.ucode

After digging around for a while, I finally figured out the problem. The kernel was trying to load the firmware for this device/driver before it was actually available. There are definitely ways to build the firmware into the kernel image as well, but instead of going that route, I just chose to rebuild my kernel with this driver as a module (which is actually the recommended method anyway):


[*] Intel devices
...
Intel Wireless WiFi Next Gen AGN - Wireless-N/Advanced-N/Ultimate-N (iwlwifi)
Intel Wireless WiFi DVM Firmware support
< > Intel Wireless WiFi MVM Firmware support
Debugging Options --->

If I had fully read the page instead of just skimming it, I could have saved myself a lot of time. Hopefully this post will help anyone getting the “Direct firmware load for iwlwifi-6000g2a-6.ucode failed with error -2” error message.

Cheers,
Zach

10 comments

Skip to comment form

    • Mike Lothian on Tuesday, 12 April 2016 at 06:15
    • Reply

    That’s true of nearly every driver that uses blobs, just pop the blobs you need into CONFIG_EXTRA_FIRMWARE (so for the above example CONFIG_EXTRA_FIRMWARE=”iwlwifi-6000g2a-6.ucode”) and hey presto it all just works

      • Zach on Tuesday, 12 April 2016 at 12:17
        Author
      • Reply

      You’re definitely right, Mike. Interestingly, though, I didn’t have the CONFIG_EXTRA_FIRMWARE set in my 4.0 kernel, and the driver worked built-in. If I recall correctly, I tried configuring it that way, but ended up just using it as a module in the end for sake of ease.

      Cheers,
      Zach

    • Georgi Georgiev on Tuesday, 12 April 2016 at 10:43
    • Reply

    Had a similar issue with the module getting loaded from the initramfs, but that did not include the firmware blobs. Had to add the firmware images to the dracut configuration so they get copied to the initramfs as well.

      • Zach on Tuesday, 12 April 2016 at 12:18
        Author
      • Reply

      Thanks for your comment, Georgi. Ultimately, that’s the main reason that I went with the module instead of building it into the kernel. I didn’t want to set up the initramfs on this particular machine, so it was more simplistic and efficient for me to just make iwlwifi a module.

      Cheers,
      Zach

    • murray foster on Tuesday, 12 April 2016 at 13:01
    • Reply

    Oh *man*, same exact thing happened to my work machine a Lenovo t440p and it’s been wired ever since. Thanks for the information!

      • Zach on Tuesday, 12 April 2016 at 13:14
        Author
      • Reply

      Hi Murray,

      Glad that it helped fix your problem! 🙂

      Cheers,
      Zach

  1. I got hit today by practically the same issue (slightly different hardware), upgrading the kernel on my Gentoo laptop from 4.8.5 to 4.11.7. Perhaps we should file a kernel bug report…

      • Zach on Tuesday, 5 December 2017 at 11:49
        Author
      • Reply

      Glad that the article helped you with the problem. I don’t know that it is a bug, per se. The documentation indicates that it can be built in to an initial RAMDISK (initrd), or as a module. So, for my needs, it’s easier to just have it as a module. 🙂

      Cheers,
      Zach

    • Bud on Saturday, 25 August 2018 at 16:25
    • Reply

    Thank you! This was very helpful and now I can go online via wifi!

      • Zach on Saturday, 25 August 2018 at 18:04
        Author
      • Reply

      I’m glad that the article helped you, Bud.

      Cheers,
      Zach

Leave a Reply

Your email address will not be published.