Make check: Simulationthread seems to be blocked

Hi,

while running make check on the latest rtt-1.4 branch/xenomai 2.3.x,
the taskcontext test produces some [CRITICAL] warnings, and then hangs
(only the "make check" hangs, the system does _not_ hang, and see explanation of why the test seems to hang below).


3/ 7 Testing event-test
Test command:
/home/kgad/SVN/rtt-1.4/build-xenomai-v2.3.x/tests/event-test
....................

OK (20)
-- Process completed
Passed
4/ 7 Testing taskcontext-test
Test command:
/home/kgad/SVN/rtt-1.4/build-xenomai-v2.3.x/tests/taskcontext-test
...1259.379 [CRITICAL][Logger] The SimulationThread thread seems to be blocked ( ret was -1 .)
.1259.382 [CRITICAL][Logger] The SimulationThread thread seems to be blocked ( ret was -1 .)
.1259.386 [CRITICAL][Logger] The SimulationThread thread seems to be blocked ( ret was -1 .)
.1259.389 [CRITICAL][Logger] The SimulationThread thread seems to be blocked ( ret was -1 .)
.1259.392 [CRITICAL][Logger] The SimulationThread thread seems to be blocked ( ret was -1 .)
.1259.396 [CRITICAL][Logger] The SimulationThread thread seems to be blocked ( ret was -1 .)
.1259.413 [CRITICAL][Logger] The SimulationThread thread seems to be blocked ( ret was -1 .)
.1259.418 [CRITICAL][Logger] The SimulationThread thread seems to be blocked ( ret was -1 .)
.1259.437 [CRITICAL][Logger] The SimulationThread thread seems to be blocked ( ret was -1 .)
.1259.444 [CRITICAL][Logger] The SimulationThread thread seems to be blocked ( ret was -1 .)
[further messages omitted]
1259.559 [CRITICAL][Logger] The SimulationThread thread seems to be blocked ( ret was -1 .)
OK (24)


After which the test seems to hang.

I have compiled xenomai with some debugging options, and this is what syslog shows for the above case:


Feb 13 09:11:07 newton kernel: I-pipe: Detected illicit call from domain 'Xenomai'
Feb 13 09:11:07 newton kernel: into a service reserved for domain 'Linux' and below.
Feb 13 09:11:07 newton kernel: e4735dd8 00000000 00000000 52544149 e4735dfc c010479a c02d5500 c04d9180
Feb 13 09:11:07 newton kernel: f1b81420 e4735e14 c0137b7d c02c7f9c c02c6b7f c02c5bb0 fefcf800 e4735e20
Feb 13 09:11:07 newton kernel: c01326f1 f15d60f0 e4735e44 fef95cd4 fefad548 e4735e44 c010ea0c 00000000
Feb 13 09:11:07 newton kernel: Call Trace:
Feb 13 09:11:07 newton kernel: [] show_trace_log_lvl+0x1f/0x35
Feb 13 09:11:07 newton kernel: [] show_stack_log_lvl+0xaa/0xcf
Feb 13 09:11:07 newton kernel: [] show_stack+0x2f/0x36
Feb 13 09:11:07 newton kernel: [] ipipe_check_context+0x7a/0x81
Feb 13 09:11:07 newton kernel: [] module_put+0x19/0x7d
Feb 13 09:11:07 newton kernel: [] xnshadow_unmap+0xbc/0x192 [xeno_nucleus]
Feb 13 09:11:07 newton kernel: [] __shadow_delete_hook+0x25/0x27 [xeno_native]
Feb 13 09:11:07 newton kernel: [] xnpod_schedule+0x206/0xcda [xeno_nucleus]
Feb 13 09:11:07 newton kernel: [] xnintr_irq_handler+0x134/0x172 [xeno_nucleus]
Feb 13 09:11:07 newton kernel: [] xnintr_clock_handler+0x17/0x19 [xeno_nucleus]
Feb 13 09:11:07 newton kernel: [] __ipipe_dispatch_wired+0x9b/0xcd
Feb 13 09:11:07 newton kernel: [] __ipipe_handle_irq+0x69/0x168
Feb 13 09:11:07 newton kernel: [] ipipe_ipi3+0x33/0x58
Feb 13 09:11:07 newton kernel: [] __ipipe_dispatch_event+0xbe/0x1fd
Feb 13 09:11:07 newton kernel: =======================
Feb 13 09:11:07 newton kernel: I-pipe tracer log (100 points):
Feb 13 09:11:07 newton kernel: | # *func 0 ipipe_trace_panic_freeze+0x9 (ipipe_check_context+0x3f)
Feb 13 09:11:07 newton kernel: | # *func 0 ipipe_check_context+0xc (module_put+0x19)
[rest of tracer log omitted]
Feb 13 09:11:07 newton kernel: Xenomai: watchdog triggered -- killing runaway thread 'SimulationThread'

