[Xenomai-help] Xenomai install problems

[Xenomai-help] Xenomai install problems

[Anthony Sharobaiko]

Hi!

I try to get Xenomai running on arm (PXA board). Currently everything compiles perfectly, but testsuite examples simply segfault:
=== cut here ===
root@domain.hid# ./run 
*
*
* Type ^C to stop this application.
*
*
/usr/xenomai/bin/xeno-load: line 247:  1139 Segmentation fault
$suflag $* $cmdargs
=== cut here ===

I use 2.6.16.29 kernel with ipipe-2.6.15-1.5-03. Some hunks were applied by hand, 
but I'm sure that IPIPE works (I've used: http://www.mail-archive.com/adeos-main@gna.org to check).

Also, Xenomai (built into kernel) successfully registers domain:
=== cut here ===
root@domain.hid# cat Xenomai 
Invariant head, Id=0x58454e4f
irq0-25: passed
irq26: wired
irq27-191: passed
irq192-193: passed, virtual
irq194: wired, virtual
=== cut here ===

Where should I dig to get a working testsuite? =)

-- 
	WBR, Anthony Sharobaiko.

Re: [Xenomai-help] Xenomai install problems

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

Anthony Sharobaiko wrote:
> Hi!
> 
> I try to get Xenomai running on arm (PXA board). Currently everything compiles perfectly, but testsuite examples simply segfault:
> === cut here ===
> root@domain.hid# ./run 
> *
> *
> * Type ^C to stop this application.
> *
> *
> /usr/xenomai/bin/xeno-load: line 247:  1139 Segmentation fault
> $suflag $* $cmdargs
> === cut here ===
> 
> I use 2.6.16.29 kernel with ipipe-2.6.15-1.5-03. Some hunks were applied by hand, 
> but I'm sure that IPIPE works (I've used: http://www.mail-archive.com/adeos-main@domain.hid to check).
> 
> Also, Xenomai (built into kernel) successfully registers domain:
> === cut here ===
> root@domain.hid# cat Xenomai 
> Invariant head, Id=0x58454e4f
> irq0-25: passed
> irq26: wired
> irq27-191: passed
> irq192-193: passed, virtual
> irq194: wired, virtual
> === cut here ===
> 
> Where should I dig to get a working testsuite? =)

Is it a pure user-space crash, or do you also see some oops in the
kernel logs? If it's user-space, place attach gdb to find out where it
crashes.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai install problems

[Anthony Sharobaiko]

On Mon, Dec 04, 2006 at 02:45:48PM +0100, Jan Kiszka wrote:
> Is it a pure user-space crash, or do you also see some oops in the
> kernel logs?

Yes, sometimes (I still can not understand what affects this) it crashes with oops:
=== cut here ===
root@domain.hid# ./run 
*
*
* Type ^C to stop this application.
*
*
Bad mode in prefetch abort handler detected: mode UK13_32
Internal error: Oops - bad mode: 0 [#1]
Modules linked in:
CPU: 0
PC is at 0x228
LR is at 0x22b
pc : [<00000228>]    lr : [<0000022b>]    Not tainted
sp : c06f1fb8  ip : 4002afd4  fp : be9d3cb8
r10: 00000000  r9 : 00000000  r8 : 400331b4
r7 : 00000001  r6 : be9d3e34  r5 : be9d3e3c  r4 : 4001c8dc
r3 : 4001c8f0  r2 : be9d3cbc  r1 : 00000001  r0 : ffffffda
Flags: nzcv  IRQs on  FIQs on  Mode UK13_32  Segment user
Control: 397F  Table: A3F34000  DAC: 00000015
Process latency (pid: 1099, stack limit = 0xc06f01a0)
Stack: (0xc06f1fb8 to 0xc06f2000)
1fa0:                                                       ffffffda
00000001 
1fc0: be9d3cbc 4001c8f0 4001c8dc be9d3e3c be9d3e34 00000001 400331b4
00000000 
1fe0: 00000000 be9d3cb8 4002afd4 c06f1fb8 0000022b 00000228 0000001d
ffffffff 
Backtrace: invalid frame pointer 0xbe9d3cb8
Code: bad PC value.
 /usr/xenomai/bin/xeno-load: line 247:  1099 Segmentation fault
 $suflag $* $cmdargs
=== cut here ===

How can I provide more detailed log? ksymoops?

> If it's user-space, place attach gdb to find out where it
> crashes.

ok, I'll try to put gdbserver in there and look.


-- 
	WBR, Anthony Sharobaiko.

Re: [Xenomai-help] Xenomai install problems

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]

Anthony Sharobaiko wrote:
> On Mon, Dec 04, 2006 at 02:45:48PM +0100, Jan Kiszka wrote:
>> Is it a pure user-space crash, or do you also see some oops in the
>> kernel logs?
> 
> Yes, sometimes (I still can not understand what affects this) it crashes with oops:
> === cut here ===
> root@domain.hid# ./run 
> *
> *
> * Type ^C to stop this application.
> *
> *
> Bad mode in prefetch abort handler detected: mode UK13_32
> Internal error: Oops - bad mode: 0 [#1]
> Modules linked in:
> CPU: 0
> PC is at 0x228
> LR is at 0x22b
> pc : [<00000228>]    lr : [<0000022b>]    Not tainted
> sp : c06f1fb8  ip : 4002afd4  fp : be9d3cb8
> r10: 00000000  r9 : 00000000  r8 : 400331b4
> r7 : 00000001  r6 : be9d3e34  r5 : be9d3e3c  r4 : 4001c8dc
> r3 : 4001c8f0  r2 : be9d3cbc  r1 : 00000001  r0 : ffffffda
> Flags: nzcv  IRQs on  FIQs on  Mode UK13_32  Segment user
> Control: 397F  Table: A3F34000  DAC: 00000015
> Process latency (pid: 1099, stack limit = 0xc06f01a0)
> Stack: (0xc06f1fb8 to 0xc06f2000)
> 1fa0:                                                       ffffffda
> 00000001 
> 1fc0: be9d3cbc 4001c8f0 4001c8dc be9d3e3c be9d3e34 00000001 400331b4
> 00000000 
> 1fe0: 00000000 be9d3cb8 4002afd4 c06f1fb8 0000022b 00000228 0000001d
> ffffffff 
> Backtrace: invalid frame pointer 0xbe9d3cb8
> Code: bad PC value.
>  /usr/xenomai/bin/xeno-load: line 247:  1099 Segmentation fault
>  $suflag $* $cmdargs
> === cut here ===
> 
> How can I provide more detailed log? ksymoops?

Give it a try, but the above complaints about invalid PC and frame
pointer sound like your kernel left the tracks and went south long ago.

You said you merged the patch for 2.6.15 on 2.6.16 and applied some
hunks manually. Did you check that the merge is obviously not hiding any
functional changes of the kernel? Do you have a chance to test a 2.6.15
kernel as well to see if this works? Note that I-pipe test does not
cover the whole functionality Xenomai uses.

> 
>> If it's user-space, place attach gdb to find out where it
>> crashes.
> 
> ok, I'll try to put gdbserver in there and look.
> 

Unless a bell is already ringing for some of the ARM gurus here, it
could be helpful to try finding out if a particular syscall/operation of
the latency program triggers the problem. Of course, this direction only
makes sense if the I-pipe merge was most probably clean.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai install problems

[Anthony Sharobaiko]

On Mon, Dec 04, 2006 at 04:22:46PM +0100, Jan Kiszka wrote:
> You said you merged the patch for 2.6.15 on 2.6.16 and applied some
> hunks manually. Did you check that the merge is obviously not hiding any
> functional changes of the kernel?

Well, I looked through all places with fuzz > 1. Some of them were not
very clear to me, and when that test passed, I've decided I made them ok =)
I'll check them again and post (to adeos-main@ ?).

> Do you have a chance to test a 2.6.15 kernel as well to see if this works?

Unforunately, no. Vendor-specific patch is available only for 2.6.16.


-- 
	WBR, Anthony Sharobaiko.

Re: [Xenomai-help] Xenomai install problems

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

Anthony Sharobaiko wrote:
> On Mon, Dec 04, 2006 at 04:22:46PM +0100, Jan Kiszka wrote:
>> You said you merged the patch for 2.6.15 on 2.6.16 and applied some
>> hunks manually. Did you check that the merge is obviously not hiding any
>> functional changes of the kernel?
> 
> Well, I looked through all places with fuzz > 1. Some of them were not
> very clear to me, and when that test passed, I've decided I made them ok =)

As Gilles remarked, it might be a problem in the syscall part. Your
I-pipe test is kernel-only.

> I'll check them again and post (to adeos-main@ ?).

Yep, adeos-main is appropriate. You can add xenomai-core in CC.

> 
>> Do you have a chance to test a 2.6.15 kernel as well to see if this works?
> 
> Unforunately, no. Vendor-specific patch is available only for 2.6.16.

Yeah, as usual. :)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Xenomai install problems

[Gilles Chanteperdrix]

Anthony Sharobaiko wrote:
> Hi!
> 
> I try to get Xenomai running on arm (PXA board). Currently everything compiles perfectly, but testsuite examples simply segfault:
> === cut here ===
> root@domain.hid# ./run 
> *
> *
> * Type ^C to stop this application.
> *
> *
> /usr/xenomai/bin/xeno-load: line 247:  1139 Segmentation fault
> $suflag $* $cmdargs
> === cut here ===
> 
> I use 2.6.16.29 kernel with ipipe-2.6.15-1.5-03. Some hunks were applied by hand, 
> but I'm sure that IPIPE works (I've used: http://www.mail-archive.com/adeos-main@gna.org to check).
> 
> Also, Xenomai (built into kernel) successfully registers domain:
> === cut here ===
> root@domain.hid# cat Xenomai 
> Invariant head, Id=0x58454e4f
> irq0-25: passed
> irq26: wired
> irq27-191: passed
> irq192-193: passed, virtual
> irq194: wired, virtual
> === cut here ===
> 
> Where should I dig to get a working testsuite? =)

Maybe you got the syscall interception wrong ? Could you show us the
difference between your version of arch/arm/kernel/entry-common.S and
the original ?

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] Xenomai install problems

[Anthony Sharobaiko]

On Mon, Dec 04, 2006 at 04:58:35PM +0100, Gilles Chanteperdrix wrote:
>> I try to get Xenomai running on arm (PXA board). Currently everything
>> compiles perfectly, but testsuite examples simply segfault:
> Maybe you got the syscall interception wrong ? Could you show us the
> difference between your version of arch/arm/kernel/entry-common.S and
> the original ?

Yep, thanks! I've overlooked some minor modification there.

Now, I'm getting this:
=== cut here ===
root@domain.hid# ./run 
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
worst
RTD|      14.153|      14.769|      39.384|       0|      14.153|
39.384
RTD|      14.153|      14.461|      35.384|       0|      14.153|
39.384
RTD|      14.153|      14.769|      39.692|       0|      14.153|
39.692
=== cut here ===

After printing these lines board hangs in some strange way: it does not reply
to ping, does not reply on serial console, but heartbeat LED works =/

Number of output lines seems to be random (sometimes it ends on 'warming up...')
Changing priority in latency.c to LOPRIO didn't help.

Hmm, any suggestions? 

-- 
	WBR, Anthony Sharobaiko.

Re: [Xenomai-help] Xenomai install problems

[Gilles Chanteperdrix]

Anthony Sharobaiko wrote:
> On Mon, Dec 04, 2006 at 04:58:35PM +0100, Gilles Chanteperdrix wrote:
> 
>>>I try to get Xenomai running on arm (PXA board). Currently everything
>>>compiles perfectly, but testsuite examples simply segfault:
>>
>>Maybe you got the syscall interception wrong ? Could you show us the
>>difference between your version of arch/arm/kernel/entry-common.S and
>>the original ?
> 
> 
> Yep, thanks! I've overlooked some minor modification there.
> 
> Now, I'm getting this:
> === cut here ===
> root@domain.hid# ./run 
> *
> *
> * Type ^C to stop this application.
> *
> *
> == Sampling period: 100 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> worst
> RTD|      14.153|      14.769|      39.384|       0|      14.153|
> 39.384
> RTD|      14.153|      14.461|      35.384|       0|      14.153|
> 39.384
> RTD|      14.153|      14.769|      39.692|       0|      14.153|
> 39.692
> === cut here ===
> 
> After printing these lines board hangs in some strange way: it does not reply
> to ping, does not reply on serial console, but heartbeat LED works =/
> 
> Number of output lines seems to be random (sometimes it ends on 'warming up...')
> Changing priority in latency.c to LOPRIO didn't help.
> 
> Hmm, any suggestions? 

100us is probably not enough, you should pass -p 1000 to latency.

-- 
                                                 Gilles Chanteperdrix