Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)

[rv]

Package: firmware-iwlwifi
Version: 20200721-1
Severity: normal
X-Debbugs-Cc: riverava...@gmail.com

Dear Maintainer,

* What led up to the situation?

AFAIK, 'sudo apt-get update && sudo apt-get dist-upgrade' and reboot.

* What exactly did you do (or not do) that was effective (or
ineffective)?

Nothing at all, I've just encountered this warning at booting-messages.

* What was the outcome of this action?

So far this seems to be the only relevant info:

$ sudo dmesg | grep iwl-debug-yoyo
[ 15.287545] iwlwifi 0000:03:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
[ 15.287655] iwlwifi 0000:03:00.0: Direct firmware load for iwl-debug-yoyo.bin failed with error -2

* What outcome did you expect instead?

Not warnings, but the really important: Wi-Fi connection has been behaving erratically, lots of lags - for instance - in LAN-SSH connections.

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

Let me know if there's some useful info I could add.

Thanks a lot. Best regards.



-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii initramfs-tools 0.137

-- no debconf information

[Salvatore Bonaccorso]

Hi,

Small note on the warning you are seeing: the warning itself is
harmless, cf. #966218.

But I'm not merging the two bugs, because you mentioned you are seeing
issues with the Wi-Fi connection.

Regards,
Salvatore

[riveravaldez]

Thanks a lot, Salvatore!

Your response has been really quick, informative and useful.

I'm under the impression that the issue with the Wi-Fi connection
pre-dates the upgrade in which I detected this warning - and so it
would be non-related and calling for a merge - , but still not sure.
I'll try to test the connection to find the cause of the problem. Any
hint about how/with which tool could I do that?

Thanks again, best regards.

[Hadrien Dussuel]

Hi,

I think those two bugs are not related.

I also get that "iwl-debug-yoyo" error, but without the firmware load
error and have no problem at all using the WiFi.

For reference, the exact messages are:

[    3.459322] iwlwifi 0000:04:00.0: firmware: direct-loading firmware
iwlwifi-7260-17.ucode
[    3.459554] iwlwifi 0000:04:00.0: loaded firmware version
17.3216344376.0 7260-17.ucode op_mode iwlmvm
[    3.459568] iwlwifi 0000:04:00.0: firmware: failed to load
iwl-debug-yoyo.bin (-2)
[    3.638557] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band
Wireless AC 7260, REV=0x144
[    3.666215] iwlwifi 0000:04:00.0: base HW address: d8:fc:93:b8:ff:06
[    3.908366] iwlwifi 0000:04:00.0 wlp4s0: renamed from wlan0

Best regards,

Hadrien

[maximilian attems]

tags 969264 moreinfo
stop

> Version: 20200721-1

> Wi-Fi connection has been behaving erratically, lots of lags - for
> instance - in LAN-SSH connections.

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

Is this reproducible with current Debian testing?

thank you for your report.

[Xiaoguang Xue]

Hi,

This issue still exist in the most recent Debian 11 (testing) setup (5.10.0-6-amd64), although there are no huge impacts on my wifi speed/reliability.

Let me know if you need any more inforation.

Regards,

Sunney

On Wed, 24 Mar 2021 19:36:05 +0100 maximilian attems <ma...@stro.at> wrote:

> tags 969264 moreinfo
> stop
>
> > Version: 20200721-1
>

> > Wi-Fi connection has been behaving erratically, lots of lags - for
> > instance - in LAN-SSH connections.
>
> > $ lspci | grep "Network controller"
> > 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205
> > [Taylor Peak] (rev 34)
>

[Frode Severin Hatlevik]

I just updated my Debian amd64 system from Buster to Bullseye as per

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html

I have to admit I cut some corners and enabled backports and Fast Track and did the update in one go.

All went well, short of the error discussed in this bug appearing at the boot console

[   20.208399] iwlwifi 0000:02:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
[   20.208429] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware

This is problematic in three ways

1. The debug firmware is not supplied nor needed for daily usage

2. The Wiki page referenced (https://wiki.debian.org/Firmware) does not provide any pointers to useful information

3. The section about intel-microcode in Chapter 5

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#intel-microcode

mentions possible problems with firmware-iwlwifi for Bullseye

Blacklisting the module has been suggested earlier in this bugreport, but it has not been reached my system as of yet.

Unexperienced Linux users can easily be putt off by such errormesages.

Is there a fix for this planned soon?

;)Frode

