All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Tollenaar <rwatollenaar@domain.hid>
To: Wolfgang Grandegger <wg@domain.hid>
Cc: Xenomai-help@domain.hid, EML users <ethercatmaster-users@domain.hid>
Subject: Re: [Xenomai-help] EML conflict with RTCAN? low_level_input	framebuilding failed.
Date: Mon, 13 Aug 2007 16:00:00 +0200	[thread overview]
Message-ID: <46C063E0.1010809@domain.hid> (raw)
In-Reply-To: <46C05690.2010108@domain.hid>

Hi,

All closing & shutting down has been perfected. There are no more errors 
on closing my application.

Yet the problem persists very explicitly. Rtcan and EML can run 
separately and never throw up any errors. As soon as they are used in 
combination then in 50% of the cases the framebuilding in EML gets 
messed up (as per the error message)

There is definitely something between the two that is not right.


>>>> RTnet:rtskb allocation from real-time cache failed.

Could I get some tips as to what I can do about this? I seem to get it 
even when I do not have rtcan activity running in my application and 
(because I am clueless) I would like to prevent this message which may 
signify the root of the problem.



Regards,

Roland.






>>> Hm, this is not supposed to happen.
>> Which of the two?
> 
> The RTCAN assertion. Well, in fact, it can happen when the device goes 
> bus-off or is stopped while a TX message is pending. The next message 
> after (re-)start will the trigger this message. This is a bug but it 
> should _not_ harm (either I remove the assertion or I reset properly the 
> value of dev->tx_socket).
> 
> The first one should be pretty clear. The rtskb pool seems to be exhausted.
> 
>>
>>> Can you show the output of /proc/rtcan/devices and 
>>> /proc/rtcan/sockets before and after the problem showed up.
>>
>> Below is an accumulation of what I think you are asking for. I am not 
>> convinced that the rtskb allocation failed message is serious, as you 
>> will see from the syslog and my comment above it only takes place when 
>> i close my application. Although I try to close all connections neatly 
>> certain threads still seem to be busy. See the errors I get on closing 
>> the application.
>>
>> App running with no problem:
>>
>> root@domain.hid:~# cat /proc/rtcan/sockets
>> fd Name___________ Filter ErrMask RX_Timeout_ns TX_Timeout_ns 
>> RX_BufFull TX_Lo
>>  2 rtcan2               1 0x00000      infinite      infinite 0     1
>>  0 rtcan2              -1 0x00000      infinite      infinite 0     1
>>
>> root@domain.hid:~# cat /proc/rtcan/devices
>> Name___________ _Baudrate State___ TX_Counter RX_Counter ____Errors
>> rtcan0          undefined stopped           0          0          0
>> rtcan1          undefined stopped           0          0          0
>> rtcan2            1000000 active     16321347   27633347    2367116
>>
>>
>> App running with messages failing
>>
>> root@domain.hid# cat /proc/rtcan/sockets
>> fd Name___________ Filter ErrMask RX_Timeout_ns TX_Timeout_ns 
>> RX_BufFull TX_Lo
>>  2 rtcan2               1 0x00000      infinite      infinite 0     1
>>  0 rtcan2              -1 0x00000      infinite      infinite 0     1
>>
>>
>> root@domain.hid# cat /proc/rtcan/devices
>> Name___________ _Baudrate State___ TX_Counter RX_Counter ____Errors
>> rtcan0          undefined stopped           0          0          0
>> rtcan1          undefined stopped           0          0          0
>> rtcan2            1000000 active     16850473   28691571    2367116
> 
> Oops, that much errors?
> 
>> cat /var/syslog shows that the error only seems to come up when the 
>> application closes.
>>
>> Only occurs on closing the application
>> Aug 13 13:01:28 (none) kernel: RTnet: rtskb allocation from real-time 
>> cache failed
>> Aug 13 13:02:14 (none) kernel: RTnet: rtskb allocation from real-time 
>> cache failed
>> Aug 13 14:02:34 (none) kernel: RTnet: rtskb allocation from real-time 
>> cache failed
>> Aug 13 14:03:36 (none) kernel: RTnet: rtskb allocation from real-time 
>> cache failed
>> Aug 13 14:18:39 (none) kernel: RTnet: rtskb allocation from real-time 
>> cache failed
>> Aug 13 14:19:33 (none) kernel: RTnet: rtskb allocation from real-time 
>> cache failed
>> Aug 13 14:19:58 (none) kernel: RTnet: rtskb allocation from real-time 
>> cache failed
>> Aug 13 14:21:27 (none) kernel: RTnet: rtskb allocation from real-time 
>> cache failed
>> Aug 13 14:22:10 (none) kernel: RTnet: rtskb allocation from real-time 
>> cache failed
>>
>>
>> When I close the application I get these errors
>>
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
>> rt_dev_recv: aborted because socket was closed
> 
> You should handle this error properly.
> 
>> rt_dev_ioctl: Bad file descriptor
>> Waiting for tasks to stop....low_level_output(): Cannot Send
>> low_level_output(): Cannot Send
>> low_level_output(): Cannot Send
>> low_level_output(): Cannot Send
>> low_level_output(): Cannot Send
>> low_level_output(): Cannot Send
>> low_level_output(): Cannot Send
>> low_level_output(): Cannot Send
>> low_level_output(): Cannot Send
>> low_level_output(): Cannot Send
>> low_level_txandrx: failed: MAX_TRIES_TX: Giving up
>> DLL::txandrx() Error
>> PD_Buffer: Error sending PD
>> txandrx failed:
>>
>>
>> Does this shed any light on the matter?
> 
> Hm, seems that your shutdown is not implemented properly.
> 
> Wolfgang.
> 


  parent reply	other threads:[~2007-08-13 14:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-13  9:45 [Xenomai-help] EML conflict with RTCAN? low_level_input framebuilding failed Roland Tollenaar
2007-08-13 11:41 ` Wolfgang Grandegger
2007-08-13 12:41   ` Roland Tollenaar
2007-08-13 13:03     ` Wolfgang Grandegger
2007-08-13 13:11       ` Roland Tollenaar
2007-08-13 14:00       ` Roland Tollenaar [this message]
2007-08-13 14:51         ` [Xenomai-help] [Ethercatmaster-users] " Jan Kiszka
2007-08-13 15:55           ` Roland Tollenaar
2007-08-13 16:57             ` Jan Kiszka
2007-08-13 17:40               ` Roland Tollenaar
2007-08-13 17:57                 ` Jan Kiszka
2007-08-13 18:17                   ` Roland Tollenaar
2007-08-13 18:30                     ` Jan Kiszka
2007-08-14 13:56           ` Roland Tollenaar
2007-08-14 14:47             ` Klaas Gadeyne
2007-08-14 18:03               ` Roland Tollenaar
2007-08-14 19:17                 ` Jan Kiszka
2007-08-15  6:11                   ` Roland Tollenaar
2007-08-15  8:24                     ` Jan Kiszka
2007-08-15  8:37                       ` Roland Tollenaar
2007-08-15  9:50                       ` Roland Tollenaar
2007-08-15 10:30                         ` Wolfgang Grandegger
2007-08-15 10:30                           ` Roland Tollenaar

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=46C063E0.1010809@domain.hid \
    --to=rwatollenaar@domain.hid \
    --cc=Xenomai-help@domain.hid \
    --cc=ethercatmaster-users@domain.hid \
    --cc=rolandtollenaar@domain.hid \
    --cc=wg@domain.hid \
    /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.