Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)
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.
Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)
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. signature.asc Description: This is a digitally signed message part.
Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)
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.shdiff -Naur linux-source-6.1~/drivers/base/firmware_loader/main.c linux-source-6.1/drivers/base/firmware_loader/main.c
--- linux-source-6.1~/drivers/base/firmware_loader/main.c 2023-03-05 15:33:00.0 +
+++ linux-source-6.1/drivers/base/firmware_loader/main.c 2023-03-27 22:58:25.794997737 +0100
@@ -572,10 +572,15 @@
__putname(path);
if (rc) {
- dev_err(device, "firmware: failed to load %s (%d)\n",
- fw_priv->fw_name, rc);
- if (rc == -ENOENT)
- pr_err_once("See https://wiki.debian.org/Firmware for information about missing firmware\n");
+ if (!(fw_priv->opt_flags & FW_OPT_NO_WARN)) {
+ dev_err(device, "firmware: failed to load %s (%d)\n",
+fw_priv->fw_name, rc);
+ if (rc == -ENOENT)
+pr_err_once("See https://wiki.debian.org/Firmware for information about missing firmware\n");
+ } else {
+ dev_info(device, "firmware: failed to load %s (%d)\n",
+fw_priv->fw_name, rc);
+ }
}
return rc;
Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)
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 signature.asc Description: This is a digitally signed message part.
Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)
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
Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)
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.
Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)
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
Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2)
Package: firmware-iwlwifi Version: 20200721-1 Severity: normal X-Debbugs-Cc: riveravaldezm...@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 :03:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2) [ 15.287655] iwlwifi :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
