Checking realtimeness of my component

Hi,

I'm running RTT/OCL master (from yesterday) on a 2.6.35.7-xenomai-2.5.5.2
system and wanted to test if my component does not cause context switches
between hard and soft realtime by using the rtos_enable_rt_warning() function
in my startHook. The component is running fine without this function.

When I start my component, the process is directly killed with the following
message:

Deployer [S]> LWR.start
CPU time limit exceeded

I checked the what this message means and
<http://www.xenomai.org/documentation/xenomai-2.0/pdf/Native-API-Tour.pdf>
tells me:
<quote>
Detecting unwanted switches to the secondary execution mode
Sometimes, switching to the secondary execution mode for a real­
time task so that it can
re­
enter the Linux kernel context may be an unwanted behaviour, likely due to invoking a
Linux system call involuntarily. In order to trap this situation, the native API allows real­
time tasks in user­
space to require the SIGXCPU signal (i.e. CPU time limit exceeded) to
be sent to them each time they switch from the primary to the secondary execution mode.
To use this feature, the application needs to install a handler for the SIGXCPU signal
(e.g. using sigaction(2)), then set the
T_WARNSW mode bit for the task to monitor, using
the
rt_task_set_mode() system call. If no SIGXCPU handler has been set, the whole
application is terminated upon receipt of this signal.
<quote>

So apparently no SIGXCPU handler has been set and this a bug? Or I do
something completely wrong and this is a call for help ;)

--Ruben

Checking realtimeness of my component

On Friday 25 February 2011 12:19:55 Ruben Smits wrote:
> Hi,
>
> I'm running RTT/OCL master (from yesterday) on a 2.6.35.7-xenomai-2.5.5.2
> system and wanted to test if my component does not cause context switches
> between hard and soft realtime by using the rtos_enable_rt_warning()
> function in my startHook. The component is running fine without this
> function.
>
> When I start my component, the process is directly killed with the
> following message:
>
> Deployer [S]> LWR.start
> CPU time limit exceeded
>
> I checked the what this message means and
> <http://www.xenomai.org/documentation/xenomai-2.0/pdf/Native-API-Tour.pdf>
> tells me:
> <quote>
> Detecting unwanted switches to the secondary execution mode
> Sometimes, switching to the secondary execution mode for a real­
> time task so that it can
> re­
> enter the Linux kernel context may be an unwanted behaviour, likely due to
> invoking a Linux system call involuntarily. In order to trap this
> situation, the native API allows real­ time tasks in user­
> space to require the SIGXCPU signal (i.e. CPU time limit exceeded) to
> be sent to them each time they switch from the primary to the secondary
> execution mode. To use this feature, the application needs to install a
> handler for the SIGXCPU signal (e.g. using sigaction(2)), then set the
> T_WARNSW mode bit for the task to monitor, using
> the
> rt_task_set_mode() system call. If no SIGXCPU handler has been set, the
> whole application is terminated upon receipt of this signal.
> <quote>
>
> So apparently no SIGXCPU handler has been set and this a bug? Or I do
> something completely wrong and this is a call for help ;)

We definately have a SIGXCPU handler setup. The fact that you get the sigxcpu
is at least a good sign. You should also see a log [Info] message with :
"Installing SIGXCPU handler." right after "Xenomai Periodic Timer runs in
preemptive 'one-shot' mode."

Maybe the readline magic is blocking some signals, you could try to compile
with editline (install libeditline-dev) and enable it with cmake. editline
does not use any signal trickery.

Peter

Ruben Smits's picture

Checking realtimeness of my component

On Friday 25 February 2011 12:29:19 Peter Soetens wrote:
> On Friday 25 February 2011 12:19:55 Ruben Smits wrote:
> > Hi,
> >
> > I'm running RTT/OCL master (from yesterday) on a
> > 2.6.35.7-xenomai-2.5.5.2
> > system and wanted to test if my component does not cause context
> > switches
> > between hard and soft realtime by using the rtos_enable_rt_warning()
> > function in my startHook. The component is running fine without this
> > function.
> >
> > When I start my component, the process is directly killed with the
> > following message:
> >
> > Deployer [S]> LWR.start
> > CPU time limit exceeded
> >
> > I checked the what this message means and
> > <http://www.xenomai.org/documentation/xenomai-2.0/pdf/Native-API-Tour.pd
> > f> tells me:
> > <quote>
> > Detecting unwanted switches to the secondary execution mode
> > Sometimes, switching to the secondary execution mode for a real­
> > time task so that it can
> > re­
> > enter the Linux kernel context may be an unwanted behaviour, likely due
> > to invoking a Linux system call involuntarily. In order to trap this
> > situation, the native API allows real­ time tasks in user­
> > space to require the SIGXCPU signal (i.e. CPU time limit exceeded) to
> > be sent to them each time they switch from the primary to the secondary
> > execution mode. To use this feature, the application needs to install a
> > handler for the SIGXCPU signal (e.g. using sigaction(2)), then set the
> > T_WARNSW mode bit for the task to monitor, using
> > the
> > rt_task_set_mode() system call. If no SIGXCPU handler has been set, the
> > whole application is terminated upon receipt of this signal.
> > <quote>
> >
> > So apparently no SIGXCPU handler has been set and this a bug? Or I do
> > something completely wrong and this is a call for help ;)
>
> We definately have a SIGXCPU handler setup. The fact that you get the
> sigxcpu is at least a good sign. You should also see a log [Info] message
> with : "Installing SIGXCPU handler." right after "Xenomai Periodic Timer
> runs in preemptive 'one-shot' mode."

Ok, I see this stuff.

> Maybe the readline magic is blocking some signals, you could try to compile
> with editline (install libeditline-dev) and enable it with cmake. editline
> does not use any signal trickery.

After installing libeditline-dev, the OCL cmake does not detect it. I'm on
Ubuntu 10.10

> Peter

--Ruben

Checking realtimeness of my component

On Friday 25 February 2011 12:45:54 Ruben Smits wrote:
> On Friday 25 February 2011 12:29:19 Peter Soetens wrote:
> > On Friday 25 February 2011 12:19:55 Ruben Smits wrote:
> > > Hi,
> > >
> > > I'm running RTT/OCL master (from yesterday) on a
> > > 2.6.35.7-xenomai-2.5.5.2
> > > system and wanted to test if my component does not cause context
> > > switches
> > > between hard and soft realtime by using the rtos_enable_rt_warning()
> > > function in my startHook. The component is running fine without this
> > > function.
> > >
> > > When I start my component, the process is directly killed with the
> > > following message:
> > >
> > > Deployer [S]> LWR.start
> > > CPU time limit exceeded
> > >
> > > I checked the what this message means and
> > > <http://www.xenomai.org/documentation/xenomai-2.0/pdf/Native-API-Tour.p
> > > d f> tells me:
> > > <quote>
> > > Detecting unwanted switches to the secondary execution mode
> > > Sometimes, switching to the secondary execution mode for a real­
> > > time task so that it can
> > > re­
> > > enter the Linux kernel context may be an unwanted behaviour, likely due
> > > to invoking a Linux system call involuntarily. In order to trap this
> > > situation, the native API allows real­ time tasks in user­
> > > space to require the SIGXCPU signal (i.e. CPU time limit exceeded) to
> > > be sent to them each time they switch from the primary to the secondary
> > > execution mode. To use this feature, the application needs to install a
> > > handler for the SIGXCPU signal (e.g. using sigaction(2)), then set the
> > > T_WARNSW mode bit for the task to monitor, using
> > > the
> > > rt_task_set_mode() system call. If no SIGXCPU handler has been set, the
> > > whole application is terminated upon receipt of this signal.
> > > <quote>
> > >
> > > So apparently no SIGXCPU handler has been set and this a bug? Or I do
> > > something completely wrong and this is a call for help ;)
> >
> > We definately have a SIGXCPU handler setup. The fact that you get the
> > sigxcpu is at least a good sign. You should also see a log [Info] message
> > with : "Installing SIGXCPU handler." right after "Xenomai Periodic Timer
> > runs in preemptive 'one-shot' mode."
>
> Ok, I see this stuff.
>
> > Maybe the readline magic is blocking some signals, you could try to
> > compile with editline (install libeditline-dev) and enable it with
> > cmake. editline does not use any signal trickery.
>
> After installing libeditline-dev, the OCL cmake does not detect it. I'm on
> Ubuntu 10.10

