Hi Daniel, [ and the submitter, Brandon, back in cc. ]
Daniel Lewart <lewa...@gmail.com> (2021-06-25):
> Thank you for your advice! Although I did not follow it ...
:)
> "modprobe (-r) rtw88_8821ce" (removes) adds the following eight modules:
> * cfg80211
> * libarc4
> * mac80211
> * rfkill
> * rtw88_8821c
> * rtw88_8821ce
> * rtw88_core
> * rtw88_pci
> The only secondary modules I can think of to experiment with would be
> Bluetooth-related, but none were loaded in the first place.
>
> Instead, I tried the Bullseye RC 2 release of the installer
> (with firmware) three more times, all successfully:
> firmware-bullseye-DI-rc2-amd64-netinst.iso
>
> What was different about the failed first effort?
> * It took me more than three minutes to enter the WPA2 passphrase
> * "INFO: buf = wpa_state=INTERFACE_DISABLED" in syslog every 5s
>
> These are possible causes of general RTL8192CE problems,
> which I rank from most likely to least likely:
> 1) RTL8821CE driver quality
> 2) Active State Power Management (disable_aspm?)
> 2) Message Signalled Interrupts (disable_msi?)
> 3) 2.4 vs 5 GHz conflict
> 4) Bluetooth vs Wireless conflict
> 5) Phase of the moon
I haven't seen many problems here (admittedly with custom built images,
see #989863 for the full story), WPA2 connection is established quite
quickly and I haven't seen anything strange in my syslog. Grepping for
wpa_state in two full installation syslogs, I'm seeing only this, once
in each:
[…] wpa_state=SCANNING […]
[…] wpa_state=COMPLETED […]
> Here are my conclusions:
> 1) My patch will help in cases where the module name is
> different than the driver name (mostly Realtek)
> 2) The RTL8821CE driver is flaky
> 3) Network configuration problems are unrelated to hw-detect
> and could be addressed in netcfg, perhaps by restarting WPA
>
> I hope some people experiencing the original problem can test my patch.
Many thanks for the inspiration, it helped a lot! (I must confess my
first idea was to just hardcode reloading a different module if that
particular one was seen.)
I've kept reloading the module determined initially, even if it could
probably be skipped if the actual module name is different: it's likely
to generate two modprobe errors (once for unloading, once for loading)
but oh well… I could also have good for the `modprobe -q` option but
better keep all logs, just in case something strange happens…
You can check the code here:
https://salsa.debian.org/installer-team/hw-detect/-/blob/master/check-missing-firmware.sh#L290-303
(A variation would be to move the first modprobe dance below the loop,
and its execution depend on whether actual_module was ever set.)
The relevant part of syslog with that patch in place:
Jul 26 03:09:20 check-missing-firmware: looking for firmware file
rtw88/rtw8821c_fw.bin requested by rtw_8821ce
Jul 26 03:09:20 check-missing-firmware: missing firmware files
(rtw88/rtw8821c_fw.bin) for rtw_8821ce
Jul 26 03:09:26 check-missing-firmware: installing firmware package
/firmware/firmware-realtek_20210315-2_all.deb
Jul 26 03:09:31 check-missing-firmware: removing and loading kernel module
rtw_8821ce
Jul 26 03:09:31 check-missing-firmware: modprobe: FATAL: Module rtw_8821ce
not found.
Jul 26 03:09:31 check-missing-firmware: modprobe: FATAL: Module rtw_8821ce
not found in directory /lib/modules/5.10.0-8-amd64
Jul 26 03:09:31 check-missing-firmware: removing and loading kernel module
rtw88_8821ce as well (actual module for rtw_8821ce)
This should land in D-I Bullseye RC 3, in a few days.
Cheers,
--
Cyril Brulebois (k...@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
