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

Bug#973733: RTW88_8821ce module fails to find firmware during install and must be reloaded

Hi Daniel,

[ and the submitter, Brandon, back in cc. ]

Daniel Lewart <lewart3@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:

(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.

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply to: