[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aa9e49d52421ac821062f6cdbccc77e81838dc03.camel@esd.eu>
Date: Mon, 18 Aug 2025 09:55:00 +0000
From: Stefan Mätje <stefan.maetje@....eu>
To: "mkl@...gutronix.de" <mkl@...gutronix.de>
CC: "mailhol@...nel.org" <mailhol@...nel.org>, "socketcan@...tkopp.net"
<socketcan@...tkopp.net>, "linux-can@...r.kernel.org"
<linux-can@...r.kernel.org>, socketcan <socketcan@....eu>, Frank Jungclaus
<frank.jungclaus@....eu>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"horms@...nel.org" <horms@...nel.org>, "olivier@...rie.be"
<olivier@...rie.be>
Subject: Re: [PATCH 4/6] can: esd_usb: Add watermark handling for TX jobs
Am Mittwoch, dem 13.08.2025 um 10:13 +0200 schrieb Marc Kleine-Budde:
> On 11.08.2025 23:06:09, Stefan Mätje wrote:
> > The driver tried to keep as much CAN frames as possible submitted to the
> > USB device (ESD_USB_MAX_TX_URBS). This has led to occasional "No free
> > context" error messages in high load situations like with
> > "cangen -g 0 -p 10 canX".
> >
> > This patch now calls netif_stop_queue() already if the number of active
> > jobs reaches ESD_USB_TX_URBS_HI_WM which is < ESD_USB_MAX_TX_URBS.
> > The netif_start_queue() is called in esd_usb_tx_done_msg() only if
> > the number of active jobs is <= ESD_USB_TX_URBS_LO_WM.
> >
> > This change eliminates the occasional error messages and significantly
> > reduces the number of calls to netif_start_queue() and
> > netif_stop_queue().
> >
> > The watermark limits have been chosen with the CAN-USB/Micro in mind to
> > not to compromise its TX throughput. This device is running on USB 1.1
> > only with its 1ms USB polling cycle where a ESD_USB_TX_URBS_LO_WM
> > value below 9 decreases the TX throughput.
> >
> > Signed-off-by: Stefan Mätje <stefan.maetje@....eu>
>
> Please add a Fixes tag.
I did not add a fixes tag because I had the impression that the code was working
fine with older kernels and the occasional messages began showing up only with
newer kernels after ~ 6.11. So I was not able to pinpoint the error to the patch
that exposed the problem.
But I retested the stuff now with older kernels. Somewhere between 5.4 and the 5.15
the problem starts. But on older kernels it can only be exposed transmitting zero
byte frames with "cangen -I i -g 0 -p 10 -L 0 canX" and additionally load the system
with other heavy tasks.
The code was unchanged since the initial implementation. I will then add a fixes
tag that denotes the initial implementation. That would be:
Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device")
Powered by blists - more mailing lists