The first messages and the last one seems to be particularly relevant :-)

Running the xenomai tests (latency and xeno-test) under heavy disk and
ping flood loads works out fine.

I'm running the recent versions of the xenomai 2.3.x branch and the
orocos 1.4.x branch:
[kgad@newton ~/SVN/rtt-1.4]$
svn info
Path: .
URL: https://svn.mech.kuleuven.be/repos/orocos/branches/rtt/rtt-1.4
Repository Root: https://svn.mech.kuleuven.be/repos/orocos
Repository UUID: ce417995-dfc9-0310-95a0-acdaff106893
Revision: 28949
Node Kind: directory
Schedule: normal
Last Changed Author: psoetens
Last Changed Rev: 28756
Last Changed Date: 2007-11-22 15:03:07 +0100 (Thu, 22 Nov 2007)

[kgad@newton ~/SVN/rtt-1.4]$
cd ../xenomai-v2.3.x/
[kgad@newton ~/SVN/xenomai-v2.3.x]$
svn info
Path: .
URL: http://svn.gna.org/svn/xenomai/branches/v2.3.x
Repository Root: http://svn.gna.org/svn/xenomai
Repository UUID: c6d672ea-8702-0410-b560-f74c916a59fe
Revision: 3494
Node Kind: directory
Schedule: normal
Last Changed Author: rpm
Last Changed Rev: 3430
Last Changed Date: 2008-01-17 17:14:39 +0100 (Thu, 17 Jan 2008)

[kgad@newton ~/SVN/xenomai-v2.3.x]$
uname -a
Linux newton 2.6.20.21-ipipe-1.12-02 #1 PREEMPT Tue Feb 12 11:40:37
CET 2008 i686 GNU/Linux

>From looking at websvn, could this be , which also applies for xenomai 2.3.x and is not yet merged into the 1.4 branch?

Klaas

Make check: Simulationthread seems to be blocked

On Wed, 13 Feb 2008, Klaas Gadeyne wrote:
> Hi,
>
> while running make check on the latest rtt-1.4 branch/xenomai 2.3.x,
> the taskcontext test produces some [CRITICAL] warnings, and then hangs
> (only the "make check" hangs, the system does _not_ hang, and see explanation
> of why the test seems to hang below).
>
[...]
> After which the test seems to hang.

> The first messages and the last one seems to be particularly relevant :-)
>
> Running the xenomai tests (latency and xeno-test) under heavy disk and
> ping flood loads works out fine.

> From looking at websvn, could this be
> ,
> which also applies for xenomai 2.3.x and is not yet merged into the 1.4
> branch?

The fact that my system does _not_ hang (contrary to what is described
in the above bugreport) could be due to the fact that
the xenomai watchdog kills this thread?

Klaas

Make check: Simulationthread seems to be blocked

On Wed, 13 Feb 2008, Klaas Gadeyne wrote:
> On Wed, 13 Feb 2008, Klaas Gadeyne wrote:
>> Hi,
>>
>> while running make check on the latest rtt-1.4 branch/xenomai 2.3.x,
>> the taskcontext test produces some [CRITICAL] warnings, and then hangs
>> (only the "make check" hangs, the system does _not_ hang, and see
>> explanation of why the test seems to hang below).
>>
> [...]
>> After which the test seems to hang.
>
>> The first messages and the last one seems to be particularly relevant :-)
>>
>> Running the xenomai tests (latency and xeno-test) under heavy disk and
>> ping flood loads works out fine.
>
>> From looking at websvn, could this be
>> ,
>> which also applies for xenomai 2.3.x and is not yet merged into the 1.4
>> branch?
>
>
>
> The fact that my system does _not_ hang (contrary to what is described
> in the above bugreport) could be due to the fact that
> the xenomai watchdog kills this thread?