So you don't see
-- Looking for curses implementation - found libncurses
-- Looking for readline/readline.h - found
-- Looking for editline/readline.h - found

?

On my system, I have:
$ dpkg -L libeditline-dev
/.
/usr
/usr/lib
/usr/lib/libeditline.a
/usr/lib/libeditline.la
/usr/include
/usr/include/editline.h
/usr/share
/usr/share/doc
/usr/share/doc/libeditline-dev
/usr/share/doc/libeditline-dev/README
/usr/share/doc/libeditline-dev/README.Debian
/usr/share/doc/libeditline-dev/copyright
/usr/share/doc/libeditline-dev/changelog.Debian.gz
/usr/share/man
/usr/share/man/man3
/usr/share/man/man3/editline.3.gz
/usr/lib/libeditline.so

Peter

Ruben Smits's picture

Checking realtimeness of my component

On Friday 25 February 2011 13:10:43 Peter Soetens wrote:
> On Friday 25 February 2011 12:45:54 Ruben Smits wrote:
> > On Friday 25 February 2011 12:29:19 Peter Soetens wrote:
> > > On Friday 25 February 2011 12:19:55 Ruben Smits wrote:
> > > > Hi,
> > > >
> > > > I'm running RTT/OCL master (from yesterday) on a
> > > > 2.6.35.7-xenomai-2.5.5.2
> > > > system and wanted to test if my component does not cause context
> > > > switches
> > > > between hard and soft realtime by using the
> > > > rtos_enable_rt_warning()
> > > > function in my startHook. The component is running fine without
> > > > this
> > > > function.
> > > >
> > > > When I start my component, the process is directly killed with
> > > > the
> > > > following message:
> > > >
> > > > Deployer [S]> LWR.start
> > > > CPU time limit exceeded
> > > >
> > > > I checked the what this message means and
> > > > <http://www.xenomai.org/documentation/xenomai-2.0/pdf/Native-API
> > > > -Tour.p d f> tells me:
> > > > <quote>
> > > > Detecting unwanted switches to the secondary execution mode
> > > > Sometimes, switching to the secondary execution mode for a real­
> > > > time task so that it can
> > > > re­
> > > > enter the Linux kernel context may be an unwanted behaviour,
> > > > likely due to invoking a Linux system call involuntarily. In
> > > > order to trap this situation, the native API allows real­ time
> > > > tasks in user­
> > > > space to require the SIGXCPU signal (i.e. CPU time limit
> > > > exceeded) to
> > > > be sent to them each time they switch from the primary to the
> > > > secondary execution mode. To use this feature, the application
> > > > needs to install a handler for the SIGXCPU signal (e.g. using
> > > > sigaction(2)), then set the T_WARNSW mode bit for the task to
> > > > monitor, using
> > > > the
> > > > rt_task_set_mode() system call. If no SIGXCPU handler has been
> > > > set, the whole application is terminated upon receipt of this
> > > > signal. <quote>
> > > >
> > > > So apparently no SIGXCPU handler has been set and this a bug? Or
> > > > I do
> > > > something completely wrong and this is a call for help ;)
> > >
> > > We definately have a SIGXCPU handler setup. The fact that you get
> > > the
> > > sigxcpu is at least a good sign. You should also see a log [Info]
> > > message with : "Installing SIGXCPU handler." right after "Xenomai
> > > Periodic Timer runs in preemptive 'one-shot' mode."
> >
> > Ok, I see this stuff.
> >
> > > Maybe the readline magic is blocking some signals, you could try to
> > > compile with editline (install libeditline-dev) and enable it with
> > > cmake. editline does not use any signal trickery.
> >
> > After installing libeditline-dev, the OCL cmake does not detect it. I'm
> > on Ubuntu 10.10
>
> So you don't see
> -- Looking for curses implementation - found libncurses
> -- Looking for readline/readline.h - found
> -- Looking for editline/readline.h - found

Shouldn't this message be editline.h?

> ?
>
> On my system, I have:
> $ dpkg -L libeditline-dev
> /.
> /usr
> /usr/lib
> /usr/lib/libeditline.a
> /usr/lib/libeditline.la
> /usr/include
> /usr/include/editline.h
> /usr/share
> /usr/share/doc
> /usr/share/doc/libeditline-dev
> /usr/share/doc/libeditline-dev/README
> /usr/share/doc/libeditline-dev/README.Debian
> /usr/share/doc/libeditline-dev/copyright
> /usr/share/doc/libeditline-dev/changelog.Debian.gz
> /usr/share/man
> /usr/share/man/man3
> /usr/share/man/man3/editline.3.gz
> /usr/lib/libeditline.so
>

I have the same thing.
Shouldn't the following line in config/check_depend:
FIND_LIBRARY(EDITLINE_LIBRARY edit )
be changed into
FIND_LIBRARY(EDITLINE_LIBRARY editline )
?

How can I enable editline if both readline and editline are found?

> Peter

--Ruben

Ruben Smits's picture

Checking realtimeness of my component

On Friday 25 February 2011 13:16:20 Ruben Smits wrote:
> On Friday 25 February 2011 13:10:43 Peter Soetens wrote:
> > On Friday 25 February 2011 12:45:54 Ruben Smits wrote:
> > > On Friday 25 February 2011 12:29:19 Peter Soetens wrote:
> > > > On Friday 25 February 2011 12:19:55 Ruben Smits wrote:
> > > > > Hi,
> > > > >
> > > > > I'm running RTT/OCL master (from yesterday) on a
> > > > > 2.6.35.7-xenomai-2.5.5.2
> > > > > system and wanted to test if my component does not cause
> > > > > context
> > > > > switches
> > > > > between hard and soft realtime by using the
> > > > > rtos_enable_rt_warning()
> > > > > function in my startHook. The component is running fine
> > > > > without
> > > > > this
> > > > > function.
> > > > >
> > > > > When I start my component, the process is directly killed
> > > > > with
> > > > > the
> > > > > following message:
> > > > >
> > > > > Deployer [S]> LWR.start
> > > > > CPU time limit exceeded
> > > > >
> > > > > I checked the what this message means and
> > > > > <http://www.xenomai.org/documentation/xenomai-2.0/pdf/Native
> > > > > -API
> > > > > -Tour.p d f> tells me:
> > > > > <quote>
> > > > > Detecting unwanted switches to the secondary execution mode
> > > > > Sometimes, switching to the secondary execution mode for a
> > > > > real­
> > > > > time task so that it can
> > > > > re­
> > > > > enter the Linux kernel context may be an unwanted behaviour,
> > > > > likely due to invoking a Linux system call involuntarily. In
> > > > > order to trap this situation, the native API allows real­
> > > > > time
> > > > > tasks in user­
> > > > > space to require the SIGXCPU signal (i.e. CPU time limit
> > > > > exceeded) to
> > > > > be sent to them each time they switch from the primary to
> > > > > the
> > > > > secondary execution mode. To use this feature, the
> > > > > application
> > > > > needs to install a handler for the SIGXCPU signal (e.g.
> > > > > using
> > > > > sigaction(2)), then set the T_WARNSW mode bit for the task
> > > > > to
> > > > > monitor, using
> > > > > the
> > > > > rt_task_set_mode() system call. If no SIGXCPU handler has
> > > > > been
> > > > > set, the whole application is terminated upon receipt of
> > > > > this
> > > > > signal. <quote>
> > > > >
> > > > > So apparently no SIGXCPU handler has been set and this a
> > > > > bug? Or
> > > > > I do
> > > > > something completely wrong and this is a call for help ;)
> > > >
> > > > We definately have a SIGXCPU handler setup. The fact that you
> > > > get
> > > > the
> > > > sigxcpu is at least a good sign. You should also see a log
> > > > [Info]
> > > > message with : "Installing SIGXCPU handler." right after
> > > > "Xenomai
> > > > Periodic Timer runs in preemptive 'one-shot' mode."
> > >
> > > Ok, I see this stuff.
> > >
> > > > Maybe the readline magic is blocking some signals, you could try
> > > > to
> > > > compile with editline (install libeditline-dev) and enable it
> > > > with
> > > > cmake. editline does not use any signal trickery.
> > >
> > > After installing libeditline-dev, the OCL cmake does not detect it.
> > > I'm
> > > on Ubuntu 10.10
> >
> > So you don't see
> > -- Looking for curses implementation - found libncurses
> > -- Looking for readline/readline.h - found
> > -- Looking for editline/readline.h - found
>
> Shouldn't this message be editline.h?
>
> > ?
> >
> > On my system, I have:
> > $ dpkg -L libeditline-dev
> > /.
> > /usr
> > /usr/lib
> > /usr/lib/libeditline.a
> > /usr/lib/libeditline.la
> > /usr/include
> > /usr/include/editline.h
> > /usr/share
> > /usr/share/doc
> > /usr/share/doc/libeditline-dev
> > /usr/share/doc/libeditline-dev/README
> > /usr/share/doc/libeditline-dev/README.Debian
> > /usr/share/doc/libeditline-dev/copyright
> > /usr/share/doc/libeditline-dev/changelog.Debian.gz
> > /usr/share/man
> > /usr/share/man/man3
> > /usr/share/man/man3/editline.3.gz
> > /usr/lib/libeditline.so
>
> I have the same thing.
> Shouldn't the following line in config/check_depend:
> FIND_LIBRARY(EDITLINE_LIBRARY edit )
> be changed into
> FIND_LIBRARY(EDITLINE_LIBRARY editline )
> ?
>
> How can I enable editline if both readline and editline are found?

