From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4BE3E2CC.9050804@domain.hid> Date: Fri, 07 May 2010 11:52:12 +0200 From: Wolfgang Grandegger MIME-Version: 1.0 References: <4BE1C695.10803@domain.hid> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] System freezes when CAN buffer overflows List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Steven Kauffmann Cc: xenomai@xenomai.org On 05/07/2010 11:34 AM, Steven Kauffmann wrote: > On Wed, May 5, 2010 at 9:27 PM, Wolfgang Grandegger wrote: >> On 05/03/2010 12:32 PM, Steven Kauffmann wrote: >>> Hi all, >>> >>> When I close my application a cleanup function is called. In this >>> function I first close the CAN listener thread that handles incoming >>> CAN messages. After that some other cleanup code is executed and at >>> the end I finally close the socket. If I close the application when >>> the CAN bus is idle, no problems occur. When the CAN bus is active, >>> I'm getting a CAN buffer overflow after the CAN listener thread is >>> closed which results in a system freeze. >> >> This is normal behaviour (not the freeze, though). Obviously you receive >> CAN messages at rather high rate and as long as the socket is open, the >> ISR tries to deliver it to the socket's RX buffer and when it gets full >> an error counter is increased and an error message is printed out if >> debugging is enabled. See: >> >> http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/rtcan_raw.c#122 >> >>> I can reproduce this problem with an easy example (see rtcanTest.c). >>> This program opens a socket but it does not start a CAN listener >>> thread. This results in a CAN buffer overflow when sending CAN >>> messages ( using rtcansend ) and a system freeze. Executing the >>> following command twice triggers the problem "rtcansend rtcan1 -l 100 >>> 001#00 00 00 00 00 00 00 00". >>> >>> Tested with the latest xenomai 2.4 branch + CAN peak pci card. >>> >>> Workaround for me is closing the socket immediately after the CAN >>> listener thread is closed. Can this be a system configuration problem >>> (config file attached) or a driver problem? >> >> The problem is due to the error messages at high rate. It should be >> rate-limited somehow or even be removed. Does Xenomai already have >> a rtdm_printk_ratelimted function? I will have a closer look >> a.s.a.p. Disabling debugging should also help. > > The problem (system freeze) also occurs when debugging > (CONFIG_XENO_OPT_DEBUG) is disabled. I'm speaking about CONFIG_XENO_DRIVERS_CAN_DEBUG! At a closer look I think rtdm_printk is mapped to printk, which may even force a switch to secondary mode. Wolfgang. > > Steven > >