Re: [Xenomai-help] System freezes when CAN buffer overflows

[Jan Kiszka <jan.kiszka@domain.hid>]

Wolfgang Grandegger wrote:
> On 05/07/2010 11:34 AM, Steven Kauffmann wrote:
>> On Wed, May 5, 2010 at 9:27 PM, Wolfgang Grandegger <wg@domain.hid> 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.

Nope, this is kernel space. printk will write to a ring buffer that gets
flushed on next switch to the Linux domain.

Jan

PS: I'm open for a rtdm_printk_ratelimit for RTDM, but I think the
underlying service should be provided by Xenomai to eventually allow
reuse in the nucleus or some skin.

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux