All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Kroon <jacob.kroon@gmail.com>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
	linux-can@vger.kernel.org, wg@grandegger.com, mkl@pengutronix.de
Subject: Re: CM-ITC, pch_can/c_can_pci, sendto() returning ENOBUFS
Date: Tue, 30 Aug 2022 14:59:29 +0200	[thread overview]
Message-ID: <f8a95bfb-b1c2-cd41-1106-ca739c438fb9@gmail.com> (raw)
In-Reply-To: <556866e2-a3aa-9077-8db7-edc4ced69491@hartkopp.net>

Hi Oliver,

On 8/29/22 15:53, Oliver Hartkopp wrote:
> 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.
> 

Ok.

> 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?
> 

I have double checked that both endpoints of the network are terminated 
with 120Ohm resistors, and when I check CAN_H/CAN_L in an oscilloscope 
they look ok, and within the spec. voltage levels.

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

Yes I do have a CAN analyser from Microchip. I guess I can record all 
traffic with the analyzer, and compare it to what I see with "candump 
can0" on the host. Or do you have some other suggestion ?

Thanks for responding,
Jacob

  reply	other threads:[~2022-08-30 12:59 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
2022-08-30 12:59         ` Jacob Kroon [this message]
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=f8a95bfb-b1c2-cd41-1106-ca739c438fb9@gmail.com \
    --to=jacob.kroon@gmail.com \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=socketcan@hartkopp.net \
    --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.