[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f3fe05ea76794cd09774cd69e85623d8@realtek.com>
Date: Fri, 16 Jan 2026 03:11:42 +0000
From: Hayes Wang <hayeswang@...ltek.com>
To: lu lu <insyelu@...il.com>
CC: "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
"davem@...emloft.net"
<davem@...emloft.net>,
nic_swsd <nic_swsd@...ltek.com>, "tiwai@...e.de"
<tiwai@...e.de>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] net: usb: r8152: fix transmit queue timeout
lu lu <insyelu@...il.com>
> Sent: Friday, January 16, 2026 10:11 AM
[...]
> > netif_tx_lock(tp->netdev);
> >
> > - if (netif_queue_stopped(tp->netdev) &&
> > - skb_queue_len(&tp->tx_queue) < tp->tx_qlen)
> > + if (netif_queue_stopped(tp->netdev)) {
> > + if (skb_queue_len(&tp->tx_queue) < tp->tx_qlen)
> > netif_wake_queue(tp->netdev);
> > + else
> > + netif_trans_update(tp->netdev);
> > + }
> The queue was stopped because it exceeded the threshold. Attempting to
> refresh the time at this point is clearly too late.
Why would this be considered too late?
Based on RTL8152_TX_TIMEOUT, there are about 5 seconds to
wake the queue or update the timestamp before a TX timeout occurs.
I believe 5 seconds should be sufficient.
If there is no TX submission for 5 seconds after the driver stops the queue,
then something is already wrong.
Best Regards,
Hayes
Powered by blists - more mailing lists