--

Da sa Gud: "Det bli lys!"
Og det ble lys.
                      1. Mosebok 1.3

And God said, "Let there be light,"
and there was light.
                      Genesis 1:3, NIV

[Enrique Garcia]

Source: linux
Followup-For: Bug #969264
X-Debbugs-Cc: cqu...@arcor.de

This seems like it has been fixed in the 5.15.0-3-amd64 kernel as installed in
testing. At least I have not seen these errors in journalctl since I moved to
the testing release.


-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=es_ES:es
Shell: /bin/sh linked to /usr/bin/dash

[Diederik de Haas]

On Sun, 9 Jan 2022 23:20:49 +0100 Frode Severin Hatlevik
<frodes...@gmail.com> wrote:
> I just updated my Debian amd64 system from Buster to Bullseye as per
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html
> I have to admit I cut some corners and enabled backports and Fast Track and
> did the update in one go.
>
> All went well, short of the error discussed in this bug appearing at the
> boot console
> [ 20.208399] iwlwifi 0000:02:00.0: firmware: failed to load
> iwl-debug-yoyo.bin (-2)

With what kernel version did you see that message?

[Marcin Juszkiewicz]

10:35 (314s) hrw@blossom:~$ uname -a
Linux blossom 5.18.0-0.bpo.1-amd64 #1 SMP PREEMPT_DYNAMIC Debian
5.18.2-1~bpo11+1 (2022-06-14) x86_64 GNU/Linux

10:35 (0s) hrw@blossom:~$ dmesg|grep iwl-debug-yoyo.bin
[sob lip 9 10:29:29 2022] iwlwifi 0000:00:14.3: firmware: failed to
load iwl-debug-yoyo.bin (-2)

10:35 (0s) hrw@blossom:~$

[Ingo]

On Sat, 9 Jul 2022 10:36:40 +0200 Marcin Juszkiewicz <mar...@juszkiewicz.com.pl> wrote:
> On Sat, 11 Jun 2022 17:58:18 +0200 Diederik de Haas > <didi....@cknow.org> wrote: >> On Sun, 9 Jan 2022 23:20:49 +0100 Frode Severin Hatlevik >> <frodes...@gmail.com> wrote: >>> I just updated my Debian amd64 system from Buster to Bullseye as >>> per >>> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html > >>> >>> >>> >>> >> I have to admit I cut some corners and enabled backports and Fast >> Track and >>> did the update in one go. >>> >>> All went well, short of the error discussed in this bug >>> appearing at the boot console [ 20.208399] iwlwifi 0000:02:00.0: >>> firmware: failed to load iwl-debug-yoyo.bin (-2) >> >> With what kernel version did you see that message? > 10:35 (314s) hrw@blossom:~$ uname -a Linux blossom > 5.18.0-0.bpo.1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.2-1~bpo11+1 > (2022-06-14) x86_64 GNU/Linux > > 10:35 (0s) hrw@blossom:~$ dmesg|grep iwl-debug-yoyo.bin [sob lip 9 > 10:29:29 2022] iwlwifi 0000:00:14.3: firmware: failed to load > iwl-debug-yoyo.bin (-2) > > 10:35 (0s) hrw@blossom:~$ > >

It's still seen here in kernel:

Linux xyz 5.19.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.19.6-1 (2022-09-01) x86_64 GNU/Linux

Hardware is Shuttle xpx With Alder Lake CPU and Intel AX200-NGW. WiFi and BlueTooth. Both work flawlessly with latest Bluetooth Firmware

ibt-20-0-3.ddc + ibt-20-0-3.sfi symlinked  to corresponding 20-0.0 version which some piece of software  strictly requests (version 20-0.3 does not load otherwise).

WiFi uses firmware

iwlwifi-cc-a0-72.ucode from github - the only version which no longer produces "failed to load ..." in dmesg.

[Ken Milmore]

This bug still persists on Bookworm kernels despite having been "fixed"
upstream. It has been annoying me for a while, so I decided to work out exactly
what was going on.

