There is no completion signaling for tx_wait skbs on USB part. This means
rtw89_core_tx_kick_off_and_wait() always returns with a timeout.
Moreover, recent rework of tx_wait objects lifecycle handling made the
driver be responsible for freeing the associated skbs, not the core
ieee80211 stack. Lack of completion signaling would cause those objects
being kept in driver internal tx_waits queue until rtw89_hci_reset()
occurs, and then a double free would happen.
Extract TX status handling into a separate function, like its
rtw89_pci_tx_status() counterpart. Signal completion from there.
Found by Linux Verification Center (linuxtesting.org).
Fixes: 2135c28be6a8 ("wifi: rtw89: Add usb.{c,h}")
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
---
New series iteration -> new nuances found.
It seems the two previous patches from the series would not be too great
in USB case because there is no completion signaling for tx_wait skbs
there.
I don't have this hardware so *the patch is compile tested only*. It'd
be nice if someone gave it a run on top of two previous patches of the
series, thanks!
drivers/net/wireless/realtek/rtw89/usb.c | 36 +++++++++++++++---------
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/usb.c b/drivers/net/wireless/realtek/rtw89/usb.c
index 6cf89aee252e..10fe19bd5166 100644
--- a/drivers/net/wireless/realtek/rtw89/usb.c
+++ b/drivers/net/wireless/realtek/rtw89/usb.c
@@ -188,11 +188,32 @@ static u8 rtw89_usb_get_bulkout_id(u8 ch_dma)
}
}
+static void rtw89_usb_tx_status(struct rtw89_dev *rtwdev, struct sk_buff *skb,
+ int status)
+{
+ struct rtw89_tx_skb_data *skb_data = RTW89_TX_SKB_CB(skb);
+ struct ieee80211_tx_info *info;
+
+ if (rtw89_core_tx_wait_complete(rtwdev, skb_data, status == 0))
+ return;
+
+ info = IEEE80211_SKB_CB(skb);
+ ieee80211_tx_info_clear_status(info);
+
+ if (status == 0) {
+ if (info->flags & IEEE80211_TX_CTL_NO_ACK)
+ info->flags |= IEEE80211_TX_STAT_NOACK_TRANSMITTED;
+ else
+ info->flags |= IEEE80211_TX_STAT_ACK;
+ }
+
+ ieee80211_tx_status_irqsafe(rtwdev->hw, skb);
+}
+
static void rtw89_usb_write_port_complete(struct urb *urb)
{
struct rtw89_usb_tx_ctrl_block *txcb = urb->context;
struct rtw89_dev *rtwdev = txcb->rtwdev;
- struct ieee80211_tx_info *info;
struct rtw89_txwd_body *txdesc;
struct sk_buff *skb;
u32 txdesc_size;
@@ -214,18 +235,7 @@ static void rtw89_usb_write_port_complete(struct urb *urb)
txdesc_size += rtwdev->chip->txwd_info_size;
skb_pull(skb, txdesc_size);
-
- info = IEEE80211_SKB_CB(skb);
- ieee80211_tx_info_clear_status(info);
-
- if (urb->status == 0) {
- if (info->flags & IEEE80211_TX_CTL_NO_ACK)
- info->flags |= IEEE80211_TX_STAT_NOACK_TRANSMITTED;
- else
- info->flags |= IEEE80211_TX_STAT_ACK;
- }
-
- ieee80211_tx_status_irqsafe(rtwdev->hw, skb);
+ rtw89_usb_tx_status(rtwdev, skb, urb->status);
}
switch (urb->status) {
--
2.51.0On 29/08/2025 00:11, Fedor Pchelkin wrote:
> There is no completion signaling for tx_wait skbs on USB part. This means
> rtw89_core_tx_kick_off_and_wait() always returns with a timeout.
>
> Moreover, recent rework of tx_wait objects lifecycle handling made the
> driver be responsible for freeing the associated skbs, not the core
> ieee80211 stack. Lack of completion signaling would cause those objects
> being kept in driver internal tx_waits queue until rtw89_hci_reset()
> occurs, and then a double free would happen.
>
> Extract TX status handling into a separate function, like its
> rtw89_pci_tx_status() counterpart. Signal completion from there.
>
> Found by Linux Verification Center (linuxtesting.org).
>
> Fixes: 2135c28be6a8 ("wifi: rtw89: Add usb.{c,h}")
> Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
> ---
>
> New series iteration -> new nuances found.
>
> It seems the two previous patches from the series would not be too great
> in USB case because there is no completion signaling for tx_wait skbs
> there.
>
> I don't have this hardware so *the patch is compile tested only*. It'd
> be nice if someone gave it a run on top of two previous patches of the
> series, thanks!
>
I tested your first three patches with RTL8851BU for a few hours. It's
looking good, no explosion yet.
The USB side doesn't have real TX ACK status reporting yet. I only
learned recently how to do that. It looks like it will work about the
same as in rtw88.
> drivers/net/wireless/realtek/rtw89/usb.c | 36 +++++++++++++++---------
> 1 file changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw89/usb.c b/drivers/net/wireless/realtek/rtw89/usb.c
> index 6cf89aee252e..10fe19bd5166 100644
> --- a/drivers/net/wireless/realtek/rtw89/usb.c
> +++ b/drivers/net/wireless/realtek/rtw89/usb.c
> @@ -188,11 +188,32 @@ static u8 rtw89_usb_get_bulkout_id(u8 ch_dma)
> }
> }
>
> +static void rtw89_usb_tx_status(struct rtw89_dev *rtwdev, struct sk_buff *skb,
> + int status)
> +{
> + struct rtw89_tx_skb_data *skb_data = RTW89_TX_SKB_CB(skb);
> + struct ieee80211_tx_info *info;
> +
> + if (rtw89_core_tx_wait_complete(rtwdev, skb_data, status == 0))
> + return;
> +
> + info = IEEE80211_SKB_CB(skb);
> + ieee80211_tx_info_clear_status(info);
> +
> + if (status == 0) {
> + if (info->flags & IEEE80211_TX_CTL_NO_ACK)
> + info->flags |= IEEE80211_TX_STAT_NOACK_TRANSMITTED;
> + else
> + info->flags |= IEEE80211_TX_STAT_ACK;
> + }
> +
> + ieee80211_tx_status_irqsafe(rtwdev->hw, skb);
> +}
> +
> static void rtw89_usb_write_port_complete(struct urb *urb)
> {
> struct rtw89_usb_tx_ctrl_block *txcb = urb->context;
> struct rtw89_dev *rtwdev = txcb->rtwdev;
> - struct ieee80211_tx_info *info;
> struct rtw89_txwd_body *txdesc;
> struct sk_buff *skb;
> u32 txdesc_size;
> @@ -214,18 +235,7 @@ static void rtw89_usb_write_port_complete(struct urb *urb)
> txdesc_size += rtwdev->chip->txwd_info_size;
>
> skb_pull(skb, txdesc_size);
> -
> - info = IEEE80211_SKB_CB(skb);
> - ieee80211_tx_info_clear_status(info);
> -
> - if (urb->status == 0) {
> - if (info->flags & IEEE80211_TX_CTL_NO_ACK)
> - info->flags |= IEEE80211_TX_STAT_NOACK_TRANSMITTED;
> - else
> - info->flags |= IEEE80211_TX_STAT_ACK;
> - }
> -
> - ieee80211_tx_status_irqsafe(rtwdev->hw, skb);
> + rtw89_usb_tx_status(rtwdev, skb, urb->status);
> }
>
> switch (urb->status) {
On Fri, 29. Aug 22:57, Bitterblue Smith wrote:
> On 29/08/2025 00:11, Fedor Pchelkin wrote:
> > There is no completion signaling for tx_wait skbs on USB part. This means
> > rtw89_core_tx_kick_off_and_wait() always returns with a timeout.
> >
> > Moreover, recent rework of tx_wait objects lifecycle handling made the
> > driver be responsible for freeing the associated skbs, not the core
> > ieee80211 stack. Lack of completion signaling would cause those objects
> > being kept in driver internal tx_waits queue until rtw89_hci_reset()
> > occurs, and then a double free would happen.
> >
> > Extract TX status handling into a separate function, like its
> > rtw89_pci_tx_status() counterpart. Signal completion from there.
> >
> > Found by Linux Verification Center (linuxtesting.org).
> >
> > Fixes: 2135c28be6a8 ("wifi: rtw89: Add usb.{c,h}")
> > Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
> > ---
> >
> > New series iteration -> new nuances found.
> >
> > It seems the two previous patches from the series would not be too great
> > in USB case because there is no completion signaling for tx_wait skbs
> > there.
> >
> > I don't have this hardware so *the patch is compile tested only*. It'd
> > be nice if someone gave it a run on top of two previous patches of the
> > series, thanks!
> >
>
> I tested your first three patches with RTL8851BU for a few hours. It's
> looking good, no explosion yet.
Hello Bitterblue,
thank you! Just in case, rtw89_core_send_nullfunc() has to be called in
order to trigger all the tx_wait activity touched with the patches, please
make sure it's called during the tests - it should be done after scan
complete, 47a498b84f01 ("wifi: rtw89: TX nulldata 0 after scan complete").
There is one more issue we'd also need to solve: perform tx_wait
completion signaling inside rtw89_usb_ops_reset() (driver shutdown stage
should probably also be handled with the case). This'd require having an
ability to track TX URBs and kill them. I'm just throwing these thoughts
now, maybe you have some ideas. I'm still exploring the USB-part source
code and hopefully will have a chance to get hands on the USB chip soon.
>
> The USB side doesn't have real TX ACK status reporting yet. I only
> learned recently how to do that. It looks like it will work about the
> same as in rtw88.
Do you mean similar pattern already exists in rtw88? Could you give a
hint on how USB side TX ACK status reporting works there? At a quick
glance, I don't see how those TX URB complete callbacks differ from what
rtw89 has.
On 01/09/2025 20:45, Fedor Pchelkin wrote:
> On Fri, 29. Aug 22:57, Bitterblue Smith wrote:
>> On 29/08/2025 00:11, Fedor Pchelkin wrote:
>>> There is no completion signaling for tx_wait skbs on USB part. This means
>>> rtw89_core_tx_kick_off_and_wait() always returns with a timeout.
>>>
>>> Moreover, recent rework of tx_wait objects lifecycle handling made the
>>> driver be responsible for freeing the associated skbs, not the core
>>> ieee80211 stack. Lack of completion signaling would cause those objects
>>> being kept in driver internal tx_waits queue until rtw89_hci_reset()
>>> occurs, and then a double free would happen.
>>>
>>> Extract TX status handling into a separate function, like its
>>> rtw89_pci_tx_status() counterpart. Signal completion from there.
>>>
>>> Found by Linux Verification Center (linuxtesting.org).
>>>
>>> Fixes: 2135c28be6a8 ("wifi: rtw89: Add usb.{c,h}")
>>> Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
>>> ---
>>>
>>> New series iteration -> new nuances found.
>>>
>>> It seems the two previous patches from the series would not be too great
>>> in USB case because there is no completion signaling for tx_wait skbs
>>> there.
>>>
>>> I don't have this hardware so *the patch is compile tested only*. It'd
>>> be nice if someone gave it a run on top of two previous patches of the
>>> series, thanks!
>>>
>>
>> I tested your first three patches with RTL8851BU for a few hours. It's
>> looking good, no explosion yet.
>
> Hello Bitterblue,
>
> thank you! Just in case, rtw89_core_send_nullfunc() has to be called in
> order to trigger all the tx_wait activity touched with the patches, please
> make sure it's called during the tests - it should be done after scan
> complete, 47a498b84f01 ("wifi: rtw89: TX nulldata 0 after scan complete").
>
> There is one more issue we'd also need to solve: perform tx_wait
> completion signaling inside rtw89_usb_ops_reset() (driver shutdown stage
> should probably also be handled with the case). This'd require having an
> ability to track TX URBs and kill them. I'm just throwing these thoughts
> now, maybe you have some ideas. I'm still exploring the USB-part source
> code and hopefully will have a chance to get hands on the USB chip soon.
>
>>
>> The USB side doesn't have real TX ACK status reporting yet. I only
>> learned recently how to do that. It looks like it will work about the
>> same as in rtw88.
>
> Do you mean similar pattern already exists in rtw88? Could you give a
> hint on how USB side TX ACK status reporting works there? At a quick
> glance, I don't see how those TX URB complete callbacks differ from what
> rtw89 has.
Well, I assume we are talking about ACK status reporting. For example,
when mac80211 detects beacon loss it sends a null frame, or a probe
request (I'm not sure which is used when). It flags the frame with
IEEE80211_TX_CTL_REQ_TX_STATUS, which means the driver has to report
whether the AP sent ACK for the null frame/probe request or not. If
the AP doesn't reply for a while, the connection is considered lost.
A URB status of 0 only means that the URB was submitted successfully.
It doesn't mean the chip actually transmitted anything, and it doesn't
mean the chip received ACK from the AP.
In order to receive these ACK status reports rtw89 will have to set
a bit in the TX descriptor and place the skb in a queue to wait for
a message from the firmware. ieee80211_tx_status_irqsafe() can be
called when the firmware sends the message.
This is for USB. It seems to work differently for PCIE in rtw89
(rtw89_pci_release_rpp()). In rtw88 it's one mechanism for PCIE, USB,
and SDIO.
These are some functions to look at in rtw88:
rtw_tx_report_enable()
rtw_usb_write_port_tx_complete()
rtw_tx_report_enqueue()
rtw_usb_rx_handler()
rtw_fw_c2h_cmd_rx_irqsafe()
rtw_fw_c2h_cmd_handle() / rtw_fw_c2h_cmd_handle_ext()
rtw_tx_report_handle()
On Mon, 01. Sep 21:46, Bitterblue Smith wrote: > On 01/09/2025 20:45, Fedor Pchelkin wrote: > > On Fri, 29. Aug 22:57, Bitterblue Smith wrote: > >> The USB side doesn't have real TX ACK status reporting yet. I only > >> learned recently how to do that. It looks like it will work about the > >> same as in rtw88. > > > > Do you mean similar pattern already exists in rtw88? Could you give a > > hint on how USB side TX ACK status reporting works there? At a quick > > glance, I don't see how those TX URB complete callbacks differ from what > > rtw89 has. > > Well, I assume we are talking about ACK status reporting. For example, > when mac80211 detects beacon loss it sends a null frame, or a probe > request (I'm not sure which is used when). It flags the frame with > IEEE80211_TX_CTL_REQ_TX_STATUS, which means the driver has to report > whether the AP sent ACK for the null frame/probe request or not. If > the AP doesn't reply for a while, the connection is considered lost. > > A URB status of 0 only means that the URB was submitted successfully. > It doesn't mean the chip actually transmitted anything, and it doesn't > mean the chip received ACK from the AP. > > In order to receive these ACK status reports rtw89 will have to set > a bit in the TX descriptor and place the skb in a queue to wait for > a message from the firmware. ieee80211_tx_status_irqsafe() can be > called when the firmware sends the message. > > This is for USB. It seems to work differently for PCIE in rtw89 > (rtw89_pci_release_rpp()). In rtw88 it's one mechanism for PCIE, USB, > and SDIO. > > These are some functions to look at in rtw88: > > rtw_tx_report_enable() > rtw_usb_write_port_tx_complete() > rtw_tx_report_enqueue() > > rtw_usb_rx_handler() > rtw_fw_c2h_cmd_rx_irqsafe() > rtw_fw_c2h_cmd_handle() / rtw_fw_c2h_cmd_handle_ext() > rtw_tx_report_handle() Thanks for the detailed explanation of the above! Apologies for the delay. So I've got the RTL8851BU chip in the meantime. As rtw89-usb part is designated for not yet released v6.17 and is rather a thing on its own, I'd better address it in a separate series. With RTL8851BU there appears a possible firmware bug related to hardware scan channel list, already reported at [1]. Eventually after some time of hardware unresponsiveness it leads to the splat [2] and the device has to be replugged. So I had to apply your proposed workaround to avoid experiencing these failures. It happens with the first available firmware version, too (0.29.41.0 (e210be8a)). [1]: https://lore.kernel.org/linux-wireless/0abbda91-c5c2-4007-84c8-215679e652e1@gmail.com/ [2]: rtw89_8851bu 2-1:1.2: rtw89_hw_scan_offload failed ret -110 rtw89_8851bu 2-1:1.2: c2h reg timeout rtw89_8851bu 2-1:1.2: FW does not process h2c registers rtw89_8851bu 2-1:1.2: HW scan failed: -110 rtw89_8851bu 2-1:1.2: Update probe request failed rtw89_8851bu 2-1:1.2: Update probe request failed rtw89_8851bu 2-1:1.2: timed out to flush queues rtw89_8851bu 2-1:1.2: timed out to flush queues rtw89_8851bu 2-1:1.2: FW does not process h2c registers rtw89_8851bu 2-1:1.2: FW does not process h2c registers rtw89_8851bu 2-1:1.2: [ERR]FWDL path ready rtw89_8851bu 2-1:1.2: [ERR]fwdl 0x1E0 = 0x23 rtw89_8851bu 2-1:1.2: [ERR]fwdl 0x83F0 = 0x70000 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb8900a77 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb8900a55 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb8900a53 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb8900a6f rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb8900a73 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb8900a59 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb8900a67 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb8900a57 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb8900a67 rtw89_8851bu 2-1:1.2: [ERR]FWDL path ready rtw89_8851bu 2-1:1.2: [ERR]fwdl 0x1E0 = 0x23 rtw89_8851bu 2-1:1.2: [ERR]fwdl 0x83F0 = 0x70000 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb8900a75 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb8900a55 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb8900a69 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce5 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb8900a51 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0xb890cce3 rtw89_8851bu 2-1:1.2: [ERR]FWDL path ready rtw89_8851bu 2-1:1.2: [ERR]fwdl 0x1E0 = 0x23 rtw89_8851bu 2-1:1.2: usb read32 0x83f0 fail ret=-110 value=0x0 attempt=0 rtw89_8851bu 2-1:1.2: usb read32 0x83f0 fail ret=-110 value=0x0 attempt=1 rtw89_8851bu 2-1:1.2: usb read32 0x83f0 fail ret=-110 value=0x0 attempt=2 rtw89_8851bu 2-1:1.2: usb read32 0x83f0 fail ret=-110 value=0x0 attempt=3 rtw89_8851bu 2-1:1.2: usb read32 0x83f0 fail ret=-110 value=0x0 attempt=4 rtw89_8851bu 2-1:1.2: [ERR]fwdl 0x83F0 = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]H2C path ready rtw89_8851bu 2-1:1.2: [ERR]fwdl 0x1E0 = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fwdl 0x83F0 = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]H2C path ready rtw89_8851bu 2-1:1.2: [ERR]fwdl 0x1E0 = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fwdl 0x83F0 = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: [ERR]fw PC = 0x0 rtw89_8851bu 2-1:1.2: mac init fail, ret:-110 rtw89_8851bu 2-1:1.2: failed to leave idle state rtw89_8851bu 2-1:1.2: Update probe request failed rtw89_8851bu 2-1:1.2: rfkill hardware state changed to disable
© 2016 - 2025 Red Hat, Inc.