[Xenomai-help] Testsuite fails on 2.5-rc3

[Xenomai-help] Testsuite fails on 2.5-rc3

[Jonathan Haws]

All,

I am trying to run Xenomai 2.5-rc3 on a 2.6.30.3 kernel from Denx on an AMCC 405EX CPU.  I have it all installed and ran the testsuite, but the latency, switchtest, switchbench, and cyclictest tests fail with these messages:


=====================================================================

running: ./run -- -sh -T 120 -t0 # latency
*
*
* Type ^C to stop this application.
*
*
Xenomai: open: No such file or directory
Xenomai: mmap(local sem heap): No such file or directory

Thu Jan  1 00:00:20 UTC 1970
running: ./run -- -sh -T 120 -t1 # latency
*
*
* Type ^C to stop this application.
*
*
Xenomai: open: No such file or directory
Xenomai: mmap(local sem heap): No such file or directory

Thu Jan  1 00:00:21 UTC 1970
running: ./run -- -sh -T 120 -t2 # latency
*
*
* Type ^C to stop this application.
*
*
Xenomai: open: No such file or directory
Xenomai: mmap(local sem heap): No such file or directory

Thu Jan  1 00:00:22 UTC 1970
running: ./run -- -T 120 # switchtest
*
*
* Type ^C to stop this application.
*
*
Xenomai: open: No such file or directory
Xenomai: mmap(local sem heap): No such file or directory
/usr/local/xenomai/bin/xeno-test: cd: line 1: can't cd to /usr/local/xenomai/share/xenomai/testsuite/switchbench

Thu Jan  1 00:00:22 UTC 1970
running: ./run -- -h # switchbench
/usr/local/xenomai/bin/xeno-test: eval: line 1: ./run: not found

Thu Jan  1 00:00:23 UTC 1970
running: ./run -- -p 10 -n -l 1000 # cyclictest
*
*
* Type ^C to stop this application.
*
*
Xenomai: open: No such file or directory
Xenomai: mmap(local sem heap): No such file or directory

=====================================================================


Has anyone seen this behavior and know what my problem is?  It may just be a dumb configuration issue.

Note, the reason I went with the development branch instead of the stable release (2.4.9.1) is because I tried 2.4.9.1 and ran xeno-test, which crashed my kernel during the FPU portion of the test.  Here is the output from there:


=====================================================================

Thu Jan  1 00:06:28 UTC 1970
running: ./run -- -T 120 # switchtest
*
*
* Type ^C to stop this application.
*
*
== Testing FPU check routines...
r0: 1 != 2
r1: 1 != 2
r2: 1 != 2
r3: 1 != 2
r4: 1 != 2
r5: 1 != 2
r6: 1 != 2
r7: 1 != 2
r8: 1 != 2
r9: 1 != 2
r10: 1 != 2
r11: 1 != 2
r12: 1 != 2
r13: 1 != 2
r14: 1 != 2
r15: 1 != 2
r16: 1 != 2
r17: 1 != 2
r18: 1 != 2
r19: 1 != 2
r20: 1 != 2
r21: 1 != 2
r22: 1 != 2
r23: 1 != 2
r24: 1 != 2
r25: 1 != 2
r26: 1 != 2
r27: 1 != 2
r28: 1 != 2
r29: 1 != 2
r30: 1 != 2
r31: 1 != 2
== FPU check routines: OK.
== Threads: sleeper_ufps-0 rtk-1Oops: Exception in kernel mode, sig: 11 [#1]
PREEMPT Kilauea
Modules linked in:
NIP: c01e876c LR: c01e86e8 CTR: c0070fb0
REGS: cf1e5440 TRAP: 0700   Not tainted  (2.6.30.3-wolverine-dirty)
MSR: 00029030 <EE,ME,CE,IR,DR>  CR: 40000002  XER: 0000005f
TASK = cd459520[817] 'switchtest' THREAD: cd450000
GPR00: 00000005 cf1e54f0 cd459520 00000000 00000005 00000001 6829524c 00000000
GPR08: 00001164 00000000 00000017 c0390000 20000002 00000000 00021030 c0070d8c
GPR16: cd469208 00000000 00000000 00000000 c0394108 c0381248 003d0900 00000000
GPR24: c02f5580 cf1e5500 cd4691d0 cd45eb78 00000006 cd469208 00000000 00000000
NIP [c01e876c] rtswitch_ktask+0xb0/0x3e4
LR [c01e86e8] rtswitch_ktask+0x2c/0x3e4
Call Trace:
Instruction dump:
7c0003b8 7f9c0038 7f892278 21290000 7d3c0194 7d3c4b78 4182009c 1c1703e8
39200000 7c002214 9001000c 91210008 <c8010008> fc200090 fc400090 fc600090
---[ end trace 203da9216e563608 ]---

=====================================================================


According to the website, these bugs should be fixed in 2.5-rc3.

Thanks for the help!

Jonathan

Re: [Xenomai-help] Testsuite fails on 2.5-rc3

[Gilles Chanteperdrix]

Jonathan Haws wrote:
> All,
> 
> I am trying to run Xenomai 2.5-rc3 on a 2.6.30.3 kernel from Denx on an AMCC 405EX CPU.  I have it all installed and ran the testsuite, but the latency, switchtest, switchbench, and cyclictest tests fail with these messages:
> 
> 
> =====================================================================
> 
> running: ./run -- -sh -T 120 -t0 # latency
> *
> *
> * Type ^C to stop this application.
> *
> *
> Xenomai: open: No such file or directory
> Xenomai: mmap(local sem heap): No such file or directory

You probably have not run make install correctly, so you are missing
/dev/rtheap on the target.


> /usr/local/xenomai/bin/xeno-test: cd: line 1: can't cd to /usr/local/xenomai/share/xenomai/testsuite/switchbench

Do you have a /usr/local/xenomai/share/xenomai/testsuite/switchbench on
the target ?

> 
> Thu Jan  1 00:00:22 UTC 1970
> running: ./run -- -h # switchbench
> /usr/local/xenomai/bin/xeno-test: eval: line 1: ./run: not found

That follows from the previous error (can not cd to the directory where
"run" is supposed to be found, so can not run "run" either).

> == FPU check routines: OK.
> == Threads: sleeper_ufps-0 rtk-1Oops: Exception in kernel mode, sig: 11 [#1]
> PREEMPT Kilauea
> Modules linked in:
> NIP: c01e876c LR: c01e86e8 CTR: c0070fb0
> REGS: cf1e5440 TRAP: 0700   Not tainted  (2.6.30.3-wolverine-dirty)
> MSR: 00029030 <EE,ME,CE,IR,DR>  CR: 40000002  XER: 0000005f
> TASK = cd459520[817] 'switchtest' THREAD: cd450000
> GPR00: 00000005 cf1e54f0 cd459520 00000000 00000005 00000001 6829524c 00000000
> GPR08: 00001164 00000000 00000017 c0390000 20000002 00000000 00021030 c0070d8c
> GPR16: cd469208 00000000 00000000 00000000 c0394108 c0381248 003d0900 00000000
> GPR24: c02f5580 cf1e5500 cd4691d0 cd45eb78 00000006 cd469208 00000000 00000000
> NIP [c01e876c] rtswitch_ktask+0xb0/0x3e4
> LR [c01e86e8] rtswitch_ktask+0x2c/0x3e4
> Call Trace:
> Instruction dump:
> 7c0003b8 7f9c0038 7f892278 21290000 7d3c0194 7d3c4b78 4182009c 1c1703e8
> 39200000 7c002214 9001000c 91210008 <c8010008> fc200090 fc400090 fc600090
> ---[ end trace 203da9216e563608 ]---

This is powerpc, I seem to remember that Philippe told me about this
one, but I do not remember what was its cause.

Could you run /proc/ipipe/version on the machine where you observe this?

-- 
					    Gilles.

Re: [Xenomai-help] Testsuite fails on 2.5-rc3

[Jonathan Haws]

> > All,
> >
> > I am trying to run Xenomai 2.5-rc3 on a 2.6.30.3 kernel from Denx
> on an AMCC 405EX CPU.  I have it all installed and ran the
> testsuite, but the latency, switchtest, switchbench, and cyclictest
> tests fail with these messages:
> >
> >
> >
> ====================================================================
> =
> >
> > running: ./run -- -sh -T 120 -t0 # latency
> > *
> > *
> > * Type ^C to stop this application.
> > *
> > *
> > Xenomai: open: No such file or directory
> > Xenomai: mmap(local sem heap): No such file or directory
> 
> You probably have not run make install correctly, so you are missing
> /dev/rtheap on the target.

You are right, there is no /dev/rtheap on the target.  However, I am building a ramdisk that uses a device table file to create all the devices in /dev when I create them EXT2 image.  What are the major/minor numbers for /dev/rtheap and how many of those devices does Xenomai need?  If I have that information, I should be able to add the device to the table.

I have used RTAI in the past and it seems like when I would insmod an RTAI module, it would create the necessary devices.  How does Xenomai get its devices into /dev normally?

> > /usr/local/xenomai/bin/xeno-test: cd: line 1: can't cd to
> /usr/local/xenomai/share/xenomai/testsuite/switchbench
> 
> Do you have a /usr/local/xenomai/share/xenomai/testsuite/switchbench
> on
> the target ?
> 
> >
> > Thu Jan  1 00:00:22 UTC 1970
> > running: ./run -- -h # switchbench
> > /usr/local/xenomai/bin/xeno-test: eval: line 1: ./run: not found
> 
> That follows from the previous error (can not cd to the directory
> where
> "run" is supposed to be found, so can not run "run" either).

Right again.  There is no switchbench on the target's testsuite.

 
> > == FPU check routines: OK.
> > == Threads: sleeper_ufps-0 rtk-1Oops: Exception in kernel mode,
> sig: 11 [#1]
> > PREEMPT Kilauea
> > Modules linked in:
> > NIP: c01e876c LR: c01e86e8 CTR: c0070fb0
> > REGS: cf1e5440 TRAP: 0700   Not tainted  (2.6.30.3-wolverine-
> dirty)
> > MSR: 00029030 <EE,ME,CE,IR,DR>  CR: 40000002  XER: 0000005f
> > TASK = cd459520[817] 'switchtest' THREAD: cd450000
> > GPR00: 00000005 cf1e54f0 cd459520 00000000 00000005 00000001
> 6829524c 00000000
> > GPR08: 00001164 00000000 00000017 c0390000 20000002 00000000
> 00021030 c0070d8c
> > GPR16: cd469208 00000000 00000000 00000000 c0394108 c0381248
> 003d0900 00000000
> > GPR24: c02f5580 cf1e5500 cd4691d0 cd45eb78 00000006 cd469208
> 00000000 00000000
> > NIP [c01e876c] rtswitch_ktask+0xb0/0x3e4
> > LR [c01e86e8] rtswitch_ktask+0x2c/0x3e4
> > Call Trace:
> > Instruction dump:
> > 7c0003b8 7f9c0038 7f892278 21290000 7d3c0194 7d3c4b78 4182009c
> 1c1703e8
> > 39200000 7c002214 9001000c 91210008 <c8010008> fc200090 fc400090
> fc600090
> > ---[ end trace 203da9216e563608 ]---
> 
> This is powerpc, I seem to remember that Philippe told me about this
> one, but I do not remember what was its cause.
> 
> Could you run /proc/ipipe/version on the machine where you observe
> this?

The version returned in 2.7-00.  However, that is after I ran the 2.5-rc3 patch on the kernel.  I ran prepare_kernel.sh again on my kernel source tree from 2.4.9.1 to try and make sure I was using version 2.4.9.1 and my xeno-test ran like it did before, but with slightly different output:

Thu Jan  1 00:06:52 UTC 1970
running: ./run -- -T 120 # switchtest
*
*
* Type ^C to stop this application.
*
*
== Testing FPU check routines...
r0: 1 != 2
r1: 1 != 2
r2: 1 != 2
r3: 1 != 2
r4: 1 != 2
r5: 1 != 2
r6: 1 != 2
r7: 1 != 2
r8: 1 != 2
r9: 1 != 2
r10: 1 != 2
r11: 1 != 2
r12: 1 != 2
r13: 1 != 2
r14: 1 != 2
r15: 1 != 2
r16: 1 != 2
r17: 1 != 2
r18: 1 != 2
r19: 1 != 2
r20: 1 != 2
r21: 1 != 2
r22: 1 != 2
r23: 1 != 2
r24: 1 != 2
r25: 1 != 2
r26: 1 != 2
r27: 1 != 2
r28: 1 != 2
r29: 1 != 2
r30: 1 != 2
r31: 1 != 2
== FPU check routines: OK.
== Threads: sleeper_ufps-0 rtk-1Oops: Exception in kernel mode, sig: 11 [#1]
PREEMPT Kilauea
Modules linked in:
NIP: c01e876c LR: c01e86e8 CTR: c0070fb0
REGS: cf1e5440 TRAP: 0700   Not tainted  (2.6.30.3-wolverine-dirty)
MSR: 00029030 <EE,ME,CE,IR,DR>  CR: 40000002  XER: 0000005f
TASK = cd412000[819] 'switchtest' THREAD: cd448000
GPR00: 00000005 cf1e54f0 cd412000 00000000 00000005 00000001 a4500f69 00000000
GPR08: 000011af 00000000 00000017 c0390000 20000002 00000000 00021030 c0070d8c
GPR16: cd471208 00000000 00000000 00000000 c0394108 c0381248 003d0900 00000000
GPR24: c02f5580 cf1e5500 cd4711d0 cd4560b8 00000006 cd471208 00000000 00000000
NIP [c01e876c] rtswitch_ktask+0xb0/0x3e4
LR [c01e86e8] rtswitch_ktask+0x2c/0x3e4
Call Trace:
Instruction dump:
7c0003b8 7f9c0038 7f892278 21290000 7d3c0194 7d3c4b78 4182009c 1c1703e8
39200000 7c002214 9001000c 91210008 <c8010008> fc200090 fc400090 fc600090
Kernel panic - not syncing: Fatal exception in interrupt
Call Trace:
Rebooting in 180 seconds..

Thanks,

Jonathan

Re: [Xenomai-help] Testsuite fails on 2.5-rc3

[Gilles Chanteperdrix]

Jonathan Haws wrote:
>>> All,
>>> 
>>> I am trying to run Xenomai 2.5-rc3 on a 2.6.30.3 kernel from Denx
>>> 
>> on an AMCC 405EX CPU.  I have it all installed and ran the 
>> testsuite, but the latency, switchtest, switchbench, and cyclictest
>>  tests fail with these messages:
>>> 
>>> 
>> ====================================================================
>>  =
>>> running: ./run -- -sh -T 120 -t0 # latency * * * Type ^C to stop
>>> this application. * * Xenomai: open: No such file or directory 
>>> Xenomai: mmap(local sem heap): No such file or directory
>> You probably have not run make install correctly, so you are
>> missing /dev/rtheap on the target.
> 
> You are right, there is no /dev/rtheap on the target.  However, I am
> building a ramdisk that uses a device table file to create all the
> devices in /dev when I create them EXT2 image.  What are the
> major/minor numbers for /dev/rtheap and how many of those devices
> does Xenomai need?  If I have that information, I should be able to
> add the device to the table.

These tables exist in many formats, here is the one I use:

crw-    10,254  /dev/rtheap
crw-    150,0   /dev/rtp0
crw-    150,1   /dev/rtp1
crw-    150,2   /dev/rtp2
crw-    150,3   /dev/rtp3
crw-    150,4   /dev/rtp4
crw-    150,5   /dev/rtp5
crw-    150,6   /dev/rtp6
crw-    150,7   /dev/rtp7
crw-    150,8   /dev/rtp8
crw-    150,9   /dev/rtp9
crw-    150,10  /dev/rtp10
crw-    150,11  /dev/rtp11
crw-    150,12  /dev/rtp12
crw-    150,13  /dev/rtp13
crw-    150,14  /dev/rtp14
crw-    150,15  /dev/rtp15
crw-    150,16  /dev/rtp16
crw-    150,17  /dev/rtp17
crw-    150,18  /dev/rtp18
crw-    150,19  /dev/rtp19
crw-    150,20  /dev/rtp20
crw-    150,21  /dev/rtp21
crw-    150,22  /dev/rtp22
crw-    150,23  /dev/rtp23
crw-    150,24  /dev/rtp24
crw-    150,25  /dev/rtp25
crw-    150,26  /dev/rtp26
crw-    150,27  /dev/rtp27
crw-    150,28  /dev/rtp28
crw-    150,29  /dev/rtp29
crw-    150,30  /dev/rtp30
crw-    150,31  /dev/rtp31


> 
> I have used RTAI in the past and it seems like when I would insmod an
> RTAI module, it would create the necessary devices.  How does Xenomai
> get its devices into /dev normally?

In the past, devfs was a kernel thing handling automatic creation of
devices nodes. Now, devfs is dead and buried, udev, a user-space tool
replaces it. So, you need scripts, which are also normally appended to
the /etc/udev/udev.rules of your target when running make install with
the proper DESTDIR. However, for this to work, you need to start udev as
part of your target boot scripts.

> 
>>> /usr/local/xenomai/bin/xeno-test: cd: line 1: can't cd to
>> /usr/local/xenomai/share/xenomai/testsuite/switchbench
>> 
>> Do you have a
>> /usr/local/xenomai/share/xenomai/testsuite/switchbench on the
>> target ?
>> 
>>> Thu Jan  1 00:00:22 UTC 1970 running: ./run -- -h # switchbench 
>>> /usr/local/xenomai/bin/xeno-test: eval: line 1: ./run: not found
>> That follows from the previous error (can not cd to the directory 
>> where "run" is supposed to be found, so can not run "run" either).
> 
> Right again.  There is no switchbench on the target's testsuite.

Ok. Will check on my target if switchbench is properly installed.


> The version returned in 2.7-00.  However, that is after I ran the
> 2.5-rc3 patch on the kernel.  I ran prepare_kernel.sh again on my
> kernel source tree from 2.4.9.1 to try and make sure I was using
> version 2.4.9.1 and my xeno-test ran like it did before, but with
> slightly different output:

Ok. For this issue, I will let Philippe answer.

-- 
                                          Gilles

Re: [Xenomai-help] Testsuite fails on 2.5-rc3

[Gilles Chanteperdrix]

Jonathan Haws wrote:
> Thu Jan  1 00:06:52 UTC 1970
> running: ./run -- -T 120 # switchtest
> *
> *
> * Type ^C to stop this application.
> *
> *
> == Testing FPU check routines...
> r0: 1 != 2
> r1: 1 != 2
> r2: 1 != 2
> r3: 1 != 2
> r4: 1 != 2
> r5: 1 != 2
> r6: 1 != 2
> r7: 1 != 2
> r8: 1 != 2
> r9: 1 != 2
> r10: 1 != 2
> r11: 1 != 2
> r12: 1 != 2
> r13: 1 != 2
> r14: 1 != 2
> r15: 1 != 2
> r16: 1 != 2
> r17: 1 != 2
> r18: 1 != 2
> r19: 1 != 2
> r20: 1 != 2
> r21: 1 != 2
> r22: 1 != 2
> r23: 1 != 2
> r24: 1 != 2
> r25: 1 != 2
> r26: 1 != 2
> r27: 1 != 2
> r28: 1 != 2
> r29: 1 != 2
> r30: 1 != 2
> r31: 1 != 2
> == FPU check routines: OK.
> == Threads: sleeper_ufps-0 rtk-1Oops: Exception in kernel mode, sig: 11 [#1]
> PREEMPT Kilauea
> Modules linked in:
> NIP: c01e876c LR: c01e86e8 CTR: c0070fb0
> REGS: cf1e5440 TRAP: 0700   Not tainted  (2.6.30.3-wolverine-dirty)
> MSR: 00029030 <EE,ME,CE,IR,DR>  CR: 40000002  XER: 0000005f
> TASK = cd412000[819] 'switchtest' THREAD: cd448000
> GPR00: 00000005 cf1e54f0 cd412000 00000000 00000005 00000001 a4500f69 00000000
> GPR08: 000011af 00000000 00000017 c0390000 20000002 00000000 00021030 c0070d8c
> GPR16: cd471208 00000000 00000000 00000000 c0394108 c0381248 003d0900 00000000
> GPR24: c02f5580 cf1e5500 cd4711d0 cd4560b8 00000006 cd471208 00000000 00000000
> NIP [c01e876c] rtswitch_ktask+0xb0/0x3e4
> LR [c01e86e8] rtswitch_ktask+0x2c/0x3e4
> Call Trace:
> Instruction dump:
> 7c0003b8 7f9c0038 7f892278 21290000 7d3c0194 7d3c4b78 4182009c 1c1703e8
> 39200000 7c002214 9001000c 91210008 <c8010008> fc200090 fc400090 fc600090
> Kernel panic - not syncing: Fatal exception in interrupt
> Call Trace:
> Rebooting in 180 seconds..

One thing I can tell for sure reading this trace is that the error is
not caused by the FPU. The error is a "program check exception".

-- 
                                          Gilles

Re: [Xenomai-help] Testsuite fails on 2.5-rc3

[Jonathan Haws]

> > Thu Jan  1 00:06:52 UTC 1970
> > running: ./run -- -T 120 # switchtest
> > *
> > *
> > * Type ^C to stop this application.
> > *
> > *
> > == Testing FPU check routines...
> > r0: 1 != 2
> > r1: 1 != 2
> > r2: 1 != 2
> > r3: 1 != 2
> > r4: 1 != 2
> > r5: 1 != 2
> > r6: 1 != 2
> > r7: 1 != 2
> > r8: 1 != 2
> > r9: 1 != 2
> > r10: 1 != 2
> > r11: 1 != 2
> > r12: 1 != 2
> > r13: 1 != 2
> > r14: 1 != 2
> > r15: 1 != 2
> > r16: 1 != 2
> > r17: 1 != 2
> > r18: 1 != 2
> > r19: 1 != 2
> > r20: 1 != 2
> > r21: 1 != 2
> > r22: 1 != 2
> > r23: 1 != 2
> > r24: 1 != 2
> > r25: 1 != 2
> > r26: 1 != 2
> > r27: 1 != 2
> > r28: 1 != 2
> > r29: 1 != 2
> > r30: 1 != 2
> > r31: 1 != 2
> > == FPU check routines: OK.
> > == Threads: sleeper_ufps-0 rtk-1Oops: Exception in kernel mode,
> sig: 11 [#1]
> > PREEMPT Kilauea
> > Modules linked in:
> > NIP: c01e876c LR: c01e86e8 CTR: c0070fb0
> > REGS: cf1e5440 TRAP: 0700   Not tainted  (2.6.30.3-wolverine-
> dirty)
> > MSR: 00029030 <EE,ME,CE,IR,DR>  CR: 40000002  XER: 0000005f
> > TASK = cd412000[819] 'switchtest' THREAD: cd448000
> > GPR00: 00000005 cf1e54f0 cd412000 00000000 00000005 00000001
> a4500f69 00000000
> > GPR08: 000011af 00000000 00000017 c0390000 20000002 00000000
> 00021030 c0070d8c
> > GPR16: cd471208 00000000 00000000 00000000 c0394108 c0381248
> 003d0900 00000000
> > GPR24: c02f5580 cf1e5500 cd4711d0 cd4560b8 00000006 cd471208
> 00000000 00000000
> > NIP [c01e876c] rtswitch_ktask+0xb0/0x3e4
> > LR [c01e86e8] rtswitch_ktask+0x2c/0x3e4
> > Call Trace:
> > Instruction dump:
> > 7c0003b8 7f9c0038 7f892278 21290000 7d3c0194 7d3c4b78 4182009c
> 1c1703e8
> > 39200000 7c002214 9001000c 91210008 <c8010008> fc200090 fc400090
> fc600090
> > Kernel panic - not syncing: Fatal exception in interrupt
> > Call Trace:
> > Rebooting in 180 seconds..
> 
> One thing I can tell for sure reading this trace is that the error
> is
> not caused by the FPU. The error is a "program check exception".

So, what could be causing the program check in switchtest?  Could it be a misconfiguration of Xenomai in my kernel, or the fact that I had re-patched my kernel with a newer I-pipe patch and then I tried to re-patch again with an older patch?

Forgive me, I am still very new to Xenomai.  Thanks for the help!

Jonathan

Re: [Xenomai-help] Testsuite fails on 2.5-rc3

[Philippe Gerum]

On Thu, 2009-09-10 at 09:29 -0600, Jonathan Haws wrote:
> > > Thu Jan  1 00:06:52 UTC 1970
> > > running: ./run -- -T 120 # switchtest
> > > *
> > > *
> > > * Type ^C to stop this application.
> > > *
> > > *
> > > == Testing FPU check routines...
> > > r0: 1 != 2
> > > r1: 1 != 2
> > > r2: 1 != 2
> > > r3: 1 != 2
> > > r4: 1 != 2
> > > r5: 1 != 2
> > > r6: 1 != 2
> > > r7: 1 != 2
> > > r8: 1 != 2
> > > r9: 1 != 2
> > > r10: 1 != 2
> > > r11: 1 != 2
> > > r12: 1 != 2
> > > r13: 1 != 2
> > > r14: 1 != 2
> > > r15: 1 != 2
> > > r16: 1 != 2
> > > r17: 1 != 2
> > > r18: 1 != 2
> > > r19: 1 != 2
> > > r20: 1 != 2
> > > r21: 1 != 2
> > > r22: 1 != 2
> > > r23: 1 != 2
> > > r24: 1 != 2
> > > r25: 1 != 2
> > > r26: 1 != 2
> > > r27: 1 != 2
> > > r28: 1 != 2
> > > r29: 1 != 2
> > > r30: 1 != 2
> > > r31: 1 != 2
> > > == FPU check routines: OK.
> > > == Threads: sleeper_ufps-0 rtk-1Oops: Exception in kernel mode,
> > sig: 11 [#1]
> > > PREEMPT Kilauea
> > > Modules linked in:
> > > NIP: c01e876c LR: c01e86e8 CTR: c0070fb0
> > > REGS: cf1e5440 TRAP: 0700   Not tainted  (2.6.30.3-wolverine-
> > dirty)
> > > MSR: 00029030 <EE,ME,CE,IR,DR>  CR: 40000002  XER: 0000005f
> > > TASK = cd412000[819] 'switchtest' THREAD: cd448000
> > > GPR00: 00000005 cf1e54f0 cd412000 00000000 00000005 00000001
> > a4500f69 00000000
> > > GPR08: 000011af 00000000 00000017 c0390000 20000002 00000000
> > 00021030 c0070d8c
> > > GPR16: cd471208 00000000 00000000 00000000 c0394108 c0381248
> > 003d0900 00000000
> > > GPR24: c02f5580 cf1e5500 cd4711d0 cd4560b8 00000006 cd471208
> > 00000000 00000000
> > > NIP [c01e876c] rtswitch_ktask+0xb0/0x3e4
> > > LR [c01e86e8] rtswitch_ktask+0x2c/0x3e4
> > > Call Trace:
> > > Instruction dump:
> > > 7c0003b8 7f9c0038 7f892278 21290000 7d3c0194 7d3c4b78 4182009c
> > 1c1703e8
> > > 39200000 7c002214 9001000c 91210008 <c8010008> fc200090 fc400090
> > fc600090
> > > Kernel panic - not syncing: Fatal exception in interrupt
> > > Call Trace:
> > > Rebooting in 180 seconds..
> > 
> > One thing I can tell for sure reading this trace is that the error
> > is
> > not caused by the FPU. The error is a "program check exception".
> 
> So, what could be causing the program check in switchtest?  Could it be a misconfiguration of Xenomai in my kernel, or the fact that I had re-patched my kernel with a newer I-pipe patch and then I tried to re-patch again with an older patch?
> 

This one is an Heisenbug from switchtest. It was known to happen with
FPU-disabled threads as well. I thought I had pinned it a month ago, but
I was wrong.

> Forgive me, I am still very new to Xenomai.  Thanks for the help!
> 
> Jonathan
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Testsuite fails on 2.5-rc3

[Jonathan Haws]

> > > > Thu Jan  1 00:06:52 UTC 1970
> > > > running: ./run -- -T 120 # switchtest
> > > > *
> > > > *
> > > > * Type ^C to stop this application.
> > > > *
> > > > *
> > > > == Testing FPU check routines...
> > > > r0: 1 != 2
> > > > r1: 1 != 2
> > > > r2: 1 != 2
> > > > r3: 1 != 2
> > > > r4: 1 != 2
> > > > r5: 1 != 2
> > > > r6: 1 != 2
> > > > r7: 1 != 2
> > > > r8: 1 != 2
> > > > r9: 1 != 2
> > > > r10: 1 != 2
> > > > r11: 1 != 2
> > > > r12: 1 != 2
> > > > r13: 1 != 2
> > > > r14: 1 != 2
> > > > r15: 1 != 2
> > > > r16: 1 != 2
> > > > r17: 1 != 2
> > > > r18: 1 != 2
> > > > r19: 1 != 2
> > > > r20: 1 != 2
> > > > r21: 1 != 2
> > > > r22: 1 != 2
> > > > r23: 1 != 2
> > > > r24: 1 != 2
> > > > r25: 1 != 2
> > > > r26: 1 != 2
> > > > r27: 1 != 2
> > > > r28: 1 != 2
> > > > r29: 1 != 2
> > > > r30: 1 != 2
> > > > r31: 1 != 2
> > > > == FPU check routines: OK.
> > > > == Threads: sleeper_ufps-0 rtk-1Oops: Exception in kernel
> mode,
> > > sig: 11 [#1]
> > > > PREEMPT Kilauea
> > > > Modules linked in:
> > > > NIP: c01e876c LR: c01e86e8 CTR: c0070fb0
> > > > REGS: cf1e5440 TRAP: 0700   Not tainted  (2.6.30.3-wolverine-
> > > dirty)
> > > > MSR: 00029030 <EE,ME,CE,IR,DR>  CR: 40000002  XER: 0000005f
> > > > TASK = cd412000[819] 'switchtest' THREAD: cd448000
> > > > GPR00: 00000005 cf1e54f0 cd412000 00000000 00000005 00000001
> > > a4500f69 00000000
> > > > GPR08: 000011af 00000000 00000017 c0390000 20000002 00000000
> > > 00021030 c0070d8c
> > > > GPR16: cd471208 00000000 00000000 00000000 c0394108 c0381248
> > > 003d0900 00000000
> > > > GPR24: c02f5580 cf1e5500 cd4711d0 cd4560b8 00000006 cd471208
> > > 00000000 00000000
> > > > NIP [c01e876c] rtswitch_ktask+0xb0/0x3e4
> > > > LR [c01e86e8] rtswitch_ktask+0x2c/0x3e4
> > > > Call Trace:
> > > > Instruction dump:
> > > > 7c0003b8 7f9c0038 7f892278 21290000 7d3c0194 7d3c4b78 4182009c
> > > 1c1703e8
> > > > 39200000 7c002214 9001000c 91210008 <c8010008> fc200090
> fc400090
> > > fc600090
> > > > Kernel panic - not syncing: Fatal exception in interrupt
> > > > Call Trace:
> > > > Rebooting in 180 seconds..
> > >
> > > One thing I can tell for sure reading this trace is that the
> error
> > > is
> > > not caused by the FPU. The error is a "program check exception".
> >
> > So, what could be causing the program check in switchtest?  Could
> it be a misconfiguration of Xenomai in my kernel, or the fact that I
> had re-patched my kernel with a newer I-pipe patch and then I tried
> to re-patch again with an older patch?
> >
> 
> This one is an Heisenbug from switchtest. It was known to happen
> with
> FPU-disabled threads as well. I thought I had pinned it a month ago,
> but
> I was wrong.

Just FYI, I got xeno-test to run correctly under 2.5-rc3 (once I had /dev/rtheap and /dev/rtpXX in place) and got this exact same error with switchtest.  So, it happens in both the stable release and the development branch.

Is this just an artifact of switchtest, or is it something that will come up in my own code?

Thanks,

Jonathan

Re: [Xenomai-help] Testsuite fails on 2.5-rc3

[Philippe Gerum]

On Thu, 2009-09-10 at 14:46 -0600, Jonathan Haws wrote:
> > > > > Thu Jan  1 00:06:52 UTC 1970
> > > > > running: ./run -- -T 120 # switchtest
> > > > > *
> > > > > *
> > > > > * Type ^C to stop this application.
> > > > > *
> > > > > *
> > > > > == Testing FPU check routines...
> > > > > r0: 1 != 2
> > > > > r1: 1 != 2
> > > > > r2: 1 != 2
> > > > > r3: 1 != 2
> > > > > r4: 1 != 2
> > > > > r5: 1 != 2
> > > > > r6: 1 != 2
> > > > > r7: 1 != 2
> > > > > r8: 1 != 2
> > > > > r9: 1 != 2
> > > > > r10: 1 != 2
> > > > > r11: 1 != 2
> > > > > r12: 1 != 2
> > > > > r13: 1 != 2
> > > > > r14: 1 != 2
> > > > > r15: 1 != 2
> > > > > r16: 1 != 2
> > > > > r17: 1 != 2
> > > > > r18: 1 != 2
> > > > > r19: 1 != 2
> > > > > r20: 1 != 2
> > > > > r21: 1 != 2
> > > > > r22: 1 != 2
> > > > > r23: 1 != 2
> > > > > r24: 1 != 2
> > > > > r25: 1 != 2
> > > > > r26: 1 != 2
> > > > > r27: 1 != 2
> > > > > r28: 1 != 2
> > > > > r29: 1 != 2
> > > > > r30: 1 != 2
> > > > > r31: 1 != 2
> > > > > == FPU check routines: OK.
> > > > > == Threads: sleeper_ufps-0 rtk-1Oops: Exception in kernel
> > mode,
> > > > sig: 11 [#1]
> > > > > PREEMPT Kilauea
> > > > > Modules linked in:
> > > > > NIP: c01e876c LR: c01e86e8 CTR: c0070fb0
> > > > > REGS: cf1e5440 TRAP: 0700   Not tainted  (2.6.30.3-wolverine-
> > > > dirty)
> > > > > MSR: 00029030 <EE,ME,CE,IR,DR>  CR: 40000002  XER: 0000005f
> > > > > TASK = cd412000[819] 'switchtest' THREAD: cd448000
> > > > > GPR00: 00000005 cf1e54f0 cd412000 00000000 00000005 00000001
> > > > a4500f69 00000000
> > > > > GPR08: 000011af 00000000 00000017 c0390000 20000002 00000000
> > > > 00021030 c0070d8c
> > > > > GPR16: cd471208 00000000 00000000 00000000 c0394108 c0381248
> > > > 003d0900 00000000
> > > > > GPR24: c02f5580 cf1e5500 cd4711d0 cd4560b8 00000006 cd471208
> > > > 00000000 00000000
> > > > > NIP [c01e876c] rtswitch_ktask+0xb0/0x3e4
> > > > > LR [c01e86e8] rtswitch_ktask+0x2c/0x3e4
> > > > > Call Trace:
> > > > > Instruction dump:
> > > > > 7c0003b8 7f9c0038 7f892278 21290000 7d3c0194 7d3c4b78 4182009c
> > > > 1c1703e8
> > > > > 39200000 7c002214 9001000c 91210008 <c8010008> fc200090
> > fc400090
> > > > fc600090
> > > > > Kernel panic - not syncing: Fatal exception in interrupt
> > > > > Call Trace:
> > > > > Rebooting in 180 seconds..
> > > >
> > > > One thing I can tell for sure reading this trace is that the
> > error
> > > > is
> > > > not caused by the FPU. The error is a "program check exception".
> > >
> > > So, what could be causing the program check in switchtest?  Could
> > it be a misconfiguration of Xenomai in my kernel, or the fact that I
> > had re-patched my kernel with a newer I-pipe patch and then I tried
> > to re-patch again with an older patch?
> > >
> > 
> > This one is an Heisenbug from switchtest. It was known to happen
> > with
> > FPU-disabled threads as well. I thought I had pinned it a month ago,
> > but
> > I was wrong.
> 
> Just FYI, I got xeno-test to run correctly under 2.5-rc3 (once I had /dev/rtheap and /dev/rtpXX in place) and got this exact same error with switchtest.  So, it happens in both the stable release and the development branch.
> 

2.4.9.1 and 2.5-rc3 are mostly in sync wrt to switchtest.

> Is this just an artifact of switchtest, or is it something that will come up in my own code?

Switchtest definitely has a bug, but the fact that it tests the FPU is
not relevant to this issue (IOW, the test engine has a problem, not what
is being tested).

> 
> Thanks,
> 
> Jonathan
-- 
Philippe.