From the upstream discussion and elsewhere, I gather that the firmware file
"iwl-debug-yoyo.bin" is optional "TLV debug data" associated with the iwlwifi
driver. This data does not seem to have been made generally available by Intel,
nor is it required for operation, nor is it even expected to exist on a normal
production system. So the error message generated when the kernel tries to load
it is harmless, but it is going to be irksome to almost everybody with an Intel
wireless adapter.

There are a few posts floating around which suggest making the problem go away
by setting the enable_ini module parameter on the iwlwifi module. This
certainly doesn't work for me on a fairly recent AX211 adapter, which fails to
initialise completely if I try messing with enable_ini.

The upstream fix [1] to avoid the irksome error messages has been to replace
a call to request_firmware() from the iwlwifi driver with
firmware_request_nowarn() instead. This causes option flag FW_OPT_NO_WARN to be
set inside the firmware subsystem to indicate that it should not complain if it
fails to load this particular file.

Unfortunately, Debian also applies a couple of downstream patches which
customise the firmware loading code so as to unconditionally issue a message at
loglevel 3 whenever a firmware file fails to load. See [2] and [3] for details.

From the above, it is difficult to know what the correct "fix" is here, as the
Debian approach seems to be to deliberately issue an error on firmware load
failure, whether asked to or not. If this behaviour were changed, it would
clearly affect the error reporting behaviour for all firmware in general, so it
needs thought.

One possible approach might be to downgrade the Debian-specific errors in
[2] and [3] to a lower loglevel in cases where FW_OPT_NO_WARN has been set
by the driver. This would stop them from appearing on the console during
boot. Loglevel 3 would still need to be used in cases where FW_OPT_NO_WARN
is unset (i.e. for firmware that is expected to exist).

Sadly the required option flags are not available in
fw_get_filesystem_firmware() where the error messages are currently issued,
so either the flags will need to be passed in, or the error checking will need
to be moved out into _request_firmware() where the flags are visible.

Note also there are a lot of fallbacks in _request_firmware(): to compressed
versions of firmware files, to firmware embedded on the platform etc. I'm not
clear on how many of these should be tried prior to issuing an error message.

If a decision is ever made on the preferred solution here, I'll be happy to
prepare a patch, but I assume further discussion will be needed as it affects
firmware loading in general. Hopefully these notes may have shed some light
to inform that.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c?id=3f4600de8c93917594a8b3c9ca713160ee4d563c
[2] https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/patches/bugfix/all/firmware_class-log-every-success-and-failure.patch
[3] https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/patches/debian/firmware_class-refer-to-debian-wiki-firmware-page.patch

[Diederik de Haas]

On Sunday, 26 March 2023 23:58:58 CEST Ken Milmore wrote:
> The upstream fix [1] to avoid the irksome error messages has been to replace
> a call to request_firmware() from the iwlwifi driver with
> firmware_request_nowarn() instead. This causes option flag FW_OPT_NO_WARN to
> be set inside the firmware subsystem to indicate that it should not
> complain if it fails to load this particular file.
>
> Unfortunately, Debian also applies a couple of downstream patches which
> customise the firmware loading code so as to unconditionally issue a message
> at loglevel 3 whenever a firmware file fails to load. See [2] and [3] for
> details.

It's also indicated in https://bugs.debian.org/969264#37 and I do believe that
the problem stems from that upstream introduced firmware_request_nowarn in
commit 7dcc01343e483efda0882456f8361f061a5f416d (part of 4.18-rc1),
but the Debian patch (your [2]) hasn't been updated accordingly.

