[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: