All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Jacob Kroon <jacob.kroon@gmail.com>,
	linux-can@vger.kernel.org, wg@grandegger.com, mkl@pengutronix.de
Subject: Re: CM-ITC, pch_can/c_can_pci, sendto() returning ENOBUFS
Date: Mon, 29 Aug 2022 15:53:03 +0200	[thread overview]
Message-ID: <556866e2-a3aa-9077-8db7-edc4ced69491@hartkopp.net> (raw)
In-Reply-To: <986401a8-5f5a-0705-82c4-4df339509e07@gmail.com>

Hi Jacob,

On 29.08.22 15:20, Jacob Kroon wrote:
> Hi Wolfgang and Marc,
> 
> On 8/29/22 11:14, Jacob Kroon wrote:
>> On 8/26/22 13:24, Jacob Kroon wrote:
>>> On 8/25/22 15:25, Jacob Kroon wrote:
>>>> Hi,
>>>>
>>>> I am using a CM-ITC board 
>>>> (https://www.compulab.com/products/computer-on-modules/cm-itc/) with 
>>>> an application that uses the CAN interface. After a while of 
>>>> successfully sending packets, sendto() starts returning ENOBUFS. I 
>>>> wait a whole second and try to send, several retries, but I get 
>>>> ENOBUFS every time. I'm using kernel 5.15.59, and I've tried both 
>>>> the pch_can and c_can_pci driver, but both show the same error.
>>>>
>>>> In the console I see several of:
>>>> can0: can_put_echo_skb: BUG! echo_skb 0 is occupied
>>>>
>>>> I've also tried to increase the txqueuelen to 1000, as suggested here
>>>>
>>>> https://stackoverflow.com/questions/40424433/write-no-buffer-space-available-socket-can-linux-can 
>>>>
>>>>
>>>> but I think that if I increase the queuelen the threads just block 
>>>> forever in sendto() (sockets are opened in blocking mode)
>>>>
>>>> If I bring down the interface with
>>>>
>>>> ifconfig can0 down
>>>> ifconfig can0 up
>>>>
>>>> the transmitting does get unblocked.
>>>>
>>>> Is there anything I can do to debug this further ? Any other ideas ?
>>>>
>>>
>>> First I get the print:
>>>
>>> can_put_echo_skb: BUG! echo_skb 0 is occupied!
>>>
>>> then netif_stop_queue() is called from here:
>>>
>>> https://github.com/torvalds/linux/blob/master/drivers/net/can/c_can/c_can_main.c#L469 
>>>
>>>
>>> and then there is no call to netif_start_queue(), so the bus hangs.
>>>
>>
>> Switching back to the pch_can driver. I'm guessing here but it would 
>> seem that the driver is not receiving the TX interrupt for 
>> 'PCH_TX_OBJ_END' that would wake up the netif queue, since with the 
>> changes below I can't reproduce the hang, although I'm still seeing a 
>> lot of "echo_skb <x> is occupied!":
>>
>>> diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
>>> index 964c8a09226a..75ad2272d9b2 100644
>>> --- a/drivers/net/can/pch_can.c
>>> +++ b/drivers/net/can/pch_can.c
>>> @@ -719,8 +720,7 @@ static void pch_can_tx_complete(struct net_device 
>>> *ndev, u32 int_stat)
>>>                           PCH_IF_MCONT_DLC);
>>>         stats->tx_bytes += dlc;
>>>         stats->tx_packets++;
>>> -       if (int_stat == PCH_TX_OBJ_END)
>>> -               netif_wake_queue(ndev);
>>> +       netif_wake_queue(ndev);
>>>  }
>>
> 
> Is there a recommended driver for the Intel EG20T PCH CAN controller ? 
> pch_can or c_can_pci ?

I'm very happy that you show up with this question!

AFAIK the PCH_CAN driver was contributed by some OKI developers on 
behalf of Intel to support their EG20T platform. This driver has not 
been worked on for years now.

Later the C_CAN driver got its PCI support which should have made the 
PCH_CAN driver obsolete as they are both using the C_CAN IP core.

So my suggestion would be to work with the well maintained c_can_pci and 
mark the pch_can obsolete in the Linux kernel.

IIRC Marc is very experienced with the C_CAN driver but he is still on 
vacation this week.

Regarding your problem:
"BUG! echo_skb 0 is occupied" should never show up but I wonder if you 
probably have another CAN specific problem with your setup.

Did you set up a CAN network with at least two CAN nodes, identical 
bitrate settings and 2x120 Ohms (== 60 Ohms) termination between CAN_L 
and CAN_H?

Do you have another CAN node which can be attached to the EG20T setup 
(e.g. some ECU or an USB CAN adapter)?

Best regards,
Oliver

  reply	other threads:[~2022-08-29 13:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-25 13:25 CM-ITC, pch_can/c_can_pci, sendto() returning ENOBUFS Jacob Kroon
2022-08-26 11:24 ` Jacob Kroon
2022-08-29  9:14   ` Jacob Kroon
2022-08-29 13:20     ` Jacob Kroon
2022-08-29 13:53       ` Oliver Hartkopp [this message]
2022-08-30 12:59         ` Jacob Kroon
2022-08-30 19:15           ` Oliver Hartkopp
2022-09-01  9:38             ` Jacob Kroon
2022-09-01 16:35               ` Oliver Hartkopp
2022-09-02 15:13                 ` Jacob Kroon
2022-09-02 16:39                   ` Jacob Kroon
2022-09-05 14:17                   ` Marc Kleine-Budde
2022-09-05 15:54               ` Marc Kleine-Budde
2022-09-16  4:14                 ` Jacob Kroon
2022-09-19 23:24                   ` Jacob Kroon
2022-09-20  1:23                     ` Vincent Mailhol
2022-09-20  5:08                       ` Jacob Kroon
2022-09-21  7:25                     ` dariobin
2022-09-21  7:47                       ` Marc Kleine-Budde
2022-09-21  8:26                         ` Jacob Kroon
2022-09-21  9:55                         ` Oliver Hartkopp
2022-09-21 10:32                           ` Marc Kleine-Budde
2022-09-21 10:39                             ` Oliver Hartkopp
2022-09-21 10:53                               ` Marc Kleine-Budde
2022-09-21 11:00                                 ` Oliver Hartkopp
2022-09-22  7:20                         ` dariobin
2022-09-23 11:36                   ` Marc Kleine-Budde
2022-09-23 17:55                     ` dariobin
2022-09-23 19:03                       ` Jacob Kroon
2022-09-23 19:21                         ` Jacob Kroon
2022-09-23 19:45                           ` dariobin
2022-09-23 20:27                             ` Jacob Kroon
2022-09-24  5:17                               ` Jacob Kroon
2022-09-28  8:25                                 ` Marc Kleine-Budde
2022-09-28  8:28                                   ` Jacob Kroon
2022-09-28  8:02                             ` Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=556866e2-a3aa-9077-8db7-edc4ced69491@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=jacob.kroon@gmail.com \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=wg@grandegger.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.