Confirmed: After

[kgad@newton ~/SVN/rtt-1.4]$
svn merge -r 28826:28827 http://svn.mech.kuleuven.be/repos/orocos/trunk/rtt/ .
U src/os/xenomai/fosi_internal.cpp

The tests pass fine. So
- Can we merge this patch into the stable branch?
- maybe bugreport 486 should be retitled (as the bug not only occurs for xenomai 2.4)

Klaas

Make check: Simulationthread seems to be blocked

On Wednesday 13 February 2008 09:44:25 Klaas Gadeyne wrote:
> On Wed, 13 Feb 2008, Klaas Gadeyne wrote:
> > On Wed, 13 Feb 2008, Klaas Gadeyne wrote:
> >> From looking at websvn, could this be
> >> > >>=28827&sc=1>, which also applies for xenomai 2.3.x and is not yet merged
> >> into the 1.4 branch?
> >
> >
> >
> > The fact that my system does _not_ hang (contrary to what is described
> > in the above bugreport) could be due to the fact that
> > the xenomai watchdog kills this thread?
>
> Confirmed: After
>
> [kgad@newton ~/SVN/rtt-1.4]$
> svn merge -r 28826:28827
> http://svn.mech.kuleuven.be/repos/orocos/trunk/rtt/ . U
> src/os/xenomai/fosi_internal.cpp
>
> The tests pass fine. So
> - Can we merge this patch into the stable branch?
> - maybe bugreport 486 should be retitled (as the bug not only occurs for
> xenomai 2.4)

This bug was fixed in the Debian packages. The Debian packages have my
priority now and the branch has been lagging behind. It's soon time for the
1.4.1 release anyway as quite some RTT and OCL bugs have been fixed.

trunk/rtt is more stable at this point than the branches/rtt/rtt-1.4 as no new
developments have been checked in.

Peter

Make check: Simulationthread seems to be blocked

On Wed, 13 Feb 2008, Peter Soetens wrote:
> On Wednesday 13 February 2008 09:44:25 Klaas Gadeyne wrote:
>> On Wed, 13 Feb 2008, Klaas Gadeyne wrote:
>>> On Wed, 13 Feb 2008, Klaas Gadeyne wrote:
>>>> From looking at websvn, could this be
>>>> >>>> =28827&sc=1>, which also applies for xenomai 2.3.x and is not yet merged
>>>> into the 1.4 branch?
>>>
>>>
>>>
>>> The fact that my system does _not_ hang (contrary to what is described
>>> in the above bugreport) could be due to the fact that
>>> the xenomai watchdog kills this thread?
>>
>> Confirmed: After
>>
>> [kgad@newton ~/SVN/rtt-1.4]$
>> svn merge -r 28826:28827
>> http://svn.mech.kuleuven.be/repos/orocos/trunk/rtt/ . U
>> src/os/xenomai/fosi_internal.cpp
>>
>> The tests pass fine. So
>> - Can we merge this patch into the stable branch?
>> - maybe bugreport 486 should be retitled (as the bug not only occurs for
>> xenomai 2.4)
>
> This bug was fixed in the Debian packages. The Debian packages have my
> priority now and the branch has been lagging behind. It's soon time for the
> 1.4.1 release anyway as quite some RTT and OCL bugs have been fixed.

I thought the debian packages were/would be generated from the 1.4
stable branch?

Klaas

> trunk/rtt is more stable at this point than the branches/rtt/rtt-1.4 as no new
> developments have been checked in.
>
> Peter
>
>
>

Make check: Simulationthread seems to be blocked

On Wednesday 13 February 2008 10:58:04 Klaas Gadeyne wrote:
>
> I thought the debian packages were/would be generated from the 1.4
> stable branch?

No, I use the dpatch mechanism for pulling patches from trunk into the
packages. I haven't found yet a good workflow for combining
SVN+dpkg-buildpackage.

There is an svn-buildpackage, but I couldn't find the right workflow with that
tool. But maybe I just didn't get it right and it's time to revise the
workflow.

Peter