I tried with the no_gpl option but then I get the following error:

CMake Error at taskbrowser/CMakeLists.txt:71 (target_link_libraries):
Cannot specify link libraries for target "orocos-taskbrowser" which is not
built by this project.

> > Peter

-- Ruben
> --Ruben

Ruben Smits's picture

Checking realtimeness of my component

On Friday 25 February 2011 13:18:18 Ruben Smits wrote:
> On Friday 25 February 2011 13:16:20 Ruben Smits wrote:
> > On Friday 25 February 2011 13:10:43 Peter Soetens wrote:
> > > On Friday 25 February 2011 12:45:54 Ruben Smits wrote:
> > > > On Friday 25 February 2011 12:29:19 Peter Soetens wrote:
> > > > > On Friday 25 February 2011 12:19:55 Ruben Smits wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I'm running RTT/OCL master (from yesterday) on a
> > > > > > 2.6.35.7-xenomai-2.5.5.2
> > > > > > system and wanted to test if my component does not cause
> > > > > > context
> > > > > > switches
> > > > > > between hard and soft realtime by using the
> > > > > > rtos_enable_rt_warning()
> > > > > > function in my startHook. The component is running fine
> > > > > > without
> > > > > > this
> > > > > > function.
> > > > > >
> > > > > > When I start my component, the process is directly
> > > > > > killed
> > > > > > with
> > > > > > the
> > > > > > following message:
> > > > > >
> > > > > > Deployer [S]> LWR.start
> > > > > > CPU time limit exceeded
> > > > > >
> > > > > > I checked the what this message means and
> > > > > > <http://www.xenomai.org/documentation/xenomai-2.0/pdf/Na
> > > > > > tive
> > > > > > -API
> > > > > > -Tour.p d f> tells me:
> > > > > > <quote>
> > > > > > Detecting unwanted switches to the secondary execution
> > > > > > mode
> > > > > > Sometimes, switching to the secondary execution mode for
> > > > > > a
> > > > > > real­
> > > > > > time task so that it can
> > > > > > re­
> > > > > > enter the Linux kernel context may be an unwanted
> > > > > > behaviour,
> > > > > > likely due to invoking a Linux system call
> > > > > > involuntarily. In
> > > > > > order to trap this situation, the native API allows
> > > > > > real­
> > > > > > time
> > > > > > tasks in user­
> > > > > > space to require the SIGXCPU signal (i.e. CPU time limit
> > > > > > exceeded) to
> > > > > > be sent to them each time they switch from the primary
> > > > > > to
> > > > > > the
> > > > > > secondary execution mode. To use this feature, the
> > > > > > application
> > > > > > needs to install a handler for the SIGXCPU signal (e.g.
> > > > > > using
> > > > > > sigaction(2)), then set the T_WARNSW mode bit for the
> > > > > > task
> > > > > > to
> > > > > > monitor, using
> > > > > > the
> > > > > > rt_task_set_mode() system call. If no SIGXCPU handler
> > > > > > has
> > > > > > been
> > > > > > set, the whole application is terminated upon receipt of
> > > > > > this
> > > > > > signal. <quote>
> > > > > >
> > > > > > So apparently no SIGXCPU handler has been set and this a
> > > > > > bug? Or
> > > > > > I do
> > > > > > something completely wrong and this is a call for help
> > > > > > ;)
> > > > >
> > > > > We definately have a SIGXCPU handler setup. The fact that
> > > > > you
> > > > > get
> > > > > the
> > > > > sigxcpu is at least a good sign. You should also see a log
> > > > > [Info]
> > > > > message with : "Installing SIGXCPU handler." right after
> > > > > "Xenomai
> > > > > Periodic Timer runs in preemptive 'one-shot' mode."
> > > >
> > > > Ok, I see this stuff.
> > > >
> > > > > Maybe the readline magic is blocking some signals, you could
> > > > > try
> > > > > to
> > > > > compile with editline (install libeditline-dev) and enable
> > > > > it
> > > > > with
> > > > > cmake. editline does not use any signal trickery.
> > > >
> > > > After installing libeditline-dev, the OCL cmake does not detect
> > > > it.
> > > > I'm
> > > > on Ubuntu 10.10
> > >
> > > So you don't see
> > > -- Looking for curses implementation - found libncurses
> > > -- Looking for readline/readline.h - found
> > > -- Looking for editline/readline.h - found
> >
> > Shouldn't this message be editline.h?
> >
> > > ?
> > >
> > > On my system, I have:
> > > $ dpkg -L libeditline-dev
> > > /.
> > > /usr
> > > /usr/lib
> > > /usr/lib/libeditline.a
> > > /usr/lib/libeditline.la
> > > /usr/include
> > > /usr/include/editline.h
> > > /usr/share
> > > /usr/share/doc
> > > /usr/share/doc/libeditline-dev
> > > /usr/share/doc/libeditline-dev/README
> > > /usr/share/doc/libeditline-dev/README.Debian
> > > /usr/share/doc/libeditline-dev/copyright
> > > /usr/share/doc/libeditline-dev/changelog.Debian.gz
> > > /usr/share/man
> > > /usr/share/man/man3
> > > /usr/share/man/man3/editline.3.gz
> > > /usr/lib/libeditline.so
> >
> > I have the same thing.
> > Shouldn't the following line in config/check_depend:
> > FIND_LIBRARY(EDITLINE_LIBRARY edit )
> > be changed into
> > FIND_LIBRARY(EDITLINE_LIBRARY editline )
> > ?
> >
> > How can I enable editline if both readline and editline are found?
>
> I tried with the no_gpl option but then I get the following error:
>
> CMake Error at taskbrowser/CMakeLists.txt:71 (target_link_libraries):
> Cannot specify link libraries for target "orocos-taskbrowser" which is
> not built by this project.

I've fixed the taskbrowser/CMakeLists.txt for this but then I get into other
trouble:

/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp:101: fatal
error: editline/readline.h: No such file or directory

/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp:101: fatal
error: editline/history.h: No such file or directory

Since these headers were not available in the libeditline-dev package I
changing these into editline.h, but that does not help because then I get the
following errors:

/usr/include/editline.h: In member function ‘char*
OCL::TaskBrowser::rl_gets()’:
/usr/include/editline.h:1: error: too many arguments to function ‘char*
readline()’
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp:219: error: at
this point in file
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp:226: error:
‘where_history’ was not declared in this scope
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp:226: error:
‘history_get’ was not declared in this scope
/usr/include/editline.h:2: error: too many arguments to function ‘void
add_history()’
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp:229: error: at
this point in file
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp: In static
member function ‘static void OCL::TaskBrowser::find_completes()’:
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp:273: error:
‘rl_line_buffer’ was not declared in this scope
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp:273: error:
‘rl_point’ was not declared in this scope
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp: In static
member function ‘static char** OCL::TaskBrowser::orocos_hmi_completion(const
char*, int, int)’:
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp:635: error:
‘rl_completion_matches’ was not declared in this scope
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp: In
constructor ‘OCL::TaskBrowser::TaskBrowser(RTT::TaskContext*)’:
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp:656: error:
‘rl_completion_append_character’ was not declared in this scope
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp:657: error:
‘rl_attempted_completion_function’ was not declared in this scope
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp:659: error:
‘read_history’ was not declared in this scope
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp: In destructor
‘virtual OCL::TaskBrowser::~TaskBrowser()’:
/home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/taskbrowser/TaskBrowser.cpp:681: error:
‘write_history’ was not declared in this scope
make[3]: *** [taskbrowser/CMakeFiles/orocos-ocl-taskbrowser.dir/TaskBrowser.o]
Error 1

Am I missing something here??

--Ruben
> -- Ruben
>
> > --Ruben
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

Ruben Smits's picture

Checking realtimeness of my component

On Friday 25 February 2011 13:32:06 Ruben Smits wrote:
> On Friday 25 February 2011 13:18:18 Ruben Smits wrote:
> > On Friday 25 February 2011 13:16:20 Ruben Smits wrote:
> > > On Friday 25 February 2011 13:10:43 Peter Soetens wrote:
> > > > On Friday 25 February 2011 12:45:54 Ruben Smits wrote:
> > > > > On Friday 25 February 2011 12:29:19 Peter Soetens wrote:
> > > > > > On Friday 25 February 2011 12:19:55 Ruben Smits wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'm running RTT/OCL master (from yesterday) on a
> > > > > > > 2.6.35.7-xenomai-2.5.5.2
> > > > > > > system and wanted to test if my component does not
> > > > > > > cause
> > > > > > > context
> > > > > > > switches
> > > > > > > between hard and soft realtime by using the
> > > > > > > rtos_enable_rt_warning()
> > > > > > > function in my startHook. The component is running
> > > > > > > fine
> > > > > > > without
> > > > > > > this
> > > > > > > function.
> > > > > > >
> > > > > > > When I start my component, the process is directly
> > > > > > > killed
> > > > > > > with
> > > > > > > the
> > > > > > > following message:
> > > > > > >
> > > > > > > Deployer [S]> LWR.start
> > > > > > > CPU time limit exceeded
> > > > > > >
> > > > > > > I checked the what this message means and
> > > > > > > <http://www.xenomai.org/documentation/xenomai-2.0/pd
> > > > > > > f/Na
> > > > > > > tive
> > > > > > > -API
> > > > > > > -Tour.p d f> tells me:
> > > > > > > <quote>
> > > > > > > Detecting unwanted switches to the secondary
> > > > > > > execution
> > > > > > > mode
> > > > > > > Sometimes, switching to the secondary execution mode
> > > > > > > for
> > > > > > > a
> > > > > > > real­
> > > > > > > time task so that it can
> > > > > > > re­
> > > > > > > enter the Linux kernel context may be an unwanted
> > > > > > > behaviour,
> > > > > > > likely due to invoking a Linux system call
> > > > > > > involuntarily. In
> > > > > > > order to trap this situation, the native API allows
> > > > > > > real­
> > > > > > > time
> > > > > > > tasks in user­
> > > > > > > space to require the SIGXCPU signal (i.e. CPU time
> > > > > > > limit
> > > > > > > exceeded) to
> > > > > > > be sent to them each time they switch from the
> > > > > > > primary
> > > > > > > to
> > > > > > > the
> > > > > > > secondary execution mode. To use this feature, the
> > > > > > > application
> > > > > > > needs to install a handler for the SIGXCPU signal
> > > > > > > (e.g.
> > > > > > > using
> > > > > > > sigaction(2)), then set the T_WARNSW mode bit for
> > > > > > > the
> > > > > > > task
> > > > > > > to
> > > > > > > monitor, using
> > > > > > > the
> > > > > > > rt_task_set_mode() system call. If no SIGXCPU
> > > > > > > handler
> > > > > > > has
> > > > > > > been
> > > > > > > set, the whole application is terminated upon
> > > > > > > receipt of
> > > > > > > this
> > > > > > > signal. <quote>
> > > > > > >
> > > > > > > So apparently no SIGXCPU handler has been set and
> > > > > > > this a
> > > > > > > bug? Or
> > > > > > > I do
> > > > > > > something completely wrong and this is a call for
> > > > > > > help
> > > > > > > ;)
> > > > > >
> > > > > > We definately have a SIGXCPU handler setup. The fact
> > > > > > that
> > > > > > you
> > > > > > get
> > > > > > the
> > > > > > sigxcpu is at least a good sign. You should also see a
> > > > > > log
> > > > > > [Info]
> > > > > > message with : "Installing SIGXCPU handler." right after
> > > > > > "Xenomai
> > > > > > Periodic Timer runs in preemptive 'one-shot' mode."
> > > > >
> > > > > Ok, I see this stuff.
> > > > >
> > > > > > Maybe the readline magic is blocking some signals, you
> > > > > > could
> > > > > > try
> > > > > > to
> > > > > > compile with editline (install libeditline-dev) and

This should have been install libedit-dev.

It's working now, I'll send a patch for the CMakeLists.txt fix

-- Ruben
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

Ruben Smits's picture

Checking realtimeness of my component

On Friday 25 February 2011 13:35:37 Ruben Smits wrote:
> On Friday 25 February 2011 13:32:06 Ruben Smits wrote:
> > On Friday 25 February 2011 13:18:18 Ruben Smits wrote:
> > > On Friday 25 February 2011 13:16:20 Ruben Smits wrote:
> > > > On Friday 25 February 2011 13:10:43 Peter Soetens wrote:
> > > > > On Friday 25 February 2011 12:45:54 Ruben Smits wrote:
> > > > > > On Friday 25 February 2011 12:29:19 Peter Soetens wrote:
> > > > > > > On Friday 25 February 2011 12:19:55 Ruben Smits wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I'm running RTT/OCL master (from yesterday) on a
> > > > > > > > 2.6.35.7-xenomai-2.5.5.2
> > > > > > > > system and wanted to test if my component does
> > > > > > > > not
> > > > > > > > cause
> > > > > > > > context
> > > > > > > > switches
> > > > > > > > between hard and soft realtime by using the
> > > > > > > > rtos_enable_rt_warning()
> > > > > > > > function in my startHook. The component is
> > > > > > > > running
> > > > > > > > fine
> > > > > > > > without
> > > > > > > > this
> > > > > > > > function.
> > > > > > > >
> > > > > > > > When I start my component, the process is
> > > > > > > > directly
> > > > > > > > killed
> > > > > > > > with
> > > > > > > > the
> > > > > > > > following message:
> > > > > > > >
> > > > > > > > Deployer [S]> LWR.start
> > > > > > > > CPU time limit exceeded
> > > > > > > >
> > > > > > > > I checked the what this message means and
> > > > > > > > <http://www.xenomai.org/documentation/xenomai-2.
> > > > > > > > 0/pd
> > > > > > > > f/Na
> > > > > > > > tive
> > > > > > > > -API
> > > > > > > > -Tour.p d f> tells me:
> > > > > > > > <quote>
> > > > > > > > Detecting unwanted switches to the secondary
> > > > > > > > execution
> > > > > > > > mode
> > > > > > > > Sometimes, switching to the secondary execution
> > > > > > > > mode
> > > > > > > > for
> > > > > > > > a
> > > > > > > > real­
> > > > > > > > time task so that it can
> > > > > > > > re­
> > > > > > > > enter the Linux kernel context may be an
> > > > > > > > unwanted
> > > > > > > > behaviour,
> > > > > > > > likely due to invoking a Linux system call
> > > > > > > > involuntarily. In
> > > > > > > > order to trap this situation, the native API
> > > > > > > > allows
> > > > > > > > real­
> > > > > > > > time
> > > > > > > > tasks in user­
> > > > > > > > space to require the SIGXCPU signal (i.e. CPU
> > > > > > > > time
> > > > > > > > limit
> > > > > > > > exceeded) to
> > > > > > > > be sent to them each time they switch from the
> > > > > > > > primary
> > > > > > > > to
> > > > > > > > the
> > > > > > > > secondary execution mode. To use this feature,
> > > > > > > > the
> > > > > > > > application
> > > > > > > > needs to install a handler for the SIGXCPU
> > > > > > > > signal
> > > > > > > > (e.g.
> > > > > > > > using
> > > > > > > > sigaction(2)), then set the T_WARNSW mode bit
> > > > > > > > for
> > > > > > > > the
> > > > > > > > task
> > > > > > > > to
> > > > > > > > monitor, using
> > > > > > > > the
> > > > > > > > rt_task_set_mode() system call. If no SIGXCPU
> > > > > > > > handler
> > > > > > > > has
> > > > > > > > been
> > > > > > > > set, the whole application is terminated upon
> > > > > > > > receipt of
> > > > > > > > this
> > > > > > > > signal. <quote>
> > > > > > > >
> > > > > > > > So apparently no SIGXCPU handler has been set
> > > > > > > > and
> > > > > > > > this a
> > > > > > > > bug? Or
> > > > > > > > I do
> > > > > > > > something completely wrong and this is a call
> > > > > > > > for
> > > > > > > > help
> > > > > > > > ;)
> > > > > > >
> > > > > > > We definately have a SIGXCPU handler setup. The fact
> > > > > > > that
> > > > > > > you
> > > > > > > get
> > > > > > > the
> > > > > > > sigxcpu is at least a good sign. You should also see
> > > > > > > a
> > > > > > > log
> > > > > > > [Info]
> > > > > > > message with : "Installing SIGXCPU handler." right
> > > > > > > after
> > > > > > > "Xenomai
> > > > > > > Periodic Timer runs in preemptive 'one-shot' mode."
> > > > > >
> > > > > > Ok, I see this stuff.
> > > > > >
> > > > > > > Maybe the readline magic is blocking some signals,
> > > > > > > you
> > > > > > > could
> > > > > > > try
> > > > > > > to
> > > > > > > compile with editline (install libeditline-dev) and
>
> This should have been install libedit-dev.
>
> It's working now, I'll send a patch for the CMakeLists.txt fix

I had to set NO_GPL to ONN, to make sure that libreadline does not get linked
to the taskbrowser.

But it is still not working, I've made sure that the deployer is not linked
with readline:

ldd /home/rsmits/ros/kul-ros-pkg/stacks/orocos_toolchain_ros/ocl/bin/deployer-
xenomai
linux-vdso.so.1 => (0x00007ffffebff000)
liblog4cpp.so => /home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/log4cpp/install/lib/liblog4cpp.so
(0x00007f50e1ada000)
liborocos-ocl-log4cpp-xenomai.so.2.3.0 => /home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/lib/liborocos-ocl-log4cpp-xenomai.so.2.3.0
(0x00007f50e186d000)
liborocos-rtt-xenomai.so.2.3 => /home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/rtt/install/lib/liborocos-rtt-xenomai.so.2.3
(0x00007f50e14c7000)
liborocos-ocl-taskbrowser-xenomai.so.2.3.0 => /home/rsmits/ros/kul-
ros-pkg/stacks/orocos_toolchain_ros/ocl/lib/liborocos-ocl-taskbrowser-
xenomai.so.2.3.0 (0x00007f50e128d000)
liborocos-ocl-deployment-xenomai.so.2.3.0 => /home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/ocl/lib/liborocos-ocl-deployment-
xenomai.so.2.3.0 (0x00007f50e0eb3000)
libboost_program_options.so.1.42.0 =>
/usr/lib/libboost_program_options.so.1.42.0 (0x00007f50e0c30000)
librtt-typekit-xenomai.so.2.3.0 => /home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/rtt/install/lib/orocos/types/librtt-typekit-
xenomai.so.2.3.0 (0x00007f50e03e0000)
libboost_filesystem.so.1.42.0 => /usr/lib/libboost_filesystem.so.1.42.0
(0x00007f50e01cb000)
libboost_system.so.1.42.0 => /usr/lib/libboost_system.so.1.42.0
(0x00007f50dffc6000)
libboost_serialization.so.1.42.0 =>
/usr/lib/libboost_serialization.so.1.42.0 (0x00007f50dfd4f000)
libxenomai.so.0 => /usr/lib/libxenomai.so.0 (0x00007f50dfb4a000)
libnative.so.3 => /usr/lib/libnative.so.3 (0x00007f50df93e000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f50df721000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f50df51d000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f50df216000)
libm.so.6 => /lib/libm.so.6 (0x00007f50def93000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f50ded7d000)
libc.so.6 => /lib/libc.so.6 (0x00007f50de9f9000)
libedit.so.2 => /usr/lib/libedit.so.2 (0x00007f50de7d1000)
libncurses.so.5 => /lib/libncurses.so.5 (0x00007f50de58d000)
librtt-scripting-xenomai.so.2.3.0 => /home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/rtt/install/lib/orocos/plugins/librtt-
scripting-xenomai.so.2.3.0 (0x00007f50ddf45000)
librtt-marshalling-xenomai.so.2.3.0 => /home/rsmits/ros/kul-ros-
pkg/stacks/orocos_toolchain_ros/rtt/install/lib/orocos/plugins/librtt-
marshalling-xenomai.so.2.3.0 (0x00007f50ddc8f000)
libroslib.so => /opt/ros/unstable/ros/core/roslib/lib/libroslib.so
(0x00007f50dda82000)
librt.so.1 => /lib/librt.so.1 (0x00007f50dd87a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f50e1d61000)
libbsd.so.0 => /lib/libbsd.so.0 (0x00007f50dd66f000)
librospack.so => /opt/ros/unstable/ros/tools/rospack/lib/librospack.so
(0x00007f50dd441000)
librosstack.so =>
/opt/ros/unstable/ros/tools/rospack/lib/librosstack.so (0x00007f50dd22e000)
libboost_thread.so.1.42.0 => /usr/lib/libboost_thread.so.1.42.0
(0x00007f50dd019000)

How can I check if other linked in libraries are not bugging me? (I'm
suspecting the ros related libs)

-- Ruben
--
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

Checking realtimeness of my component