The bug report is usually about iwl-debug-yolo.bin (sorry, couldn't resist),
which a not-needed (nor useful) 'debug' msg, I believe the issue is wider:

root@quartz64b:~# dmesg --level err | grep firmware
[ 33.225697] brcmfmac mmc2:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.pine64,quartz64-b.bin (-2)
[ 33.225716] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[ 33.225806] brcmfmac mmc2:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.pine64,quartz64-b.bin (-2)
[ 33.297583] brcmfmac mmc2:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.pine64,quartz64-b.clm_blob (-2)
[ 33.323650] brcmfmac mmc2:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.pine64,quartz64-b.clm_blob (-2)
[ 34.940552] bluetooth hci0: firmware: failed to load brcm/BCM4345C0.pine64,quartz64-b.hcd (-2)
[ 34.941576] bluetooth hci0: firmware: failed to load brcm/BCM4345C0.pine64,quartz64-b.hcd (-2)

Logged as *errors* in dmesg ... which aren't actual errors:

root@quartz64b:~# dmesg | grep "brcmfmac"
[ 33.201725] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 33.202444] usbcore: registered new interface driver brcmfmac
[ 33.225697] brcmfmac mmc2:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.pine64,quartz64-b.bin (-2)
[ 33.225806] brcmfmac mmc2:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.pine64,quartz64-b.bin (-2)
[ 33.225814] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.pine64,quartz64-b.bin failed with error -2
[ 33.285263] brcmfmac mmc2:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.bin
[ 33.294308] brcmfmac mmc2:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.pine64,quartz64-b.txt
[ 33.297583] brcmfmac mmc2:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.pine64,quartz64-b.clm_blob (-2)
[ 33.323650] brcmfmac mmc2:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.pine64,quartz64-b.clm_blob (-2)
[ 33.328250] brcmfmac mmc2:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.clm_blob
[ 33.482658] brcmfmac_wcc: brcmf_wcc_attach: executing
[ 33.488864] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2
root@quartz64b:~# dmesg | grep "bluetooth"
[ 34.940552] bluetooth hci0: firmware: failed to load brcm/BCM4345C0.pine64,quartz64-b.hcd (-2)
[ 34.941576] bluetooth hci0: firmware: failed to load brcm/BCM4345C0.pine64,quartz64-b.hcd (-2)
[ 34.947627] bluetooth hci0: firmware: direct-loading firmware brcm/BCM4345C0.hcd

So they weren't errors, but more debug-level messages as it all succeeded.

I don't know if it's also an upstream kernel issue or it's only caused by
Debian's patch, but AFAICT that patch needs to be revised to (at least) account
for the upstream change(s?) in firmware loading.

The bad news is that we're in hard-freeze and the current logic is used by
debian-installer to load the (non-free-)firmware, so it seems VERY unwise
to change the logic and output wrt firmware loading NOW.

The beginning of the Trixie development cycle would be an excellent time to
address this, but this is 'above my paygrade' and I can't make claims on other
people's time.

I personally would like to see a review of all the patches to see whether
they're still needed, still the best solution to the problem, can be upstreamed
etc, but having enough people with the needed skillset and time to do things,
has been a problem for a while. Even my request for help didn't get a (public)
response: https://lists.debian.org/debian-kernel/2022/06/msg00146.html ...

Cheers,
Diederik

[Ken Milmore]

On 27/03/2023 01:08, Diederik de Haas wrote:
> I don't know if it's also an upstream kernel issue or it's only caused by
> Debian's patch, but AFAICT that patch needs to be revised to (at least) account
> for the upstream change(s?) in firmware loading.

AFAICT, it's just a Debian problem now.

I'm attaching a patch, more for documentary purposes than anything else.

This reduces the "firmware: failed to load..." message to a loglevel of info in
cases where the FW_OPT_NO_WARN flag is set, which stops if from bothering the
user on the console.

That same message seems to be the key that the installer greps for to indicate
missing firmware: See [4], line 157. One wonders whether that is the best course
in cases where that firmware is only optional anyway.

-Ken.

[4] https://salsa.debian.org/installer-team/hw-detect/-/blob/master/check-missing-firmware.sh

[Diederik de Haas]

On Tuesday, 28 March 2023 00:21:59 CEST Ken Milmore wrote:
> > I don't know if it's also an upstream kernel issue or it's only caused by
> > Debian's patch, but AFAICT that patch needs to be revised to (at least)
> > account for the upstream change(s?) in firmware loading.
>
> AFAICT, it's just a Debian problem now.

I meant in _my specific case_ it could *also* be an upstream issue.
I agree that this bug is certainly a Debian problem, which also affects the
specific issue I added.

[Max Nikulin]

I hope,

firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)

is a really harmless message and

options iwlwifi enable_ini=0

has no side effects besides suppressing attempts of loading this file.

The real issue that a missed firmware file is first thing to suspect in
the case of firmware crashes (likely caused by some other bug). It takes
time to estimate real severity of the message by looking up for bug reports.

It would be great to see clearly expressed intentions in logs like
"optional development-only firmware" or "iterating to find latest
available version" instead of obscure "failed to load" that may mean
anything from critical error to logging of a routine action.

The message appears during boot of linux-image-amd64_6.4.4-3~bpo12+1
backport kernel.