All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Grandegger <wg@domain.hid>
To: "Urs.Eichholzer" <urs.eichholzer@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] FW: xeno_can: socket buffer overflow for fd=0
Date: Thu, 28 Feb 2008 14:16:43 +0100	[thread overview]
Message-ID: <47C6B43B.6080601@domain.hid> (raw)
In-Reply-To: <001501c87a09$08a9f6f0$2401a8c0@domain.hid>

Hi Urs,

Urs.Eichholzer wrote:
> Dear Xenomai Help
> 
>  
> 
> The write to CAN is fast and have no problem... this can  be performed
> fast and even in microsecond  resolution
> 
> The read to CAN is working... but not fast enough as we expect it should
> be reading the network... The Xenomai CAN  can  read the network
> transfers in seconds and  about 40 milliseconds but once the read is
> performed on a much faster rate... the Xenomai CAN is having errors
> already... The message is:
> xeno_can: socket buffer overflow for fd=0
> 
> Something like this would be printed on screen and the system scrolls
> with this message again and again.
> 
> Here are some of the remedies I tried but still this problem occurs:
> 
> 1.) Increase the buffer size for receive in the menuconfig from 1024 to
> 4096, same problem.
> 
> 2.) Link the CAN drivers statically to the OS, same problem.
> 
> 3.) Link the CAN drivers with dynamic loading of driver, same problem.
> 
> 4.) Create my own test program, same problem
> 
> 5.) Create my own xenomai task based on how a task should be made, same
> problem...
> 
> 
> I have investigated this and it is coming from the rtdm file of 
> Xenomai... when it detects  a low buffer resource, it will  trigger this
> error. But allocating more buffer space to 4096 will not solve this
> problem. On my investigation, the problem is buried deep in the Xenomai
> itself for the CAN driver and RTCAN socket. The file which is
> responsible for this is involved in the Xenomai RTCAN driver support.

If a RT application does not read the CAN messages from the RX socket
buffer fast enough, such socket overflows can happen. Check if your
application switches (accidentally) to secondary mode.

Do you use sockets just for sending messages? Then it helps to disable
the reception of messages by using sendto

http://www.rts.uni-hannover.de/xenomai/lxr/source/src/utils/can/rtcansend.c#085

or disable the receive filter:

http://www.rts.uni-hannover.de/xenomai/lxr/source/src/utils/can/rtcansend.c#252

It also helps to disable the CAN debugging because the printk's provoke
further buffer overflows. You can also see the socket buffer overflows
in /proc/rtcan/sockets.

Wolfgang.


      reply	other threads:[~2008-02-28 13:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-28 12:54 [Xenomai-help] FW: xeno_can: socket buffer overflow for fd=0 Urs.Eichholzer
2008-02-28 13:16 ` Wolfgang Grandegger [this message]

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=47C6B43B.6080601@domain.hid \
    --to=wg@domain.hid \
    --cc=urs.eichholzer@domain.hid \
    --cc=xenomai@xenomai.org \
    /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.