User Tools

Site Tools


This is an old revision of the document!

Bugs and support

How to report?

Issues can be filed in kernel's bugzilla. Make sure to add to the bug. Always attach the kernel log to your reports:

dmesg > dmesg.log

and attach dmesg.log to the bug. Please also add the firmware version:

 ethtool -i wlan0 | grep firmware

Note: the interface name (here wlan0) can vary between distributions.

How to debug?


The simplest way to provide minimal output is to dump your kernel log: dmesg. Sometimes we will ask for logs from the supplicant too - they typically land in syslog. iwlwifi can print more data to the kernel log if asked to: this is controlled by the debug module parameter. This is a bitmap. To see more debug prints, CONFIG_IWLWIFI_DEBUG must be enabled. Please don't add debug level unless instructed to do so. Adding more prints typically adds useless information.


Another (more powerful) way to debug iwlwifi is to use tracing:

sudo trace-cmd record -e iwlwifi

We will typically ask for more switches:

sudo trace-cmd record -e iwlwifi -e mac80211 -e cfg80211 -e iwlwifi_msg

This records all the data that goes from and to the firmware. The output is a file: trace.dat which you can compress prior to sending. To enable tracing, CONFIG_IWLWIFI_TRACING must be set.

Firmware Debugging

Note that we no longer provide support for the firmware of the devices using iwldvm.

How to provide information to debug the firmware?

Getting data from the firmware can often provide a lot of information, especially when the traffic is being stalled, latency is high, queues are stuck etc.. Here is how to do so. This is working starting kernel 3.19.

First you'll need to allow DEV_COREDUMP by setting CONFIG_ALLOW_DEV_COREDUMP to Y. Then, you'll need to create a core dump. This can be done by:

echo 1 > /sys/kernel/debug/iwlwifi/0000\:0X\:00.0/iwlmvm/fw_dbg_collect

(Check what is the X for your system)

You can now get the data from the devcoredump device and dump to a file:

cat /sys/devices/virtual/devcoredump/devcdY/data > iwl.dump
echo 1 > /sys/devices/virtual/devcoredump/devcdY/data

(Y is incremented each time)

The easiest is to define a udev rule to dump the data automatically as soon as a dump is created:

SUBSYSTEM=="devcoredump", ACTION=="add", RUN+="/sbin/"

You'll typically have to paste this into a new file called /etc/udev/rules.d/85-iwl-dump.rules. This location can vary between distributions.

/sbin/ can simply be:

timestamp=$(date +%F_%H-%M-%S)
cat /sys/${DEVPATH}/data > /var/log/${filename}
echo 1 > /sys/${DEVPATH}/data

This way, each time a dump is created it will automatically land on your file system. Remember to make the /sbin/ file executable (i.e. chmod a+x /sbin/, so that the udev rule can execute it, otherwise it won't work.

To debug the firmware you'll typically need a customized version of it. This customization depends on the bug you are facing. Starting from 4.1, we can trigger firmware dumps when issues occur (e.g. when the association fails) this again requires a customized firmware. In that case, the developer working with you will let you know and you won't have to trigger the dump yourself using fw_dbg_collect debugfs hook.

Firmware crashes

When the firmware crashes, you'll see a message like this:

iwlwifi 0000:01:00.0: Microcode SW error detected.  Restarting 0x82000000.
iwlwifi 0000:01:00.0: Loaded firmware version: XX.XX.XX.XX
iwlwifi 0000:01:00.0: 0x0000090A | ADVANCED_SYSASSERT

In this case, please copy the full dmesg output since there may be data before and after this message that can be helpful.

In case of a firmware crash or queues being stuck, a dump will be automatically created. If you have the udev rule in place, you'll see the dump on your file system. No customization needed in that case, the dump from a regular firmware will already include valuable data, but the firmware team is likely to ask reproduction with a customized version.

Privacy aspects

By sending the debug logs, you are providing information to Intel such as your email address, peer’s MAC address, and other information. This information will be used only for the purpose of troubleshooting the issue you are reporting. Intel is committed to protecting your privacy. To learn more about Intel’s privacy practices, please visit Intel's privacy site or write Intel Corporation, ATTN Privacy, Mailstop RNB4-145, 2200 Mission College Blvd., Santa Clara, CA 95054 USA.

Please don't attach the firmware dumps to public bug trackers (such as bugzilla), but send it privately through email. We recommend you encrypt the data using Emmanuel Grumbach's PGP key (6E363201).

en/users/drivers/iwlwifi/debugging.1441914186.txt.gz · Last modified: 2015/09/10 19:43 by Luca Coelho