Christian Hewitt <christianshewitt@gmail.com> wrote:
> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse
> physical map dump intermittently fails with -EBUSY during probe.
> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where
> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY
> bit after 1 second.
I'm checking internally how we handle this case.
[...]
>
> For context, firmware also fails (and recovers) sometimes:
Did you mean this doesn't always happen? sometimes?
We has seen similar log because of 36-bit DMA. Try below to force 32- or 36-
bit DMA to see if it can resolve problem in your platform.
diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireless/realtek/rtw89/pci.c
index 43c61b3dc969..9d003ab93c85 100644
--- a/drivers/net/wireless/realtek/rtw89/pci.c
+++ b/drivers/net/wireless/realtek/rtw89/pci.c
@@ -3305,6 +3305,8 @@ static bool rtw89_pci_is_dac_compatible_bridge(struct rtw89_dev *rtwdev)
if (!bridge)
return false;
+ return true; // or force to return false;
+
switch (bridge->vendor) {
case PCI_VENDOR_ID_INTEL:
return true;
>
> ROCK5B:~ # dmesg | grep rtw89
> [ 6.436873] rtw89_8852be 0002:21:00.0: loaded firmware rtw89/rtw8852b_fw-1.bin
> [ 6.437165] rtw89_8852be 0002:21:00.0: enabling device (0000 -> 0003)
> [ 6.450228] rtw89_8852be 0002:21:00.0: Firmware version 0.29.29.15 (6fb3ec41), cmd version 0, type 5
> [ 6.450239] rtw89_8852be 0002:21:00.0: Firmware version 0.29.29.15 (6fb3ec41), cmd version 0, type 3
> [ 7.864148] rtw89_8852be 0002:21:00.0: fw security fail
> [ 7.864154] rtw89_8852be 0002:21:00.0: download firmware fail
> [ 7.864160] rtw89_8852be 0002:21:00.0: [ERR]fwdl 0x1E0 = 0x62
> [ 7.864165] rtw89_8852be 0002:21:00.0: [ERR]fwdl 0x83F0 = 0x80011
> [ 7.864173] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
> [ 7.864188] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
> [ 7.864203] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864219] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864234] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864250] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
> [ 7.864265] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
> [ 7.864281] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
> [ 7.864296] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864311] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864327] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864342] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
> [ 7.864358] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864373] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864387] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 8.181342] rtw89_8852be 0002:21:00.0: chip info CID: 0, CV: 1, AID: 0, ACV: 1, RFE: 1
> [ 8.184322] rtw89_8852be 0002:21:00.0: rfkill hardware state changed to enable
> > On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Christian Hewitt <christianshewitt@gmail.com> wrote:
>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse
>> physical map dump intermittently fails with -EBUSY during probe.
>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where
>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY
>> bit after 1 second.
>
> I'm checking internally how we handle this case.
>
> [...]
>
>>
>> For context, firmware also fails (and recovers) sometimes:
>
> Did you mean this doesn't always happen? sometimes?
It’s another intermittent behaviour observed on this board (and not
related to the issue this patch targets). It occurs less frequently
than the efuse issue and the existing retry mechanism in the driver
ensures firmware load always succeeds.
> We has seen similar log because of 36-bit DMA. Try below to force 32- or 36-
> bit DMA to see if it can resolve problem in your platform.
I can experiment but this doesn’t happen often so I probably can’t
provide meaningful feedback.
Christian
> diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireless/realtek/rtw89/pci.c
> index 43c61b3dc969..9d003ab93c85 100644
> --- a/drivers/net/wireless/realtek/rtw89/pci.c
> +++ b/drivers/net/wireless/realtek/rtw89/pci.c
> @@ -3305,6 +3305,8 @@ static bool rtw89_pci_is_dac_compatible_bridge(struct rtw89_dev *rtwdev)
> if (!bridge)
> return false;
>
> + return true; // or force to return false;
> +
> switch (bridge->vendor) {
> case PCI_VENDOR_ID_INTEL:
> return true;
>
>>
>> ROCK5B:~ # dmesg | grep rtw89
>> [ 6.436873] rtw89_8852be 0002:21:00.0: loaded firmware rtw89/rtw8852b_fw-1.bin
>> [ 6.437165] rtw89_8852be 0002:21:00.0: enabling device (0000 -> 0003)
>> [ 6.450228] rtw89_8852be 0002:21:00.0: Firmware version 0.29.29.15 (6fb3ec41), cmd version 0, type 5
>> [ 6.450239] rtw89_8852be 0002:21:00.0: Firmware version 0.29.29.15 (6fb3ec41), cmd version 0, type 3
>> [ 7.864148] rtw89_8852be 0002:21:00.0: fw security fail
>> [ 7.864154] rtw89_8852be 0002:21:00.0: download firmware fail
>> [ 7.864160] rtw89_8852be 0002:21:00.0: [ERR]fwdl 0x1E0 = 0x62
>> [ 7.864165] rtw89_8852be 0002:21:00.0: [ERR]fwdl 0x83F0 = 0x80011
>> [ 7.864173] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
>> [ 7.864188] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
>> [ 7.864203] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864219] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864234] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864250] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
>> [ 7.864265] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
>> [ 7.864281] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
>> [ 7.864296] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864311] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864327] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864342] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
>> [ 7.864358] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864373] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864387] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 8.181342] rtw89_8852be 0002:21:00.0: chip info CID: 0, CV: 1, AID: 0, ACV: 1, RFE: 1
>> [ 8.184322] rtw89_8852be 0002:21:00.0: rfkill hardware state changed to enable
>>
>
>
Christian Hewitt <christianshewitt@gmail.com> wrote:
> > On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > Christian Hewitt <christianshewitt@gmail.com> wrote:
> >> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse
> >> physical map dump intermittently fails with -EBUSY during probe.
> >> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where
> >> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY
> >> bit after 1 second.
> >
> > I'm checking internally how we handle this case.
> >
> > [...]
> >
> >>
> >> For context, firmware also fails (and recovers) sometimes:
> >
> > Did you mean this doesn't always happen? sometimes?
>
> It’s another intermittent behaviour observed on this board (and not
> related to the issue this patch targets). It occurs less frequently
> than the efuse issue and the existing retry mechanism in the driver
> ensures firmware load always succeeds.
As intermittent behaviour, it might be not worth to try DMA.
Recently, we have some patches related to PCI hardware settings. Please
use the latest driver including patch [1] to see if it can be stable.
[1] af1e82232b98 ("wifi: rtw89: pci: restore LDO setting after device resume")
>
> > We has seen similar log because of 36-bit DMA. Try below to force 32- or 36-
> > bit DMA to see if it can resolve problem in your platform.
>
> I can experiment but this doesn’t happen often so I probably can’t
> provide meaningful feedback.
> On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Christian Hewitt <christianshewitt@gmail.com> wrote:
>>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
>>>
>>> Christian Hewitt <christianshewitt@gmail.com> wrote:
>>>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse
>>>> physical map dump intermittently fails with -EBUSY during probe.
>>>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where
>>>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY
>>>> bit after 1 second.
>>>
>>> I'm checking internally how we handle this case.
>>>
>>> [...]
>>>
>>>>
>>>> For context, firmware also fails (and recovers) sometimes:
>>>
>>> Did you mean this doesn't always happen? sometimes?
>>
>> It’s another intermittent behaviour observed on this board (and not
>> related to the issue this patch targets). It occurs less frequently
>> than the efuse issue and the existing retry mechanism in the driver
>> ensures firmware load always succeeds.
>
> As intermittent behaviour, it might be not worth to try DMA.
>
> Recently, we have some patches related to PCI hardware settings. Please
> use the latest driver including patch [1] to see if it can be stable.
>
> [1] af1e82232b98 ("wifi: rtw89: pci: restore LDO setting after device resume")
The efuse fail snippet that I posted alongside the patch was from a
Linux 7.0-rc1 kernel so that patch was already present.
>> We has seen similar log because of 36-bit DMA. Try below to force 32- or 36-
>>> bit DMA to see if it can resolve problem in your platform.
>>
>> I can experiment but this doesn’t happen often so I probably can’t
>> provide meaningful feedback.
Christian Hewitt <christianshewitt@gmail.com> wrote: > > > On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > > > > Christian Hewitt <christianshewitt@gmail.com> wrote: > >>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>> > >>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse > >>>> physical map dump intermittently fails with -EBUSY during probe. > >>>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where > >>>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY > >>>> bit after 1 second. > >>> > >>> I'm checking internally how we handle this case. Sorry for the late. We encountered WiFi/BT reading efuse at the same time causing similar problem as yours. The workaround is like yours, which adds timeout time. > >>> > >>> [...] > >>> > >>>> > >>>> For context, firmware also fails (and recovers) sometimes: > >>> > >>> Did you mean this doesn't always happen? sometimes? > >> > >> It’s another intermittent behaviour observed on this board (and not > >> related to the issue this patch targets). It occurs less frequently > >> than the efuse issue and the existing retry mechanism in the driver > >> ensures firmware load always succeeds. This might be the same cause due to reading efuse in firmware. Though we can add more timeout and retry times as workaround, I wonder if you can control loading time of WiFi and BT kernel modules? More, can you do experiment that you load BT module first, and then load WiFi module after 10 seconds (choose a large number intentionally, or even larger)? Ping-Ke
> On 9 Mar 2026, at 6:35 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > > Christian Hewitt <christianshewitt@gmail.com> wrote: >> >>> On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>> >>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>>>> >>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>>>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse >>>>>> physical map dump intermittently fails with -EBUSY during probe. >>>>>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where >>>>>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY >>>>>> bit after 1 second. >>>>> >>>>> I'm checking internally how we handle this case. > > Sorry for the late. > > We encountered WiFi/BT reading efuse at the same time causing similar > problem as yours. The workaround is like yours, which adds timeout > time. > >>>>> >>>>> [...] >>>>> >>>>>> >>>>>> For context, firmware also fails (and recovers) sometimes: >>>>> >>>>> Did you mean this doesn't always happen? sometimes? >>>> >>>> It’s another intermittent behaviour observed on this board (and not >>>> related to the issue this patch targets). It occurs less frequently >>>> than the efuse issue and the existing retry mechanism in the driver >>>> ensures firmware load always succeeds. > > This might be the same cause due to reading efuse in firmware. > > Though we can add more timeout and retry times as workaround, I wonder > if you can control loading time of WiFi and BT kernel modules? > > More, can you do experiment that you load BT module first, and then load > WiFi module after 10 seconds (choose a large number intentionally, or > even larger)? https://paste.libreelec.tv/charmed-turkey.sh I’ve run the above script ^ which removes the wifi and bt modules in sequence then reloads them in the reverse order with a delay between bt and wifi modules loading, then checks for error messages. Over 200 test cycles with a 10s delay all were clean (no errors). I also ran cycles with a 2 second delay and 0 second delay before starting wifi module load and those were clear too. I guess that proves sequencing avoids the efuse contention issue? - although it’s not possible in the real-world so not sure there’s huge value in knowing that :) Christian
Christian Hewitt <christianshewitt@gmail.com> wrote: > > > On 9 Mar 2026, at 6:35 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > > > > Christian Hewitt <christianshewitt@gmail.com> wrote: > >> > >>> On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>> > >>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>>>> > >>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>>>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse > >>>>>> physical map dump intermittently fails with -EBUSY during probe. > >>>>>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where > >>>>>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY > >>>>>> bit after 1 second. > >>>>> > >>>>> I'm checking internally how we handle this case. > > > > Sorry for the late. > > > > We encountered WiFi/BT reading efuse at the same time causing similar > > problem as yours. The workaround is like yours, which adds timeout > > time. > > > >>>>> > >>>>> [...] > >>>>> > >>>>>> > >>>>>> For context, firmware also fails (and recovers) sometimes: > >>>>> > >>>>> Did you mean this doesn't always happen? sometimes? > >>>> > >>>> It’s another intermittent behaviour observed on this board (and not > >>>> related to the issue this patch targets). It occurs less frequently > >>>> than the efuse issue and the existing retry mechanism in the driver > >>>> ensures firmware load always succeeds. > > > > This might be the same cause due to reading efuse in firmware. > > > > Though we can add more timeout and retry times as workaround, I wonder > > if you can control loading time of WiFi and BT kernel modules? > > > > More, can you do experiment that you load BT module first, and then load > > WiFi module after 10 seconds (choose a large number intentionally, or > > even larger)? > > https://paste.libreelec.tv/charmed-turkey.sh > > I’ve run the above script ^ which removes the wifi and bt modules in > sequence then reloads them in the reverse order with a delay between > bt and wifi modules loading, then checks for error messages. Over 200 > test cycles with a 10s delay all were clean (no errors). I also ran > cycles with a 2 second delay and 0 second delay before starting wifi > module load and those were clear too. I guess that proves sequencing > avoids the efuse contention issue? - although it’s not possible in > the real-world so not sure there’s huge value in knowing that :) Thanks for the experiments. Still want to know is it possible to change sequence/time of loading kernel modules at boot time from system level? I mean can you adjust the sequence in the Rock 5B board? In addition, did below messages not appear in these experiments? [ 7.864148] rtw89_8852be 0002:21:00.0: fw security fail [ 7.864154] rtw89_8852be 0002:21:00.0: download firmware fail Ping-Ke
> On 11 Mar 2026, at 7:05 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > > Christian Hewitt <christianshewitt@gmail.com> wrote: >> >>> On 9 Mar 2026, at 6:35 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>> >>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>> >>>>> On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>>>> >>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>>>>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>>>>>> >>>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>>>>>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse >>>>>>>> physical map dump intermittently fails with -EBUSY during probe. >>>>>>>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where >>>>>>>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY >>>>>>>> bit after 1 second. >>>>>>> >>>>>>> I'm checking internally how we handle this case. >>> >>> Sorry for the late. >>> >>> We encountered WiFi/BT reading efuse at the same time causing similar >>> problem as yours. The workaround is like yours, which adds timeout >>> time. >>> >>>>>>> >>>>>>> [...] >>>>>>> >>>>>>>> >>>>>>>> For context, firmware also fails (and recovers) sometimes: >>>>>>> >>>>>>> Did you mean this doesn't always happen? sometimes? >>>>>> >>>>>> It’s another intermittent behaviour observed on this board (and not >>>>>> related to the issue this patch targets). It occurs less frequently >>>>>> than the efuse issue and the existing retry mechanism in the driver >>>>>> ensures firmware load always succeeds. >>> >>> This might be the same cause due to reading efuse in firmware. >>> >>> Though we can add more timeout and retry times as workaround, I wonder >>> if you can control loading time of WiFi and BT kernel modules? >>> >>> More, can you do experiment that you load BT module first, and then load >>> WiFi module after 10 seconds (choose a large number intentionally, or >>> even larger)? >> >> https://paste.libreelec.tv/charmed-turkey.sh >> >> I’ve run the above script ^ which removes the wifi and bt modules in >> sequence then reloads them in the reverse order with a delay between >> bt and wifi modules loading, then checks for error messages. Over 200 >> test cycles with a 10s delay all were clean (no errors). I also ran >> cycles with a 2 second delay and 0 second delay before starting wifi >> module load and those were clear too. I guess that proves sequencing >> avoids the efuse contention issue? - although it’s not possible in >> the real-world so not sure there’s huge value in knowing that :) > > Thanks for the experiments. > > Still want to know is it possible to change sequence/time of loading > kernel modules at boot time from system level? I mean can you adjust > the sequence in the Rock 5B board? I’m not a kernel expert, but I’ve always understood module probe and load ordering to not be guaranteed; as many things run in parallel and are highly subjective to the specific hardware capabilities and kernel config being used. > In addition, did below messages not appear in these experiments? > > [ 7.864148] rtw89_8852be 0002:21:00.0: fw security fail > [ 7.864154] rtw89_8852be 0002:21:00.0: download firmware fail No, because even if we have a 0s delay between each group of modules being loaded, they are loaded in series, so we workaround the issue. Tweaking the script to background the module load loops so both run in parallel would be closer to normal conditions, and I would expect to start seeing failures and the retry mechanisms within the modules (as added in this patch) being triggered. Christian
Christian Hewitt <christianshewitt@gmail.com> wrote: > > On 11 Mar 2026, at 7:05 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > > > > Christian Hewitt <christianshewitt@gmail.com> wrote: > >> > >>> On 9 Mar 2026, at 6:35 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>> > >>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>> > >>>>> On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>>>> > >>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>>>>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>>>>>> > >>>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>>>>>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse > >>>>>>>> physical map dump intermittently fails with -EBUSY during probe. > >>>>>>>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where > >>>>>>>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY > >>>>>>>> bit after 1 second. > >>>>>>> > >>>>>>> I'm checking internally how we handle this case. > >>> > >>> Sorry for the late. > >>> > >>> We encountered WiFi/BT reading efuse at the same time causing similar > >>> problem as yours. The workaround is like yours, which adds timeout > >>> time. > >>> > >>>>>>> > >>>>>>> [...] > >>>>>>> > >>>>>>>> > >>>>>>>> For context, firmware also fails (and recovers) sometimes: > >>>>>>> > >>>>>>> Did you mean this doesn't always happen? sometimes? > >>>>>> > >>>>>> It’s another intermittent behaviour observed on this board (and not > >>>>>> related to the issue this patch targets). It occurs less frequently > >>>>>> than the efuse issue and the existing retry mechanism in the driver > >>>>>> ensures firmware load always succeeds. > >>> > >>> This might be the same cause due to reading efuse in firmware. > >>> > >>> Though we can add more timeout and retry times as workaround, I wonder > >>> if you can control loading time of WiFi and BT kernel modules? > >>> > >>> More, can you do experiment that you load BT module first, and then load > >>> WiFi module after 10 seconds (choose a large number intentionally, or > >>> even larger)? > >> > >> https://paste.libreelec.tv/charmed-turkey.sh > >> > >> I’ve run the above script ^ which removes the wifi and bt modules in > >> sequence then reloads them in the reverse order with a delay between > >> bt and wifi modules loading, then checks for error messages. Over 200 > >> test cycles with a 10s delay all were clean (no errors). I also ran > >> cycles with a 2 second delay and 0 second delay before starting wifi > >> module load and those were clear too. I guess that proves sequencing > >> avoids the efuse contention issue? - although it’s not possible in > >> the real-world so not sure there’s huge value in knowing that :) > > > > Thanks for the experiments. > > > > Still want to know is it possible to change sequence/time of loading > > kernel modules at boot time from system level? I mean can you adjust > > the sequence in the Rock 5B board? > > I’m not a kernel expert, but I’ve always understood module probe and > load ordering to not be guaranteed; as many things run in parallel and > are highly subjective to the specific hardware capabilities and kernel > config being used. I have heard people about changing sequence/time of kernel modules, so I'd like you can try this method. I did ask AI, it said it is possible to create a .conf file under /etc/modprobe.d/ and use `softdep` syntax to ensure loading sequence. Could you try this? > > > In addition, did below messages not appear in these experiments? > > > > [ 7.864148] rtw89_8852be 0002:21:00.0: fw security fail > > [ 7.864154] rtw89_8852be 0002:21:00.0: download firmware fail > > No, because even if we have a 0s delay between each group of modules > being loaded, they are loaded in series, so we workaround the issue. > Tweaking the script to background the module load loops so both run > in parallel would be closer to normal conditions, and I would expect > to start seeing failures and the retry mechanisms within the modules > (as added in this patch) being triggered. Additional question for downloading firmware. As you reported this issue initially (load modules at boot time in parallel), it seems appear this message by chance. Since this driver will retry to download firmware, will it successfully downloads firmware finally? Or it still fails to download after 5 times retry? Ping-Ke
> On 12 Mar 2026, at 6:22 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > > Christian Hewitt <christianshewitt@gmail.com> wrote: >>> On 11 Mar 2026, at 7:05 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>> >>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>> >>>>> On 9 Mar 2026, at 6:35 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>>>> >>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>>>> >>>>>>> On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>>>>>> >>>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>>>>>>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>>>>>>>> >>>>>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>>>>>>>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse >>>>>>>>>> physical map dump intermittently fails with -EBUSY during probe. >>>>>>>>>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where >>>>>>>>>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY >>>>>>>>>> bit after 1 second. >>>>>>>>> >>>>>>>>> I'm checking internally how we handle this case. >>>>> >>>>> Sorry for the late. >>>>> >>>>> We encountered WiFi/BT reading efuse at the same time causing similar >>>>> problem as yours. The workaround is like yours, which adds timeout >>>>> time. >>>>> >>>>>>>>> >>>>>>>>> [...] >>>>>>>>> >>>>>>>>>> >>>>>>>>>> For context, firmware also fails (and recovers) sometimes: >>>>>>>>> >>>>>>>>> Did you mean this doesn't always happen? sometimes? >>>>>>>> >>>>>>>> It’s another intermittent behaviour observed on this board (and not >>>>>>>> related to the issue this patch targets). It occurs less frequently >>>>>>>> than the efuse issue and the existing retry mechanism in the driver >>>>>>>> ensures firmware load always succeeds. >>>>> >>>>> This might be the same cause due to reading efuse in firmware. >>>>> >>>>> Though we can add more timeout and retry times as workaround, I wonder >>>>> if you can control loading time of WiFi and BT kernel modules? >>>>> >>>>> More, can you do experiment that you load BT module first, and then load >>>>> WiFi module after 10 seconds (choose a large number intentionally, or >>>>> even larger)? >>>> >>>> https://paste.libreelec.tv/charmed-turkey.sh >>>> >>>> I’ve run the above script ^ which removes the wifi and bt modules in >>>> sequence then reloads them in the reverse order with a delay between >>>> bt and wifi modules loading, then checks for error messages. Over 200 >>>> test cycles with a 10s delay all were clean (no errors). I also ran >>>> cycles with a 2 second delay and 0 second delay before starting wifi >>>> module load and those were clear too. I guess that proves sequencing >>>> avoids the efuse contention issue? - although it’s not possible in >>>> the real-world so not sure there’s huge value in knowing that :) >>> >>> Thanks for the experiments. >>> >>> Still want to know is it possible to change sequence/time of loading >>> kernel modules at boot time from system level? I mean can you adjust >>> the sequence in the Rock 5B board? >> >> I’m not a kernel expert, but I’ve always understood module probe and >> load ordering to not be guaranteed; as many things run in parallel and >> are highly subjective to the specific hardware capabilities and kernel >> config being used. > > I have heard people about changing sequence/time of kernel modules, so > I'd like you can try this method. > > I did ask AI, it said it is possible to create a .conf file under > /etc/modprobe.d/ and use `softdep` syntax to ensure loading sequence. > Could you try this? I can test this, but even if it works it’s not a fix because modprobe confs configured in userspace are only used with loadable modules that have been compiled with =m, not build-in modules that are resident in kernel memory and compiled with =y; and distros are free to choose how their kernel is configured. NB: I’m not sure if there are any general kernel rules for this, but I’d expect there to be general principle of modules being resilient to transient host states and not depending on userspace packaging to load correctly? >> In addition, did below messages not appear in these experiments? >>> >>> [ 7.864148] rtw89_8852be 0002:21:00.0: fw security fail >>> [ 7.864154] rtw89_8852be 0002:21:00.0: download firmware fail >> >> No, because even if we have a 0s delay between each group of modules >> being loaded, they are loaded in series, so we workaround the issue. >> Tweaking the script to background the module load loops so both run >> in parallel would be closer to normal conditions, and I would expect >> to start seeing failures and the retry mechanisms within the modules >> (as added in this patch) being triggered. > > Additional question for downloading firmware. As you reported this > issue initially (load modules at boot time in parallel), it seems > appear this message by chance. Since this driver will retry to download > firmware, will it successfully downloads firmware finally? Or it still > fails to download after 5 times retry? I have only seen firmware load fail a handful of times in many hundreds of boots and each time one retry attempt resulted in success. To be clear; I have am not reporting firwmare loading as a problem, it is not an issue for me. I’ve mentioned it only for context, i.e. it shows that a simple retry mechanism is effective at handling the similar issue with efuse map. Christian
Christian Hewitt <christianshewitt@gmail.com> wrote: > > On 12 Mar 2026, at 6:22 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > > > > Christian Hewitt <christianshewitt@gmail.com> wrote: > >>> On 11 Mar 2026, at 7:05 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>> > >>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>> > >>>>> On 9 Mar 2026, at 6:35 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>>>> > >>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>>>> > >>>>>>> On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>>>>>> > >>>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>>>>>>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>>>>>>>> > >>>>>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>>>>>>>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse > >>>>>>>>>> physical map dump intermittently fails with -EBUSY during probe. > >>>>>>>>>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where > >>>>>>>>>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY > >>>>>>>>>> bit after 1 second. > >>>>>>>>> > >>>>>>>>> I'm checking internally how we handle this case. > >>>>> > >>>>> Sorry for the late. > >>>>> > >>>>> We encountered WiFi/BT reading efuse at the same time causing similar > >>>>> problem as yours. The workaround is like yours, which adds timeout > >>>>> time. > >>>>> > >>>>>>>>> > >>>>>>>>> [...] > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> For context, firmware also fails (and recovers) sometimes: > >>>>>>>>> > >>>>>>>>> Did you mean this doesn't always happen? sometimes? > >>>>>>>> > >>>>>>>> It’s another intermittent behaviour observed on this board (and not > >>>>>>>> related to the issue this patch targets). It occurs less frequently > >>>>>>>> than the efuse issue and the existing retry mechanism in the driver > >>>>>>>> ensures firmware load always succeeds. > >>>>> > >>>>> This might be the same cause due to reading efuse in firmware. > >>>>> > >>>>> Though we can add more timeout and retry times as workaround, I wonder > >>>>> if you can control loading time of WiFi and BT kernel modules? > >>>>> > >>>>> More, can you do experiment that you load BT module first, and then load > >>>>> WiFi module after 10 seconds (choose a large number intentionally, or > >>>>> even larger)? > >>>> > >>>> https://paste.libreelec.tv/charmed-turkey.sh > >>>> > >>>> I’ve run the above script ^ which removes the wifi and bt modules in > >>>> sequence then reloads them in the reverse order with a delay between > >>>> bt and wifi modules loading, then checks for error messages. Over 200 > >>>> test cycles with a 10s delay all were clean (no errors). I also ran > >>>> cycles with a 2 second delay and 0 second delay before starting wifi > >>>> module load and those were clear too. I guess that proves sequencing > >>>> avoids the efuse contention issue? - although it’s not possible in > >>>> the real-world so not sure there’s huge value in knowing that :) > >>> > >>> Thanks for the experiments. > >>> > >>> Still want to know is it possible to change sequence/time of loading > >>> kernel modules at boot time from system level? I mean can you adjust > >>> the sequence in the Rock 5B board? > >> > >> I’m not a kernel expert, but I’ve always understood module probe and > >> load ordering to not be guaranteed; as many things run in parallel and > >> are highly subjective to the specific hardware capabilities and kernel > >> config being used. > > > > I have heard people about changing sequence/time of kernel modules, so > > I'd like you can try this method. > > > > I did ask AI, it said it is possible to create a .conf file under > > /etc/modprobe.d/ and use `softdep` syntax to ensure loading sequence. > > Could you try this? > > I can test this, but even if it works it’s not a fix because modprobe > confs configured in userspace are only used with loadable modules that > have been compiled with =m, not build-in modules that are resident in > kernel memory and compiled with =y; and distros are free to choose how > their kernel is configured. NB: I’m not sure if there are any general > kernel rules for this, but I’d expect there to be general principle of > modules being resilient to transient host states and not depending on > userspace packaging to load correctly? I think built-in modules will be loaded sequentially (not in parallel) by device_initicall(), so BT and WiFi drivers will not read efuse at the same time. > > >> In addition, did below messages not appear in these experiments? > >>> > >>> [ 7.864148] rtw89_8852be 0002:21:00.0: fw security fail > >>> [ 7.864154] rtw89_8852be 0002:21:00.0: download firmware fail > >> > >> No, because even if we have a 0s delay between each group of modules > >> being loaded, they are loaded in series, so we workaround the issue. > >> Tweaking the script to background the module load loops so both run > >> in parallel would be closer to normal conditions, and I would expect > >> to start seeing failures and the retry mechanisms within the modules > >> (as added in this patch) being triggered. > > > > Additional question for downloading firmware. As you reported this > > issue initially (load modules at boot time in parallel), it seems > > appear this message by chance. Since this driver will retry to download > > firmware, will it successfully downloads firmware finally? Or it still > > fails to download after 5 times retry? > > I have only seen firmware load fail a handful of times in many hundreds > of boots and each time one retry attempt resulted in success. To be > clear; I have am not reporting firwmare loading as a problem, it is not > an issue for me. I’ve mentioned it only for context, i.e. it shows that > a simple retry mechanism is effective at handling the similar issue with > efuse map. I have this question because I wonder downloading firmware issue might be also a reading efuse issue. If so, retry might resolve as well. As your results, it looks like to retry reading efuse can resolve all issues you found. What do you think? Ping-Ke
> On 12 Mar 2026, at 11:39 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > > Christian Hewitt <christianshewitt@gmail.com> wrote: >>> On 12 Mar 2026, at 6:22 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>> >>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>>> On 11 Mar 2026, at 7:05 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>>>> >>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>>>> >>>>>>> On 9 Mar 2026, at 6:35 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>>>>>> >>>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>>>>>> >>>>>>>>> On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>>>>>>>> >>>>>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>>>>>>>>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: >>>>>>>>>>>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse >>>>>>>>>>>> physical map dump intermittently fails with -EBUSY during probe. >>>>>>>>>>>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where >>>>>>>>>>>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY >>>>>>>>>>>> bit after 1 second. >>>>>>>>>>> >>>>>>>>>>> I'm checking internally how we handle this case. >>>>>>> >>>>>>> Sorry for the late. >>>>>>> >>>>>>> We encountered WiFi/BT reading efuse at the same time causing similar >>>>>>> problem as yours. The workaround is like yours, which adds timeout >>>>>>> time. >>>>>>> >>>>>>>>>>> >>>>>>>>>>> [...] >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> For context, firmware also fails (and recovers) sometimes: >>>>>>>>>>> >>>>>>>>>>> Did you mean this doesn't always happen? sometimes? >>>>>>>>>> >>>>>>>>>> It’s another intermittent behaviour observed on this board (and not >>>>>>>>>> related to the issue this patch targets). It occurs less frequently >>>>>>>>>> than the efuse issue and the existing retry mechanism in the driver >>>>>>>>>> ensures firmware load always succeeds. >>>>>>> >>>>>>> This might be the same cause due to reading efuse in firmware. >>>>>>> >>>>>>> Though we can add more timeout and retry times as workaround, I wonder >>>>>>> if you can control loading time of WiFi and BT kernel modules? >>>>>>> >>>>>>> More, can you do experiment that you load BT module first, and then load >>>>>>> WiFi module after 10 seconds (choose a large number intentionally, or >>>>>>> even larger)? >>>>>> >>>>>> https://paste.libreelec.tv/charmed-turkey.sh >>>>>> >>>>>> I’ve run the above script ^ which removes the wifi and bt modules in >>>>>> sequence then reloads them in the reverse order with a delay between >>>>>> bt and wifi modules loading, then checks for error messages. Over 200 >>>>>> test cycles with a 10s delay all were clean (no errors). I also ran >>>>>> cycles with a 2 second delay and 0 second delay before starting wifi >>>>>> module load and those were clear too. I guess that proves sequencing >>>>>> avoids the efuse contention issue? - although it’s not possible in >>>>>> the real-world so not sure there’s huge value in knowing that :) >>>>> >>>>> Thanks for the experiments. >>>>> >>>>> Still want to know is it possible to change sequence/time of loading >>>>> kernel modules at boot time from system level? I mean can you adjust >>>>> the sequence in the Rock 5B board? >>>> >>>> I’m not a kernel expert, but I’ve always understood module probe and >>>> load ordering to not be guaranteed; as many things run in parallel and >>>> are highly subjective to the specific hardware capabilities and kernel >>>> config being used. >>> >>> I have heard people about changing sequence/time of kernel modules, so >>> I'd like you can try this method. >>> >>> I did ask AI, it said it is possible to create a .conf file under >>> /etc/modprobe.d/ and use `softdep` syntax to ensure loading sequence. >>> Could you try this? >> >> I can test this, but even if it works it’s not a fix because modprobe >> confs configured in userspace are only used with loadable modules that >> have been compiled with =m, not build-in modules that are resident in >> kernel memory and compiled with =y; and distros are free to choose how >> their kernel is configured. NB: I’m not sure if there are any general >> kernel rules for this, but I’d expect there to be general principle of >> modules being resilient to transient host states and not depending on >> userspace packaging to load correctly? > > I think built-in modules will be loaded sequentially (not in parallel) > by device_initicall(), so BT and WiFi drivers will not read efuse > at the same time. Even if built-in modules are loaded sequentially, the kernel still has many dynamically loaded modules; and distros can configure that mix as they like, so you still cannot predict or guarantee the outcome. That could be changed by requiring rtw89 modules to be =y, but that goes against the principles of a modular kernel and I’d expect appropriately rude comments to the idea if submitted :) >>>> In addition, did below messages not appear in these experiments? >>>>> >>>>> [ 7.864148] rtw89_8852be 0002:21:00.0: fw security fail >>>>> [ 7.864154] rtw89_8852be 0002:21:00.0: download firmware fail >>>> >>>> No, because even if we have a 0s delay between each group of modules >>>> being loaded, they are loaded in series, so we workaround the issue. >>>> Tweaking the script to background the module load loops so both run >>>> in parallel would be closer to normal conditions, and I would expect >>>> to start seeing failures and the retry mechanisms within the modules >>>> (as added in this patch) being triggered. >>> >>> Additional question for downloading firmware. As you reported this >>> issue initially (load modules at boot time in parallel), it seems >>> appear this message by chance. Since this driver will retry to download >>> firmware, will it successfully downloads firmware finally? Or it still >>> fails to download after 5 times retry? >> >> I have only seen firmware load fail a handful of times in many hundreds >> of boots and each time one retry attempt resulted in success. To be >> clear; I have am not reporting firwmare loading as a problem, it is not >> an issue for me. I’ve mentioned it only for context, i.e. it shows that >> a simple retry mechanism is effective at handling the similar issue with >> efuse map. > > I have this question because I wonder downloading firmware issue might be > also a reading efuse issue. If so, retry might resolve as well. Hard to know, but it's an infrequent event and the existing retry mechanism appears to work fine. > As your results, it looks like to retry reading efuse can resolve all > issues you found. What do you think? The patch submitted resolves the efuse map dump for me. If there are more efuse accesses that need to be addressed I haven’t seen them in tests. If you are hinting to abstract things further I’d ask you to please propose an alternative patch that I can test for you; I’m firmly at the novice end of kernel contributors and unlikely to spot where changes might be needed without being spoon-fed rather explicit instructions :) Christian
Christian Hewitt <christianshewitt@gmail.com> wrote: > > > On 12 Mar 2026, at 11:39 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > > > > Christian Hewitt <christianshewitt@gmail.com> wrote: > >>> On 12 Mar 2026, at 6:22 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>> > >>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>>> On 11 Mar 2026, at 7:05 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>>>> > >>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>>>> > >>>>>>> On 9 Mar 2026, at 6:35 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>>>>>> > >>>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>>>>>> > >>>>>>>>> On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>>>>>>>> > >>>>>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>>>>>>>>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Christian Hewitt <christianshewitt@gmail.com> wrote: > >>>>>>>>>>>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse > >>>>>>>>>>>> physical map dump intermittently fails with -EBUSY during probe. > >>>>>>>>>>>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where > >>>>>>>>>>>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY > >>>>>>>>>>>> bit after 1 second. > >>>>>>>>>>> > >>>>>>>>>>> I'm checking internally how we handle this case. > >>>>>>> > >>>>>>> Sorry for the late. > >>>>>>> > >>>>>>> We encountered WiFi/BT reading efuse at the same time causing similar > >>>>>>> problem as yours. The workaround is like yours, which adds timeout > >>>>>>> time. > >>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> [...] > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> For context, firmware also fails (and recovers) sometimes: > >>>>>>>>>>> > >>>>>>>>>>> Did you mean this doesn't always happen? sometimes? > >>>>>>>>>> > >>>>>>>>>> It’s another intermittent behaviour observed on this board (and not > >>>>>>>>>> related to the issue this patch targets). It occurs less frequently > >>>>>>>>>> than the efuse issue and the existing retry mechanism in the driver > >>>>>>>>>> ensures firmware load always succeeds. > >>>>>>> > >>>>>>> This might be the same cause due to reading efuse in firmware. > >>>>>>> > >>>>>>> Though we can add more timeout and retry times as workaround, I wonder > >>>>>>> if you can control loading time of WiFi and BT kernel modules? > >>>>>>> > >>>>>>> More, can you do experiment that you load BT module first, and then load > >>>>>>> WiFi module after 10 seconds (choose a large number intentionally, or > >>>>>>> even larger)? > >>>>>> > >>>>>> https://paste.libreelec.tv/charmed-turkey.sh > >>>>>> > >>>>>> I’ve run the above script ^ which removes the wifi and bt modules in > >>>>>> sequence then reloads them in the reverse order with a delay between > >>>>>> bt and wifi modules loading, then checks for error messages. Over 200 > >>>>>> test cycles with a 10s delay all were clean (no errors). I also ran > >>>>>> cycles with a 2 second delay and 0 second delay before starting wifi > >>>>>> module load and those were clear too. I guess that proves sequencing > >>>>>> avoids the efuse contention issue? - although it’s not possible in > >>>>>> the real-world so not sure there’s huge value in knowing that :) > >>>>> > >>>>> Thanks for the experiments. > >>>>> > >>>>> Still want to know is it possible to change sequence/time of loading > >>>>> kernel modules at boot time from system level? I mean can you adjust > >>>>> the sequence in the Rock 5B board? > >>>> > >>>> I’m not a kernel expert, but I’ve always understood module probe and > >>>> load ordering to not be guaranteed; as many things run in parallel and > >>>> are highly subjective to the specific hardware capabilities and kernel > >>>> config being used. > >>> > >>> I have heard people about changing sequence/time of kernel modules, so > >>> I'd like you can try this method. > >>> > >>> I did ask AI, it said it is possible to create a .conf file under > >>> /etc/modprobe.d/ and use `softdep` syntax to ensure loading sequence. > >>> Could you try this? > >> > >> I can test this, but even if it works it’s not a fix because modprobe > >> confs configured in userspace are only used with loadable modules that > >> have been compiled with =m, not build-in modules that are resident in > >> kernel memory and compiled with =y; and distros are free to choose how > >> their kernel is configured. NB: I’m not sure if there are any general > >> kernel rules for this, but I’d expect there to be general principle of > >> modules being resilient to transient host states and not depending on > >> userspace packaging to load correctly? > > > > I think built-in modules will be loaded sequentially (not in parallel) > > by device_initicall(), so BT and WiFi drivers will not read efuse > > at the same time. > > Even if built-in modules are loaded sequentially, the kernel still has > many dynamically loaded modules; and distros can configure that mix as > they like, so you still cannot predict or guarantee the outcome. That > could be changed by requiring rtw89 modules to be =y, but that goes > against the principles of a modular kernel and I’d expect appropriately > rude comments to the idea if submitted :) As I know, dynamical modules are executed after init process, but that's not your case. Let's clarify if /etc/modprobe.d/ with `softdep` option can resolve your problem. I'd like to know the result. :) > > >>>> In addition, did below messages not appear in these experiments? > >>>>> > >>>>> [ 7.864148] rtw89_8852be 0002:21:00.0: fw security fail > >>>>> [ 7.864154] rtw89_8852be 0002:21:00.0: download firmware fail > >>>> > >>>> No, because even if we have a 0s delay between each group of modules > >>>> being loaded, they are loaded in series, so we workaround the issue. > >>>> Tweaking the script to background the module load loops so both run > >>>> in parallel would be closer to normal conditions, and I would expect > >>>> to start seeing failures and the retry mechanisms within the modules > >>>> (as added in this patch) being triggered. > >>> > >>> Additional question for downloading firmware. As you reported this > >>> issue initially (load modules at boot time in parallel), it seems > >>> appear this message by chance. Since this driver will retry to download > >>> firmware, will it successfully downloads firmware finally? Or it still > >>> fails to download after 5 times retry? > >> > >> I have only seen firmware load fail a handful of times in many hundreds > >> of boots and each time one retry attempt resulted in success. To be > >> clear; I have am not reporting firwmare loading as a problem, it is not > >> an issue for me. I’ve mentioned it only for context, i.e. it shows that > >> a simple retry mechanism is effective at handling the similar issue with > >> efuse map. > > > > I have this question because I wonder downloading firmware issue might be > > also a reading efuse issue. If so, retry might resolve as well. > > Hard to know, but it's an infrequent event and the existing retry mechanism > appears to work fine. > > > As your results, it looks like to retry reading efuse can resolve all > > issues you found. What do you think? > > The patch submitted resolves the efuse map dump for me. If there are more > efuse accesses that need to be addressed I haven’t seen them in tests. If > you are hinting to abstract things further I’d ask you to please propose > an alternative patch that I can test for you; I’m firmly at the novice end > of kernel contributors and unlikely to spot where changes might be needed > without being spoon-fed rather explicit instructions :) I will start to review this patch in detail and consider if another alternative method. Ping-Ke
© 2016 - 2026 Red Hat, Inc.