Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1030636: Debian Installer complains about missing firmware in ath10k, even when using image with firmware included
1,170 views
Skip to first unread message
Brandon Werner
Feb 5, 2023, 6:10:05 PM2/5/23
to
package: hw-detect
version: 1.154
Hello,
I saw the recent work to the installer surrounding firmware handling and thought I would test on my machines to see how this all was working. I used one of the daily sid_d-i netinst cds including firmware. I noticed some problems around the installer asking for firmware that was not neded for ath10k. I first tried on a laptop that had QCA-6174 hw2.1. I noticed the prompt telling me about missing firmware and asking if I wanted to load it from additional media, which was puzzling for the firmware image. If I select no, the installer continues, however, I thought this could confuse users, so I dug into it.
Before firmware atheros was loaded, the kernel tried to load versions 6 through 2 of the firmware files as well as calibration firmware files. After firmware atheros was installed, the card was brought up, and this time, only three files were missing. The cal and pre-cal files appear to be optional according to the driver source, and do not exist in linux-firmware upstream, so I think them missing is no problem. Firmware ver 6 doesn't exist yet in the upstream Linux repo so maybe this is in the driver for future use? I guess the installer still thinks there is missing firmware because of the kernel failing to load these 3 unnecessary files. After version 5 of the firmware was found, the kernel stopped trying to load versions 4 3 2, so there was many fewer missing files on the second run of check-missing-firmware.
I have another laptop with hw3.2 of QCA-6174 and on that machine, only pre-cal and cal are missing after firmware-atheros is loaded by the installer. I looked at hw-detect, and noticed there was a section in check-missing-firmware.sh ignoreing intel wifi debugging firmware, but I think trying to ignore all the correct files in that location might be a bit tricky, especially if other net drivers try to load optional firmware. It also seems possible that the PCI IDs searched by the driver could be different for cal and pre-cal for different ath10k hardware although I didn't dig into this. I hope the information I provided is enough for package maintainers to determine a correct solution. Thanks for all the great work on the installer recently to make firmware handling work better.
Below, a bit of text from the installer log, to show the driver is loading, but the installer still thinking there is missing firmware.
Feb 5 10:35:26 check-missing-firmware: mainloop iteration #1
Feb 5 10:35:26 check-missing-firmware: lookup with /cdrom/firmware/Contents-firmware
Feb 5 10:35:26 check-missing-firmware: installing firmware package /cdrom/firmware/firmware-atheros_20221214-5_all.deb (non-free-firmware)
Feb 5 10:35:28 check-missing-firmware: removing and loading kernel module ath10k_pci
Feb 5 10:35:28 kernel: [ 60.711599] DMAR: DRHD: handling fault status reg 2
Feb 5 10:35:28 kernel: [ 60.711605] DMAR: [DMA Write NO_PASID] Request device [01:00.0] fault addr 0x7ee00000 [fault reason 0x05] PTE Write access is not set
Feb 5 10:35:28 kernel: [ 60.711661] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
Feb 5 10:35:28 kernel: [ 60.977712] ath10k_pci 0000:01:00.0: firmware: failed to load ath10k/pre-cal-pci-0000:01:00.0.bin (-2)
Feb 5 10:35:28 kernel: [ 60.977724] ath10k_pci 0000:01:00.0: firmware: failed to load ath10k/pre-cal-pci-0000:01:00.0.bin (-2)
Feb 5 10:35:28 kernel: [ 60.977735] ath10k_pci 0000:01:00.0: firmware: failed to load ath10k/cal-pci-0000:01:00.0.bin (-2)
Feb 5 10:35:28 kernel: [ 60.977744] ath10k_pci 0000:01:00.0: firmware: failed to load ath10k/cal-pci-0000:01:00.0.bin (-2)
Feb 5 10:35:28 kernel: [ 60.977755] ath10k_pci 0000:01:00.0: firmware: failed to load ath10k/QCA6174/hw2.1/firmware-6.bin (-2)
Feb 5 10:35:28 kernel: [ 60.977762] ath10k_pci 0000:01:00.0: firmware: failed to load ath10k/QCA6174/hw2.1/firmware-6.bin (-2)
Feb 5 10:35:28 kernel: [ 60.977973] ath10k_pci 0000:01:00.0: firmware: direct-loading firmware ath10k/QCA6174/hw2.1/firmware-5.bin
Feb 5 10:35:28 kernel: [ 60.977980] ath10k_pci 0000:01:00.0: qca6174 hw2.1 target 0x05010000 chip_id 0x003405ff sub 144d:4125
Feb 5 10:35:28 kernel: [ 60.977986] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
Feb 5 10:35:28 kernel: [ 60.978697] ath10k_pci 0000:01:00.0: firmware ver SW_RM.1.1.1-00157-QCARMSWPZ-1 api 5 features ignore-otp,no-4addr-pad crc32 10bf8e08
Feb 5 10:35:28 kernel: [ 61.040011] ath10k_pci 0000:01:00.0: firmware: direct-loading firmware ath10k/QCA6174/hw2.1/board-2.bin
Feb 5 10:35:28 kernel: [ 61.040387] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id N/A crc32 ae2e275a
Feb 5 10:35:29 check-missing-firmware: looking at dmesg again, restarting from timestamp: [ 57.345819]
Feb 5 10:35:29 check-missing-firmware: timestamp found, truncating dmesg accordingly
Feb 5 10:35:29 check-missing-firmware: saving timestamp for a later use: [ 61.040387]
Feb 5 10:35:29 check-missing-firmware: looking for firmware file ath10k/pre-cal-pci-0000:01:00.0.bin requested by ath10k_pci
Feb 5 10:35:29 check-missing-firmware: looking for firmware file ath10k/pre-cal-pci-0000:01:00.0.bin requested by ath10k_pci
Feb 5 10:35:29 check-missing-firmware: looking for firmware file ath10k/cal-pci-0000:01:00.0.bin requested by ath10k_pci
Feb 5 10:35:29 check-missing-firmware: looking for firmware file ath10k/cal-pci-0000:01:00.0.bin requested by ath10k_pci
Feb 5 10:35:29 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-6.bin requested by ath10k_pci
Feb 5 10:35:29 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-6.bin requested by ath10k_pci
Feb 5 10:35:29 check-missing-firmware: missing firmware files (ath10k/pre-cal-pci-0000:01:00.0.bin ath10k/pre-cal-pci-0000:01:00.0.bin ath10k/cal-pci-0000:01:00.0.bin ath10k/cal-pci-0000:01:00.0.bin ath10k/QCA6174/hw2.1/firmware-6.bin ath10k/QCA6174/hw2.1/firmware-6.bin) for ath10k_pci
Feb 5 10:35:29 kernel: [ 62.211095] ath10k_pci 0000:01:00.0: htt-ver 3.1 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
Feb 5 10:35:30 kernel: [ 62.299139] ath: EEPROM regdomain: 0x6a
Feb 5 10:35:30 kernel: [ 62.299142] ath: EEPROM indicates we should expect a direct regpair map
Feb 5 10:35:30 kernel: [ 62.299144] ath: Country alpha2 being used: 00
Feb 5 10:35:30 kernel: [ 62.299145] ath: Regpair used: 0x6a
Feb 5 10:35:30 kernel: [ 62.300428] ath10k_pci 0000:01:00.0 wlp1s0: renamed from wlan0
Feb 5 10:35:30 net/hw-detect.hotplug: Detected hotpluggable network interface wlp1s0
Feb 5 10:36:02 check-missing-firmware: mainloop iteration #2
Alexander Dalm
Feb 6, 2023, 4:30:04 AM2/6/23
to
Hi
Brandon,
good point.
currently hw-detect / check-missing-firmware doesn't checks if a specific firmware file is optional or required, I even considered asking for the optional ones as well as a feature.
But there is actually a function nic_is_configured() that is used to determine if the module has to be removed and reloaded after files are installed.
This function technically could be used before asking, so either:
a) optional files wouln't be displayed at all
b) optional files would be marked as optional
c) all files should be displayed regardless
I think
Cyril will step in to answer this question ;)
I will do some testing to check if
nic_is_configured() is reliable enough for this task by feeding the files one by one.
Cyril Brulebois
Feb 6, 2023, 4:40:05 AM2/6/23
to
Hi Brandon,
Brandon Werner <brando...@fastmail.fm> (2023-02-05):
> Before firmware atheros was loaded, the kernel tried to load versions
> 6 through 2 of the firmware files as well as calibration firmware
> files. After firmware atheros was installed, the card was brought up,
> and this time, only three files were missing. The cal and pre-cal
> files appear to be optional according to the driver source, and do not
> exist in linux-firmware upstream, so I think them missing is no
> problem. Firmware ver 6 doesn't exist yet in the upstream Linux repo
> so maybe this is in the driver for future use? I guess the installer
> still thinks there is missing firmware because of the kernel failing
> to load these 3 unnecessary files. After version 5 of the firmware was
> found, the kernel stopped trying to load versions 4 3 2, so there was
> many fewer missing files on the second run of check-missing-firmware.
We would need to see more of your log file. It starts with mainloop
iteration #1, while the first check_missing call has happened already.
> I have another laptop with hw3.2 of QCA-6174 and on that machine, only
> pre-cal and cal are missing after firmware-atheros is loaded by the
> installer. I looked at hw-detect, and noticed there was a section in
> check-missing-firmware.sh ignoreing intel wifi debugging firmware,
That one was obvious enough to ignore. But how are we supposed to tell
which one(s) of the *68* files iwlwifi requests is(are) needed?
> but I think trying to ignore all the correct files in that location
> might be a bit tricky, especially if other net drivers try to load
> optional firmware. It also seems possible that the PCI IDs searched by
> the driver could be different for cal and pre-cal for different ath10k
> hardware although I didn't dig into this. I hope the information I
> provided is enough for package maintainers to determine a correct
> solution. Thanks for all the great work on the installer recently to
> make firmware handling work better.
I don't think there's a way to identify what's needed and what's
optional. We can't even determine whether firmware is actually needed!
(e.g. my rtw8192cu requests firmware but works fine without it.)
> Below, a bit of text from the installer log, to show the driver is
> loading, but the installer still thinking there is missing firmware.
Please include at least all lines between the first and the last
check-missing-firmware lines.
Cheers,
--
Cyril Brulebois (ki...@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Brandon Werner <brando...@fastmail.fm> (2023-02-05):
> I saw the recent work to the installer surrounding firmware handling
> and thought I would test on my machines to see how this all was
> working. I used one of the daily sid_d-i netinst cds including
> firmware. I noticed some problems around the installer asking for
> firmware that was not neded for ath10k. I first tried on a laptop that
> had QCA-6174 hw2.1. I noticed the prompt telling me about missing
> firmware and asking if I wanted to load it from additional media,
> which was puzzling for the firmware image. If I select no, the
> installer continues, however, I thought this could confuse users, so
> I dug into it.
Thanks for the tests and the report.
> and thought I would test on my machines to see how this all was
> working. I used one of the daily sid_d-i netinst cds including
> firmware. I noticed some problems around the installer asking for
> firmware that was not neded for ath10k. I first tried on a laptop that
> had QCA-6174 hw2.1. I noticed the prompt telling me about missing
> firmware and asking if I wanted to load it from additional media,
> which was puzzling for the firmware image. If I select no, the
> installer continues, however, I thought this could confuse users, so
> I dug into it.
> Before firmware atheros was loaded, the kernel tried to load versions
> 6 through 2 of the firmware files as well as calibration firmware
> files. After firmware atheros was installed, the card was brought up,
> and this time, only three files were missing. The cal and pre-cal
> files appear to be optional according to the driver source, and do not
> exist in linux-firmware upstream, so I think them missing is no
> problem. Firmware ver 6 doesn't exist yet in the upstream Linux repo
> so maybe this is in the driver for future use? I guess the installer
> still thinks there is missing firmware because of the kernel failing
> to load these 3 unnecessary files. After version 5 of the firmware was
> found, the kernel stopped trying to load versions 4 3 2, so there was
> many fewer missing files on the second run of check-missing-firmware.
iteration #1, while the first check_missing call has happened already.
> I have another laptop with hw3.2 of QCA-6174 and on that machine, only
> pre-cal and cal are missing after firmware-atheros is loaded by the
> installer. I looked at hw-detect, and noticed there was a section in
> check-missing-firmware.sh ignoreing intel wifi debugging firmware,
which one(s) of the *68* files iwlwifi requests is(are) needed?
> but I think trying to ignore all the correct files in that location
> might be a bit tricky, especially if other net drivers try to load
> optional firmware. It also seems possible that the PCI IDs searched by
> the driver could be different for cal and pre-cal for different ath10k
> hardware although I didn't dig into this. I hope the information I
> provided is enough for package maintainers to determine a correct
> solution. Thanks for all the great work on the installer recently to
> make firmware handling work better.
optional. We can't even determine whether firmware is actually needed!
(e.g. my rtw8192cu requests firmware but works fine without it.)
> Below, a bit of text from the installer log, to show the driver is
> loading, but the installer still thinking there is missing firmware.
check-missing-firmware lines.
Cheers,
--
Cyril Brulebois (ki...@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Cyril Brulebois
Feb 6, 2023, 4:51:53 AM2/6/23
to
Alexander Dalm <a.dal...@googlemail.com> (2023-02-06):
idea to reload a module. That's quite a different story… And no, between
two mainloop iterations, that part wouldn't change anyway.
> This function technically could be used before asking, so either:
> a) optional files wouln't be displayed at all
> b) optional files would be marked as optional
> c) all files should be displayed regardless
>
> I think Cyril will step in to answer this question ;)
See other reply.
> But there is actually a function nic_is_configured() that is used to
> determine if the module has to be removed and reloaded after files are
> installed.
That's not what it does. It is there to determine whether it's a bad
> determine if the module has to be removed and reloaded after files are
> installed.
idea to reload a module. That's quite a different story… And no, between
two mainloop iterations, that part wouldn't change anyway.
> This function technically could be used before asking, so either:
> a) optional files wouln't be displayed at all
> b) optional files would be marked as optional
> c) all files should be displayed regardless
>
> I think Cyril will step in to answer this question ;)
Brandon Werner
Feb 6, 2023, 5:20:04 AM2/6/23
to
Feb 5 10:35:26 check-missing-firmware: looking at dmesg for the first time
Feb 5 10:35:26 check-missing-firmware: saving timestamp for a later use: [ 57.345819]
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/pre-cal-pci-0000:01:00.0.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/pre-cal-pci-0000:01:00.0.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/cal-pci-0000:01:00.0.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/cal-pci-0000:01:00.0.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-6.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-6.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-5.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-5.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-4.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-4.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-3.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-3.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-2.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-2.bin requested by ath10k_pci
Feb 5 10:35:26 check-missing-firmware: missing firmware files (ath10k/pre-cal-pci-0000:01:00.0.bin ath10k/pre-cal-pci-0000:01:00.0.bin ath10k/cal-pci-0000:01:00.0.bin ath10k/cal-pci-0000:01:00.0.bin ath10k/QCA6174/hw2.1/firmware-6.bin ath10k/QCA6174/hw2.1/firmware-6.bin ath10k/QCA6174/hw2.1/firmware-5.bin ath10k/QCA6174/hw2.1/firmware-5.bin ath10k/QCA6174/hw2.1/firmware-4.bin ath10k/QCA6174/hw2.1/firmware-4.bin ath10k/QCA6174/hw2.1/firmware-3.bin ath10k/QCA6174/hw2.1/firmware-3.bin ath10k/QCA6174/hw2.1/firmware-2.bin ath10k/QCA6174/hw2.1/firmware-2.bin) for ath10k_pci
Feb 5 10:35:26 check-missing-firmware: mainloop iteration #1
Feb 5 10:36:02 check-missing-firmware: removing and loading kernel module ath10k_pci
Feb 5 10:36:02 kernel: [ 95.083903] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
Feb 5 10:36:03 kernel: [ 95.349714] ath10k_pci 0000:01:00.0: firmware: failed to load ath10k/pre-cal-pci-0000:01:00.0.bin (-2)
Feb 5 10:36:03 kernel: [ 95.349727] ath10k_pci 0000:01:00.0: firmware: failed to load ath10k/pre-cal-pci-0000:01:00.0.bin (-2)
Feb 5 10:36:03 kernel: [ 95.349739] ath10k_pci 0000:01:00.0: firmware: failed to load ath10k/cal-pci-0000:01:00.0.bin (-2)
Feb 5 10:36:03 kernel: [ 95.349749] ath10k_pci 0000:01:00.0: firmware: failed to load ath10k/cal-pci-0000:01:00.0.bin (-2)
Feb 5 10:36:03 kernel: [ 95.349760] ath10k_pci 0000:01:00.0: firmware: failed to load ath10k/QCA6174/hw2.1/firmware-6.bin (-2)
Feb 5 10:36:03 kernel: [ 95.349770] ath10k_pci 0000:01:00.0: firmware: failed to load ath10k/QCA6174/hw2.1/firmware-6.bin (-2)
Feb 5 10:36:03 kernel: [ 95.349914] ath10k_pci 0000:01:00.0: firmware: direct-loading firmware ath10k/QCA6174/hw2.1/firmware-5.bin
Feb 5 10:36:03 kernel: [ 95.349919] ath10k_pci 0000:01:00.0: qca6174 hw2.1 target 0x05010000 chip_id 0x003405ff sub 144d:4125
Feb 5 10:36:03 kernel: [ 95.349922] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
Feb 5 10:36:03 kernel: [ 95.350425] ath10k_pci 0000:01:00.0: firmware ver SW_RM.1.1.1-00157-QCARMSWPZ-1 api 5 features ignore-otp,no-4addr-pad crc32 10bf8e08
Feb 5 10:36:03 kernel: [ 95.411727] ath10k_pci 0000:01:00.0: firmware: direct-loading firmware ath10k/QCA6174/hw2.1/board-2.bin
Feb 5 10:36:03 kernel: [ 95.412101] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id N/A crc32 ae2e275a
Feb 5 10:36:03 check-missing-firmware: looking at dmesg again, restarting from timestamp: [ 61.040387]
Feb 5 10:36:03 check-missing-firmware: timestamp found, truncating dmesg accordingly
Feb 5 10:36:03 check-missing-firmware: saving timestamp for a later use: [ 95.412101]
Feb 5 10:36:03 check-missing-firmware: looking for firmware file ath10k/pre-cal-pci-0000:01:00.0.bin requested by ath10k_pci
Feb 5 10:36:03 check-missing-firmware: looking for firmware file ath10k/pre-cal-pci-0000:01:00.0.bin requested by ath10k_pci
Feb 5 10:36:03 check-missing-firmware: looking for firmware file ath10k/cal-pci-0000:01:00.0.bin requested by ath10k_pci
Feb 5 10:36:03 check-missing-firmware: looking for firmware file ath10k/cal-pci-0000:01:00.0.bin requested by ath10k_pci
Feb 5 10:36:03 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-6.bin requested by ath10k_pci
Feb 5 10:36:03 check-missing-firmware: looking for firmware file ath10k/QCA6174/hw2.1/firmware-6.bin requested by ath10k_pci
Feb 5 10:36:03 check-missing-firmware: missing firmware files (ath10k/pre-cal-pci-0000:01:00.0.bin ath10k/pre-cal-pci-0000:01:00.0.bin ath10k/cal-pci-0000:01:00.0.bin ath10k/cal-pci-0000:01:00.0.bin ath10k/QCA6174/hw2.1/firmware-6.bin ath10k/QCA6174/hw2.1/firmware-6.bin) for ath10k_pci
Feb 5 10:36:04 kernel: [ 96.582186] ath10k_pci 0000:01:00.0: htt-ver 3.1 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
Feb 5 10:36:04 kernel: [ 96.671106] ath: EEPROM regdomain: 0x6a
Feb 5 10:36:04 kernel: [ 96.671109] ath: EEPROM indicates we should expect a direct regpair map
Feb 5 10:36:04 kernel: [ 96.671111] ath: Country alpha2 being used: 00
Feb 5 10:36:04 kernel: [ 96.671112] ath: Regpair used: 0x6a
Feb 5 10:36:04 kernel: [ 96.672484] ath10k_pci 0000:01:00.0 wlp1s0: renamed from wlan0
Feb 5 10:36:04 net/hw-detect.hotplug: Detected hotpluggable network interface wlp1s0
Feb 5 10:36:09 check-missing-firmware: taking network interface wlp1s0 up/down
Feb 5 10:36:11 check-missing-firmware: looking at dmesg again, restarting from timestamp: [ 95.412101]
Feb 5 10:36:11 check-missing-firmware: timestamp found, truncating dmesg accordingly
Feb 5 10:36:11 check-missing-firmware: saving timestamp for a later use: [ 96.672484]
Feb 5 10:36:11 check-missing-firmware: no missing firmware in loaded kernel modules
Feb 5 10:36:12 main-menu[834]: INFO: Falling back to the package description for brltty-udeb
Cyril Brulebois
Feb 6, 2023, 5:40:05 AM2/6/23
to
Hi Brandon,
Brandon Werner <brando...@fastmail.fm> (2023-02-06):
good idea to check a hypothesis before deciding what to do about it. :)
I think I might have mentioned the following in some discussion, or
in some commit, but basically:
- we have a list of requested files;
- we have a list of requesting modules;
- some modules get reloaded.
If we maintain a module/file mapping, we could:
- decide which modules need to be reloaded, instead of iterating on all
of them (that's part of the reason why I had this idea in mind in the
first place, looking around how to “reload dance” was implemented:
walking through all modules unconditionally);
- decide that a module is “good to go” as soon as it's been reloaded
once, i.e. some of the files it requested have been found.
The second part would make the point about “required” vs. “optional”
firmware moot, and would prevent extra dialogs. One could argue that
maybe some other *.deb somewhere could be more recent or could have
extra files, but then we don't implement anything when it comes to
multiplicity anyway, so that wouldn't be a regression.
Alternatively, we could keep the unconditionally reload dance, while
still keeping track of files requested by each module over time.
When the list gets smaller, its files start getting ignored.
Does that make sense to you?
Brandon Werner <brando...@fastmail.fm> (2023-02-06):
> Thanks for your response. I have included the syslog lines from the
> installer log you requested.
OK, that's basically what I thought was happening, but it's always a
> installer log you requested.
good idea to check a hypothesis before deciding what to do about it. :)
I think I might have mentioned the following in some discussion, or
in some commit, but basically:
- we have a list of requested files;
- we have a list of requesting modules;
- some modules get reloaded.
If we maintain a module/file mapping, we could:
- decide which modules need to be reloaded, instead of iterating on all
of them (that's part of the reason why I had this idea in mind in the
first place, looking around how to “reload dance” was implemented:
walking through all modules unconditionally);
- decide that a module is “good to go” as soon as it's been reloaded
once, i.e. some of the files it requested have been found.
The second part would make the point about “required” vs. “optional”
firmware moot, and would prevent extra dialogs. One could argue that
maybe some other *.deb somewhere could be more recent or could have
extra files, but then we don't implement anything when it comes to
multiplicity anyway, so that wouldn't be a regression.
Alternatively, we could keep the unconditionally reload dance, while
still keeping track of files requested by each module over time.
When the list gets smaller, its files start getting ignored.
Does that make sense to you?
Cyril Brulebois
Feb 6, 2023, 7:40:05 AM2/6/23
to
Brandon Werner <brando...@fastmail.fm> (2023-02-06):
> This makes sense, and both solutions seem like they would work. It
> seems like the second solution of keeping the unconditional reload and
> testing if the list of files was smaller after the reload would be
> easier to implement for Bookworm, but I think you and the rest of the
> installer team are better informed to make that decision. :)
Heh. :)
> I think assuming the module is working if the list of requested files
> is smaller after a reload is a fairly safe bet for network hardware,
> but If the installer team implemented either of these solutions, I
> could test on a bunch of old and new machines that are available at a
> computer club I attend. I unfortunately don't feel like I personally
> understand the installer well enough to fix this properly, and any
> merge request I would create would be a sad hack. Hopefully many folks
> will be testing Alpha 2 of Bookworm as well, to find any problems that
> would result from a change like this.
To be honest, there were a lot of changes already, and I'm not sure I'll
be able to squeeze that in before the next release (to be confirmed but
we were aiming at a release next week-end, and we still have to upload
d-i and see whether it becomes eligible for testing…). The safest bet at
this point would be to release with what's in the archive (basically
what you tested), warn against this specific issue (that wouldn't be a
regression from previous releases anyway), and mention it should go away
in the following release.
That's not to say I won't try and get a tentative patch before then…
Would you be happy to test a custom netinst that I would build locally
(i.e. outside cdimage.debian.org and the official infrastructure)?
> This makes sense, and both solutions seem like they would work. It
> seems like the second solution of keeping the unconditional reload and
> testing if the list of files was smaller after the reload would be
> easier to implement for Bookworm, but I think you and the rest of the
> installer team are better informed to make that decision. :)
Heh. :)
> I think assuming the module is working if the list of requested files
> is smaller after a reload is a fairly safe bet for network hardware,
> but If the installer team implemented either of these solutions, I
> could test on a bunch of old and new machines that are available at a
> computer club I attend. I unfortunately don't feel like I personally
> understand the installer well enough to fix this properly, and any
> merge request I would create would be a sad hack. Hopefully many folks
> will be testing Alpha 2 of Bookworm as well, to find any problems that
> would result from a change like this.
To be honest, there were a lot of changes already, and I'm not sure I'll
be able to squeeze that in before the next release (to be confirmed but
we were aiming at a release next week-end, and we still have to upload
d-i and see whether it becomes eligible for testing…). The safest bet at
this point would be to release with what's in the archive (basically
what you tested), warn against this specific issue (that wouldn't be a
regression from previous releases anyway), and mention it should go away
in the following release.
That's not to say I won't try and get a tentative patch before then…
Would you be happy to test a custom netinst that I would build locally
(i.e. outside cdimage.debian.org and the official infrastructure)?
Alexander Dalm
Feb 6, 2023, 10:50:05 AM2/6/23
to
Hi Cyril,
> That's not what it does. It is there to determine whether it's a bad
> idea to reload a module. That's quite a different story… And no, between> two mainloop iterations, that part wouldn't change anyway.
indeed.
I thought the device would be configured after upnics at the beginning or reloading the module + upnics.
sorry for the inconvenience :)
> If we maintain a module/file mapping, we could:
> - decide which modules need to be reloaded, instead of iterating on all
> of them (that's part of the reason why I had this idea in mind in the
> first place, looking around how to “reload dance” was implemented:
> walking through all modules unconditionally);
> - decide that a module is “good to go” as soon as it's been reloaded
> once, i.e. some of the files it requested have been found.
> - decide which modules need to be reloaded, instead of iterating on all
> of them (that's part of the reason why I had this idea in mind in the
> first place, looking around how to “reload dance” was implemented:
> walking through all modules unconditionally);
> - decide that a module is “good to go” as soon as it's been reloaded
> once, i.e. some of the files it requested have been found.
The needed files for my WiFi module BCM43340 / CYW43340 / AP6234 are basically a worst case scenario:
brcmfmac43340-sdio.bin -> required firmware file
(reload)
brcmfmac43340-sdio.txt -> required NVRAM file
(reload)
brcmfmac43340-sdio.clm_blob -> optional and not available for
43340
Depending on the Kernel version the brcmfmac module requests each file first as
brcmfmac43340-sdio.[ManufacturerName]-[ProductName].bin /
.txt /
.clm_blob
and then as fallback:
brcmfmac43340-sdio.bin /
.txt / .clm_blob
-> Debian 11.6: only .txt in
[ManufacturerName]-[ProductName] format
-> Debian 12: all three files in
[ManufacturerName]-[ProductName] format
My manufacturer was kinda lazy and left the
ManufacturerName in BIOS as "To be filled by O.E.M"
->
brcmfmac43340-sdio.To be filled by O.E.M.-Z83.bin
(this is where the spaces came from)
There will be some more prominent devices like the Raspberry Pi 3A / 3B / 4B / M2 / M3 affected with the new Debian version,
here's the file list of the firmware-brcm80211 package:
https://packages.debian.org/bullseye/all/firmware-brcm80211/filelist
https://packages.debian.org/bullseye/all/firmware-brcm80211/filelist
I guess it's best to keep the reload dance.
0 new messages