On Friday 25 February 2011 13:48:45 Ruben Smits wrote:
> On Friday 25 February 2011 13:35:37 Ruben Smits wrote:
> > On Friday 25 February 2011 13:32:06 Ruben Smits wrote:
> > > On Friday 25 February 2011 13:18:18 Ruben Smits wrote:
> > > > On Friday 25 February 2011 13:16:20 Ruben Smits wrote:
> > > > > On Friday 25 February 2011 13:10:43 Peter Soetens wrote:
> > > > > > On Friday 25 February 2011 12:45:54 Ruben Smits wrote:
> > > > > > > On Friday 25 February 2011 12:29:19 Peter Soetens wrote:
> > > > > > > > On Friday 25 February 2011 12:19:55 Ruben Smits wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I'm running RTT/OCL master (from yesterday) on a
> > > > > > > > > 2.6.35.7-xenomai-2.5.5.2
> > > > > > > > > system and wanted to test if my component does
> > > > > > > > > not
> > > > > > > > > cause
> > > > > > > > > context
> > > > > > > > > switches
> > > > > > > > > between hard and soft realtime by using the
> > > > > > > > > rtos_enable_rt_warning()
> > > > > > > > > function in my startHook. The component is
> > > > > > > > > running
> > > > > > > > > fine
> > > > > > > > > without
> > > > > > > > > this
> > > > > > > > > function.
> > > > > > > > >
> > > > > > > > > When I start my component, the process is
> > > > > > > > > directly
> > > > > > > > > killed
> > > > > > > > > with
> > > > > > > > > the
> > > > > > > > > following message:
> > > > > > > > >
> > > > > > > > > Deployer [S]> LWR.start
> > > > > > > > > CPU time limit exceeded
> > > > > > > > >
> > > > > > > > > I checked the what this message means and
> > > > > > > > > <http://www.xenomai.org/documentation/xenomai-2.
> > > > > > > > > 0/pd
> > > > > > > > > f/Na
> > > > > > > > > tive
> > > > > > > > > -API
> > > > > > > > > -Tour.p d f> tells me:
> > > > > > > > > <quote>
> > > > > > > > > Detecting unwanted switches to the secondary
> > > > > > > > > execution
> > > > > > > > > mode
> > > > > > > > > Sometimes, switching to the secondary execution
> > > > > > > > > mode
> > > > > > > > > for
> > > > > > > > > a
> > > > > > > > > real­
> > > > > > > > > time task so that it can
> > > > > > > > > re­
> > > > > > > > > enter the Linux kernel context may be an
> > > > > > > > > unwanted
> > > > > > > > > behaviour,
> > > > > > > > > likely due to invoking a Linux system call
> > > > > > > > > involuntarily. In
> > > > > > > > > order to trap this situation, the native API
> > > > > > > > > allows
> > > > > > > > > real­
> > > > > > > > > time
> > > > > > > > > tasks in user­
> > > > > > > > > space to require the SIGXCPU signal (i.e. CPU
> > > > > > > > > time
> > > > > > > > > limit
> > > > > > > > > exceeded) to
> > > > > > > > > be sent to them each time they switch from the
> > > > > > > > > primary
> > > > > > > > > to
> > > > > > > > > the
> > > > > > > > > secondary execution mode. To use this feature,
> > > > > > > > > the
> > > > > > > > > application
> > > > > > > > > needs to install a handler for the SIGXCPU
> > > > > > > > > signal
> > > > > > > > > (e.g.
> > > > > > > > > using
> > > > > > > > > sigaction(2)), then set the T_WARNSW mode bit
> > > > > > > > > for
> > > > > > > > > the
> > > > > > > > > task
> > > > > > > > > to
> > > > > > > > > monitor, using
> > > > > > > > > the
> > > > > > > > > rt_task_set_mode() system call. If no SIGXCPU
> > > > > > > > > handler
> > > > > > > > > has
> > > > > > > > > been
> > > > > > > > > set, the whole application is terminated upon
> > > > > > > > > receipt of
> > > > > > > > > this
> > > > > > > > > signal. <quote>
> > > > > > > > >
> > > > > > > > > So apparently no SIGXCPU handler has been set
> > > > > > > > > and
> > > > > > > > > this a
> > > > > > > > > bug? Or
> > > > > > > > > I do
> > > > > > > > > something completely wrong and this is a call
> > > > > > > > > for
> > > > > > > > > help
> > > > > > > > > ;)
> > > > > > > >
> > > > > > > > We definately have a SIGXCPU handler setup. The fact
> > > > > > > > that
> > > > > > > > you
> > > > > > > > get
> > > > > > > > the
> > > > > > > > sigxcpu is at least a good sign. You should also see
> > > > > > > > a
> > > > > > > > log
> > > > > > > > [Info]
> > > > > > > > message with : "Installing SIGXCPU handler." right
> > > > > > > > after
> > > > > > > > "Xenomai
> > > > > > > > Periodic Timer runs in preemptive 'one-shot' mode."
> > > > > > >
> > > > > > > Ok, I see this stuff.
> > > > > > >
> > > > > > > > Maybe the readline magic is blocking some signals,
> > > > > > > > you
> > > > > > > > could
> > > > > > > > try
> > > > > > > > to
> > > > > > > > compile with editline (install libeditline-dev) and
> >
> > This should have been install libedit-dev.
> >
> > It's working now, I'll send a patch for the CMakeLists.txt fix
>
> I had to set NO_GPL to ONN, to make sure that libreadline does not get
> linked to the taskbrowser.
>
> But it is still not working, I've made sure that the deployer is not linked
> with readline:
>
> ldd
> /home/rsmits/ros/kul-ros-pkg/stacks/orocos_toolchain_ros/ocl/bin/deployer-
> xenomai
> linux-vdso.so.1 => (0x00007ffffebff000)
> liblog4cpp.so => /home/rsmits/ros/kul-ros-
> pkg/stacks/orocos_toolchain_ros/log4cpp/install/lib/liblog4cpp.so
> (0x00007f50e1ada000)
> liborocos-ocl-log4cpp-xenomai.so.2.3.0 => /home/rsmits/ros/kul-ros-
> pkg/stacks/orocos_toolchain_ros/ocl/lib/liborocos-ocl-log4cpp-xenomai.so.2.
> 3.0 (0x00007f50e186d000)
> liborocos-rtt-xenomai.so.2.3 => /home/rsmits/ros/kul-ros-
> pkg/stacks/orocos_toolchain_ros/rtt/install/lib/liborocos-rtt-xenomai.so.2.
> 3 (0x00007f50e14c7000)
> liborocos-ocl-taskbrowser-xenomai.so.2.3.0 => /home/rsmits/ros/kul-
> ros-pkg/stacks/orocos_toolchain_ros/ocl/lib/liborocos-ocl-taskbrowser-
> xenomai.so.2.3.0 (0x00007f50e128d000)
> liborocos-ocl-deployment-xenomai.so.2.3.0 =>
> /home/rsmits/ros/kul-ros-
> pkg/stacks/orocos_toolchain_ros/ocl/lib/liborocos-ocl-deployment-
> xenomai.so.2.3.0 (0x00007f50e0eb3000)
> libboost_program_options.so.1.42.0 =>
> /usr/lib/libboost_program_options.so.1.42.0 (0x00007f50e0c30000)
> librtt-typekit-xenomai.so.2.3.0 => /home/rsmits/ros/kul-ros-
> pkg/stacks/orocos_toolchain_ros/rtt/install/lib/orocos/types/librtt-typekit
> - xenomai.so.2.3.0 (0x00007f50e03e0000)
> libboost_filesystem.so.1.42.0 =>
> /usr/lib/libboost_filesystem.so.1.42.0 (0x00007f50e01cb000)
> libboost_system.so.1.42.0 => /usr/lib/libboost_system.so.1.42.0
> (0x00007f50dffc6000)
> libboost_serialization.so.1.42.0 =>
> /usr/lib/libboost_serialization.so.1.42.0 (0x00007f50dfd4f000)
> libxenomai.so.0 => /usr/lib/libxenomai.so.0 (0x00007f50dfb4a000)
> libnative.so.3 => /usr/lib/libnative.so.3 (0x00007f50df93e000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x00007f50df721000)
> libdl.so.2 => /lib/libdl.so.2 (0x00007f50df51d000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f50df216000)
> libm.so.6 => /lib/libm.so.6 (0x00007f50def93000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f50ded7d000)
> libc.so.6 => /lib/libc.so.6 (0x00007f50de9f9000)
> libedit.so.2 => /usr/lib/libedit.so.2 (0x00007f50de7d1000)
> libncurses.so.5 => /lib/libncurses.so.5 (0x00007f50de58d000)
> librtt-scripting-xenomai.so.2.3.0 => /home/rsmits/ros/kul-ros-
> pkg/stacks/orocos_toolchain_ros/rtt/install/lib/orocos/plugins/librtt-
> scripting-xenomai.so.2.3.0 (0x00007f50ddf45000)
> librtt-marshalling-xenomai.so.2.3.0 => /home/rsmits/ros/kul-ros-
> pkg/stacks/orocos_toolchain_ros/rtt/install/lib/orocos/plugins/librtt-
> marshalling-xenomai.so.2.3.0 (0x00007f50ddc8f000)
> libroslib.so => /opt/ros/unstable/ros/core/roslib/lib/libroslib.so
> (0x00007f50dda82000)
> librt.so.1 => /lib/librt.so.1 (0x00007f50dd87a000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f50e1d61000)
> libbsd.so.0 => /lib/libbsd.so.0 (0x00007f50dd66f000)
> librospack.so =>
> /opt/ros/unstable/ros/tools/rospack/lib/librospack.so (0x00007f50dd441000)
> librosstack.so =>
> /opt/ros/unstable/ros/tools/rospack/lib/librosstack.so (0x00007f50dd22e000)
> libboost_thread.so.1.42.0 => /usr/lib/libboost_thread.so.1.42.0
> (0x00007f50dd019000)
>
> How can I check if other linked in libraries are not bugging me? (I'm
> suspecting the ros related libs)

