Intel Wireless 7260 fails on every Linux distro I tried (Fedora 44, Mint, CachyOS, PikaOS) but works on Windows 11 - iwlwifi "BAD_COMMAND / Failed to send DQA enabling command: -5"

Hi everyone,

My Intel Dual Band Wireless-N 7260 doesn’t work on Linux, but it works fine on Windows 11 on the same machine, so the card itself seems healthy. On Linux the driver and firmware load and the wlp1s0 interface appears, but the firmware crashes as soon as I enable the radio, and NetworkManager shows the device as “unavailable”. Wired Ethernet works fine.

What I’ve tried

  • Fedora 44: WiFi doesn’t work (kernel 7.2.5, also tried 6.19 and 6.14)
  • Linux Mint: WiFi doesn’t work
  • CachyOS: WiFi doesn’t work
  • PikaOS: WiFi doesn’t work
  • Windows 11: WiFi works without problems

Since it fails on four different distros and on several kernel versions, it doesn’t look like a distro-specific configuration problem.

System info

  • Machine: HP EliteDesk 800 G5 Desktop Mini, BIOS R21 Ver. 02.27.00 (07/28/2026)
  • WiFi card: Intel Wireless 7260 [8086:08b1], subsystem [8086:c020] (Wilkins Peak 2)
  • Driver: iwlwifi / iwlmvm
  • Firmware: 7260-17.ucode (version 17.bfb58538.0), linux-firmware-20260916-1.fc44
  • Secure Boot: enabled
  • Kernel command line: default, no iwlwifi module parameters set
  • rfkill: no soft or hard block

What happens
At boot the driver and firmware load without errors:

iwlwifi 0000:01:00.0: Detected Intel(R) Dual Band Wireless N 7260
iwlwifi 0000:01:00.0: loaded firmware version 17.bfb58538.0 7260-17.ucode op_mode iwlmvm
iwlwifi 0000:01:00.0 wlp1s0: renamed from wlan0

The crash happens when the radio is enabled (nmcli radio wifi on):

iwlwifi 0000:01:00.0: Microcode SW error detected.  Restarting 0x2000000.
iwlwifi 0000:01:00.0: Transport status: 0x0000004B, valid: 6
iwlwifi 0000:01:00.0: 0x00000038 | BAD_COMMAND
iwlwifi 0000:01:00.0: FW error in SYNC CMD UNKNOWN
iwlwifi 0000:01:00.0: Failed to send DQA enabling command: -5
iwlwifi 0000:01:00.0: Collecting data: trigger 2 fired.
iwlwifi 0000:01:00.0: Device is not enabled - cannot dump error

NetworkManager also logs platform-linux: do-change-link[3]: failure 5 (Input/output error). The error repeats every time I enable the radio.

No PCIe/AER errors are logged for the card’s link (only the root port’s “AER: enabled” lines), so this looks like a firmware-level crash rather than a link problem.

There’s also SELinux: Permission firmware_load in class system not defined in policy at boot, probably unrelated.

Full log (MAC addresses removed):https://paste.centos.org/view/01973553

Has anyone seen the 7260 firmware crash with BAD_COMMAND on the first command after enabling the radio? Since Windows works, is there any firmware/driver workaround or module parameter worth trying? Happy to run any tests or provide more logs.

Thanks!

It is also attached to the kernel,org bug report: https://bugzilla.kernel.org/show_bug.cgi?id=222030

Have you disabled Windows FastStartup? See https://gist.github.com/pelletier/2cf3053ecad136391f34d8a9facbb1a6 for explanation.

yes i tried. im using fedora only. i also waited for the power to drain from the device.

Update (2026-09-22): SOLVED

The problem is fixed. Huge thanks to Emmanuel Grumbach (Intel) for the patch — he replied on the kernel bug with a one-line guard that skips the LARI_CONFIG_CHANGE command on older firmware, and that turned out to be the root cause.

The driver was sending LARI_CONFIG_CHANGE to firmware 7260-17.ucode, which doesn’t support it. The firmware crashes with BAD_COMMAND as soon as it receives this command, which cascades into the Failed to send DQA enabling command: -5 and Microcode SW error messages we were all seeing. Once the LARI command is skipped, everything else falls into place.

The fix

Emmanuel’s patch adds a version guard in iwl_mvm_lari_cfg():

static void iwl_mvm_lari_cfg(struct iwl_mvm *mvm)
{
	struct iwl_lari_config_change_cmd cmd;
	size_t cmd_size;
	int ret;

	if (mvm->fw->ucode_ver < 26)   /* <-- added */
		return;

	ret = iwl_mvm_fill_lari_config(&mvm->fwrt, &cmd, &cmd_size);
	/* ... */
}

Patch thread: Making sure you're not a bot!

How I applied it on Fedora 44

Fedora ships iwlwifi/iwlmvm as modules, so I rebuilt just the module out-of-tree:

  1. Grabbed the matching iwlwifi source tree.
  2. Added the ucode_ver < 26 guard to mvm/fw.c in iwl_mvm_lari_cfg().
  3. make -C /lib/modules/$(uname -r)/build M=$PWD modules
  4. sudo make -C /lib/modules/$(uname -r)/build M=$PWD modules_install
  5. sudo modprobe -r iwlmvm iwlwifi && sudo modprobe iwlmvm

Result

After reloading the module:

  • No more BAD_COMMAND, no more Microcode SW error, no more Failed to send DQA enabling command: -5.
  • wlp1s0 comes up cleanly and associates with my AP on the first try.
  • nmcli radio wifi on works normally.
  • The card connects on 802.11n with default module parameters — no workarounds needed.

Environment confirmed working

  • Kernel: 7.2.6-200.fc44.x86_64
  • Firmware: 7260-17.ucode (17.bfb58538.0)
  • Card: Intel Dual Band Wireless-N 7260 ([8086:08b1], subsystem [8086:c020])
  • Secure Boot: disabled (the rebuilt, unsigned module loaded fine on my machine)

What I did not need

  • 11n_disable=1 or =8 — the default 0 works fine.
  • bt_coex_active, swcrypto, or any other module parameter.
  • The PCIe link tweak from the GitHub fix — it’s a no-op on my card.
  • Removing or downgrading 7260-17.ucode.

For anyone else on Fedora

If you’re on Fedora 44 and hit the same crash, either wait for a kernel update that backports the fix, or do the out-of-tree rebuild above — it takes about five minutes and survives reboots (the module is installed under /lib/modules/$(uname -r)/updates/).

Cross-posting this to the CachyOS and Linux Mint threads so people searching for the same error can find it.

Problems with newer firmware on older hardware are becoming more common. It is encouraging that Intel still has people willing to fix issues with old hardware.

planned obsolescence
:slight_smile:

mission failed :smiley: