Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #78621 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2) Ken Milmore <ken.milmore@gmail.com> - 2023-03-27 00:10 +0200
    Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2) Diederik de Haas <didi.debian@cknow.org> - 2023-03-27 02:20 +0200
      Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2) Ken Milmore <ken.milmore@gmail.com> - 2023-03-28 00:30 +0200
        Bug#969264: firmware-iwlwifi: failed to load iwl-debug-yoyo.bin (-2) Diederik de Haas <didi.debian@cknow.org> - 2023-03-28 01:00 +0200

#78621 — 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

[toc] | [next] | [standalone]

#78622

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#78627

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#78628

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web