I don't know. We could install the signal handler explicitly or try to force
to reinstall it by calling
rtos_task_create_main ( MainThread::Instance()->getTask() );
from the main thread. But i don't know if the double shadow will work in
Xenomai.

Maybe first try the patch in attachment which uses the recommended sigaction
instead of signal...

Peter

Ruben Smits's picture

Checking realtimeness of my component

On Friday 25 February 2011 14:18:18 Peter Soetens wrote:
> On Friday 25 February 2011 13:48:45 Ruben Smits wrote:
>
> > On Friday 25 February 2011 13:35:37 Ruben Smits wrote:
> >
> > > On Friday 25 February 2011 13:32:06 Ruben Smits wrote:
> > >
> > > > On Friday 25 February 2011 13:18:18 Ruben Smits wrote:
> > > >
> > > > > On Friday 25 February 2011 13:16:20 Ruben Smits wrote:
> > > > >
> > > > > > On Friday 25 February 2011 13:10:43 Peter Soetens
> > > > > > wrote:
> > > > > >
> > > > > > > On Friday 25 February 2011 12:45:54 Ruben Smits
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Friday 25 February 2011 12:29:19 Peter
> > > > > > > > Soetens wrote:
> > > > > > > >
> > > > > > > > > On Friday 25 February 2011 12:19:55 Ruben
> > > > > > > > > Smits wrote:
> > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > I'm running RTT/OCL master (from
> > > > > > > > > > yesterday) on a
> > > > > > > > > > 2.6.35.7-xenomai-2.5.5.2
> > > > > > > > > > system and wanted to test if my
> > > > > > > > > > component does
> > > > > > > > > > not
> > > > > > > > > > cause
> > > > > > > > > > context
> > > > > > > > > > switches
> > > > > > > > > > between hard and soft realtime by using
> > > > > > > > > > the
> > > > > > > > > > rtos_enable_rt_warning()
> > > > > > > > > > function in my startHook. The component
> > > > > > > > > > is
> > > > > > > > > > running
> > > > > > > > > > fine
> > > > > > > > > > without
> > > > > > > > > > this
> > > > > > > > > > function.
> > > > > > > > > >
> > > > > > > > > > When I start my component, the process
> > > > > > > > > > is
> > > > > > > > > > directly
> > > > > > > > > > killed
> > > > > > > > > > with
> > > > > > > > > > the
> > > > > > > > > > following message:
> > > > > > > > > >
> > > > > > > > > > Deployer [S]> LWR.start
> > > > > > > > > > CPU time limit exceeded
> > > > > > > > > >
> > > > > > > > > > I checked the what this message means
> > > > > > > > > > and
> > > > > > > > > > <http://www.xenomai.org/documentation/xe
> > > > > > > > > > nomai-2.
> > > > > > > > > > 0/pd
> > > > > > > > > > f/Na
> > > > > > > > > > tive
> > > > > > > > > > -API
> > > > > > > > > > -Tour.p d f> tells me:
> > > > > > > > > > <quote>
> > > > > > > > > > Detecting unwanted switches to the
> > > > > > > > > > secondary
> > > > > > > > > > execution
> > > > > > > > > > mode
> > > > > > > > > > Sometimes, switching to the secondary
> > > > > > > > > > execution
> > > > > > > > > > mode
> > > > > > > > > > for
> > > > > > > > > > a
> > > > > > > > > > real­
> > > > > > > > > > time task so that it can
> > > > > > > > > > re­
> > > > > > > > > > enter the Linux kernel context may be
> > > > > > > > > > an
> > > > > > > > > > unwanted
> > > > > > > > > > behaviour,
> > > > > > > > > > likely due to invoking a Linux system
> > > > > > > > > > call
> > > > > > > > > > involuntarily. In
> > > > > > > > > > order to trap this situation, the native
> > > > > > > > > > API
> > > > > > > > > > allows
> > > > > > > > > > real­
> > > > > > > > > > time
> > > > > > > > > > tasks in user­
> > > > > > > > > > space to require the SIGXCPU signal
> > > > > > > > > > (i.e. CPU
> > > > > > > > > > time
> > > > > > > > > > limit
> > > > > > > > > > exceeded) to
> > > > > > > > > > be sent to them each time they switch
> > > > > > > > > > from the
> > > > > > > > > > primary
> > > > > > > > > > to
> > > > > > > > > > the
> > > > > > > > > > secondary execution mode. To use this
> > > > > > > > > > feature,
> > > > > > > > > > the
> > > > > > > > > > application
> > > > > > > > > > needs to install a handler for the
> > > > > > > > > > SIGXCPU
> > > > > > > > > > signal
> > > > > > > > > > (e.g.
> > > > > > > > > > using
> > > > > > > > > > sigaction(2)), then set the T_WARNSW
> > > > > > > > > > mode bit
> > > > > > > > > > for
> > > > > > > > > > the
> > > > > > > > > > task
> > > > > > > > > > to
> > > > > > > > > > monitor, using
> > > > > > > > > > the
> > > > > > > > > > rt_task_set_mode() system call. If no
> > > > > > > > > > SIGXCPU
> > > > > > > > > > handler
> > > > > > > > > > has
> > > > > > > > > > been
> > > > > > > > > > set, the whole application is terminated
> > > > > > > > > > upon
> > > > > > > > > > receipt of
> > > > > > > > > > this
> > > > > > > > > > signal. <quote>
> > > > > > > > > >
> > > > > > > > > > So apparently no SIGXCPU handler has
> > > > > > > > > > been set
> > > > > > > > > > and
> > > > > > > > > > this a
> > > > > > > > > > bug? Or
> > > > > > > > > > I do
> > > > > > > > > > something completely wrong and this is a
> > > > > > > > > > call
> > > > > > > > > > for
> > > > > > > > > > help
> > > > > > > > > > ;)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > We definately have a SIGXCPU handler setup.
> > > > > > > > > The fact
> > > > > > > > > that
> > > > > > > > > you
> > > > > > > > > get
> > > > > > > > > the
> > > > > > > > > sigxcpu is at least a good sign. You should
> > > > > > > > > also see
> > > > > > > > > a
> > > > > > > > > log
> > > > > > > > > [Info]
> > > > > > > > > message with : "Installing SIGXCPU handler."
> > > > > > > > > right
> > > > > > > > > after
> > > > > > > > > "Xenomai
> > > > > > > > > Periodic Timer runs in preemptive 'one-shot'
> > > > > > > > > mode."
> > > > > > > >
> > > > > > > >
> > > > > > > > Ok, I see this stuff.
> > > > > > > >
> > > > > > > >
> > > > > > > > > Maybe the readline magic is blocking some
> > > > > > > > > signals,
> > > > > > > > > you
> > > > > > > > > could
> > > > > > > > > try
> > > > > > > > > to
> > > > > > > > > compile with editline (install
> > > > > > > > > libeditline-dev) and
> > >
> > >
> > > This should have been install libedit-dev.
> > >
> > > It's working now, I'll send a patch for the CMakeLists.txt fix
> >
> >
> > I had to set NO_GPL to ONN, to make sure that libreadline does not get
> > linked to the taskbrowser.
> >
> > But it is still not working, I've made sure that the deployer is not
> > linked
with readline:
> >
> > ldd
> > /home/rsmits/ros/kul-ros-pkg/stacks/orocos_toolchain_ros/ocl/bin/deploye
> > r-
xenomai
> >
> > linux-vdso.so.1 => (0x00007ffffebff000)
> > liblog4cpp.so => /home/rsmits/ros/kul-ros-
> >
> > pkg/stacks/orocos_toolchain_ros/log4cpp/install/lib/liblog4cpp.so
> > (0x00007f50e1ada000)
> >
> > liborocos-ocl-log4cpp-xenomai.so.2.3.0 =>
> > /home/rsmits/ros/kul-ros-
> >
> > pkg/stacks/orocos_toolchain_ros/ocl/lib/liborocos-ocl-log4cpp-xenomai.so
> > .2.
3.0 (0x00007f50e186d000)
> >
> > liborocos-rtt-xenomai.so.2.3 =>
> > /home/rsmits/ros/kul-ros-
> >
> > pkg/stacks/orocos_toolchain_ros/rtt/install/lib/liborocos-rtt-xenomai.so
> > .2.
3 (0x00007f50e14c7000)
> >
> > liborocos-ocl-taskbrowser-xenomai.so.2.3.0 =>
> > /home/rsmits/ros/kul-
> >
> > ros-pkg/stacks/orocos_toolchain_ros/ocl/lib/liborocos-ocl-taskbrowser-
> > xenomai.so.2.3.0 (0x00007f50e128d000)
> >
> > liborocos-ocl-deployment-xenomai.so.2.3.0 =>
> >
> > /home/rsmits/ros/kul-ros-
> > pkg/stacks/orocos_toolchain_ros/ocl/lib/liborocos-ocl-deployment-
> > xenomai.so.2.3.0 (0x00007f50e0eb3000)
> >
> > libboost_program_options.so.1.42.0 =>
> >
> > /usr/lib/libboost_program_options.so.1.42.0 (0x00007f50e0c30000)
> >
> > librtt-typekit-xenomai.so.2.3.0 =>
> > /home/rsmits/ros/kul-ros-
> >
> > pkg/stacks/orocos_toolchain_ros/rtt/install/lib/orocos/types/librtt-type
> > kit
- xenomai.so.2.3.0 (0x00007f50e03e0000)
> >
> > libboost_filesystem.so.1.42.0 =>
> >
> > /usr/lib/libboost_filesystem.so.1.42.0 (0x00007f50e01cb000)
> >
> > libboost_system.so.1.42.0 =>
> > /usr/lib/libboost_system.so.1.42.0
> >
> > (0x00007f50dffc6000)
> >
> > libboost_serialization.so.1.42.0 =>
> >
> > /usr/lib/libboost_serialization.so.1.42.0 (0x00007f50dfd4f000)
> >
> > libxenomai.so.0 => /usr/lib/libxenomai.so.0
> > (0x00007f50dfb4a000)
> > libnative.so.3 => /usr/lib/libnative.so.3
> > (0x00007f50df93e000)
> > libpthread.so.0 => /lib/libpthread.so.0
> > (0x00007f50df721000)
> > libdl.so.2 => /lib/libdl.so.2 (0x00007f50df51d000)
> > libstdc++.so.6 => /usr/lib/libstdc++.so.6
> > (0x00007f50df216000)
> > libm.so.6 => /lib/libm.so.6 (0x00007f50def93000)
> > libgcc_s.so.1 => /lib/libgcc_s.so.1
> > (0x00007f50ded7d000)
> > libc.so.6 => /lib/libc.so.6 (0x00007f50de9f9000)
> > libedit.so.2 => /usr/lib/libedit.so.2
> > (0x00007f50de7d1000)
> > libncurses.so.5 => /lib/libncurses.so.5
> > (0x00007f50de58d000)
> > librtt-scripting-xenomai.so.2.3.0 =>
> > /home/rsmits/ros/kul-ros-
> >
> > pkg/stacks/orocos_toolchain_ros/rtt/install/lib/orocos/plugins/librtt-
> > scripting-xenomai.so.2.3.0 (0x00007f50ddf45000)
> >
> > librtt-marshalling-xenomai.so.2.3.0 =>
> > /home/rsmits/ros/kul-ros-
> >
> > pkg/stacks/orocos_toolchain_ros/rtt/install/lib/orocos/plugins/librtt-
> > marshalling-xenomai.so.2.3.0 (0x00007f50ddc8f000)
> >
> > libroslib.so =>
> > /opt/ros/unstable/ros/core/roslib/lib/libroslib.so
> >
> > (0x00007f50dda82000)
> >
> > librt.so.1 => /lib/librt.so.1 (0x00007f50dd87a000)
> > /lib64/ld-linux-x86-64.so.2 (0x00007f50e1d61000)
> > libbsd.so.0 => /lib/libbsd.so.0 (0x00007f50dd66f000)
> > librospack.so =>
> >
> > /opt/ros/unstable/ros/tools/rospack/lib/librospack.so
> > (0x00007f50dd441000)
> >
> > librosstack.so =>
> >
> > /opt/ros/unstable/ros/tools/rospack/lib/librosstack.so
> > (0x00007f50dd22e000)
> >
> > libboost_thread.so.1.42.0 =>
> > /usr/lib/libboost_thread.so.1.42.0
> >
> > (0x00007f50dd019000)
> >
> > How can I check if other linked in libraries are not bugging me? (I'm
> > suspecting the ros related libs)
>
>
> I don't know. We could install the signal handler explicitly or try to force
>
>to reinstall it by calling
> rtos_task_create_main ( MainThread::Instance()->getTask() );
> from the main thread. But i don't know if the double shadow will work in
> Xenomai.
>
> Maybe first try the patch in attachment which uses the recommended sigaction
>
>instead of signal...

The patch did not work. But I've backtraced the signal using gdb, it shows
that the context switch is caused by the TaskBrowser, I also see that the
deployer's activity is a RT activity by default, I've tried to set its
activity to ORO_SCHED_OTHER, but that does not seem to work (It still shows up
as rt task in /proc/xenomai/sched, but maybe that's normal).

Shouldn't the deployer by default have a non-RT activitity attached? Why
doesn't the setActivity with ORO_SCHED_OTHER work?

-- Ruben

> Peter