Re: [Xenomai-core] RT_HEAP Problem
Hi Gilles, excuse me, I will test it and reply to you at Tuesday. regards --- On Thu, 9/25/08, Gilles Chanteperdrix [EMAIL PROTECTED] wrote: From: Gilles Chanteperdrix [EMAIL PROTECTED] Subject: Re: [Xenomai-core] RT_HEAP Problem To: [EMAIL PROTECTED] Cc: xenomai-core@gna.org Date: Thursday, September 25, 2008, 5:33 AM Gilles Chanteperdrix wrote: Gilles Chanteperdrix wrote: Yasser Kashfi wrote: Hi Thanks Gilles for your notes. The problem is solved. Well... not exactly, it shows that the problem is using highmem, but we should now modify xenomai so that it supports using highmem. Hi Yasser, here is a patch which is supposed to fix this issue with highmem. Could you apply it and use the same kernel configuration as you used initially ? Thanks in advance. Hi Yasser, if you do not have time to test this patch, please tell us, we will try and test it by other means. Regards. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt_sem_create bug when registring in proc
stephane ancelot wrote:
Hi,
I have the following kernel bug, when using a string name in
rt_sem_create. using NULL as name do not report this problem.
BUG: unable to handle kernel paging request at virtual address de82a268
printing eip: c025d51a *pde = 1dd3e067 *pte =
Oops: [#1] PREEMPT
Modules linked in: xx(P) elok_s(P) e100 mii
You did not specify the Xenomai version in use. Looking at this output, you may
want to search the bug in your proprietary module code first; it seems that you
passed a string laid into the data segment of a module that has been unloaded,
without removing the semaphore it had initially created.
Pid: 4, comm: events/0 Tainted: P(2.6.24.2-ipipe #3)
EIP: 0060:[c025d51a] EFLAGS: 00010246 CPU: 0
EIP is at strlen+0xa/0x20
EAX: EBX: 8124 ECX: EDX: de82a268
ESI: de82a268 EDI: de82a268 EBP: 0001 ESP: ddc27e8c
DS: 007b ES: 007b FS: GS: SS: 0068
Process events/0 (pid: 4, ti=ddc26000 task=ddc19ab0 task.ti=ddc26000)0
I-pipe domain Linux
Stack: ddc27ebc c01e445b dde783c0 c0257d2a dde78140 de82a268 de82a268
c016e7a0
c048aebc c01e46d4 0001 dde78140 c04fbac4 c016338c
0200
007b 0002 dde783c0
dde78140
Call Trace:
[c01e445b] proc_create+0x4b/0x110
[c0257d2a] idr_get_new+0xa/0x30
[c016e7a0] __sem_read_proc+0x0/0x130
[c01e46d4] create_proc_entry+0x44/0x90
[c016338c] registry_proc_callback+0xa1c/0xb00
[c01130c1] update_curr+0x71/0x100
[c0113148] update_curr+0xf8/0x100
[c01132ef] set_next_entity+0x1f/0x50
[c0162970] registry_proc_callback+0x0/0xb00
[c0129516] run_workqueue+0xb6/0x1a0
[c039ff8f] schedule+0x1df/0x3d0
[c0129e9d] worker_thread+0x6d/0xa0
[c012d670] autoremove_wake_function+0x0/0x50
[c0129e30] worker_thread+0x0/0xa0
[c012d302] kthread+0x42/0x70
[c012d2c0] kthread+0x0/0x70
[c010398b] kernel_thread_helper+0x7/0x1c
===
Code: 00 56 89 c6 89 d0 88 c4 ac 38 e0 74 09 84 c0 75 f7 be 01 00 00 00 89
f0 48 5e c3 8d b6 00 00 00 00 57 b9 ff ff ff ff 89 c7 31 c0 f2 ae f7 d1
49 5f 89 c8 c3 8d b6 00 00 00 00 8d bc 27 00 00 00
EIP: [c025d51a] strlen+0xa/0x20 SS:ESP 0068:ddc27e8c
---[ end trace 614a6309c2874abe ]---
Best regards
S.Ancelot
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi, on some (all ?) platforms, we get a SIGILL when trying to emit the first Xenomai syscall, instead of the -ENOSYS return value. This patches handles the SIGILL by printing an error message and exiting. This is an issue for archs that encode the syscall number into the trap opcode like ARM using the OABI, others will get -ENOSYS as expected, so this should move to the arch-specific code. Actually, I get a SIGILL on ARM compiled with EABI as well. It seems the ARM folks decided to send SIGILL with EABI to conform to the OABI behaviour, despite they did not formally need that. Only invalid calls in the 9f00xx..9f07ff range are expected to return -ENOSYS. Too bad that our syscall marker is out of that range. Moving this code to the arch dependent code looks hard, since we need to setup the jump buffer in the very function which issues the syscall (Ok, we could use a macro). But what would you think of a SIGILL handler which does not longjmp (like Jan suggested, simply print an error message and exit, even if xeno_bind_skin_opt was called) ? Fine with me. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.
Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi, on some (all ?) platforms, we get a SIGILL when trying to emit the first Xenomai syscall, instead of the -ENOSYS return value. This patches handles the SIGILL by printing an error message and exiting. This is an issue for archs that encode the syscall number into the trap opcode like ARM using the OABI, others will get -ENOSYS as expected, so this should move to the arch-specific code. Actually, I get a SIGILL on ARM compiled with EABI as well. It seems the ARM folks decided to send SIGILL with EABI to conform to the OABI behaviour, despite they did not formally need that. Only invalid calls in the 9f00xx..9f07ff range are expected to return -ENOSYS. Too bad that our syscall marker is out of that range. Moving this code to the arch dependent code looks hard, since we need to setup the jump buffer in the very function which issues the syscall (Ok, we could use a macro). But what would you think of a SIGILL handler which does not longjmp (like Jan suggested, simply print an error message and exit, even if xeno_bind_skin_opt was called) ? Fine with me. Ok. Commited in trunk. Do I commit in v2.4.x branch? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi, on some (all ?) platforms, we get a SIGILL when trying to emit the first Xenomai syscall, instead of the -ENOSYS return value. This patches handles the SIGILL by printing an error message and exiting. This is an issue for archs that encode the syscall number into the trap opcode like ARM using the OABI, others will get -ENOSYS as expected, so this should move to the arch-specific code. Actually, I get a SIGILL on ARM compiled with EABI as well. It seems the ARM folks decided to send SIGILL with EABI to conform to the OABI behaviour, despite they did not formally need that. Only invalid calls in the 9f00xx..9f07ff range are expected to return -ENOSYS. Too bad that our syscall marker is out of that range. Moving this code to the arch dependent code looks hard, since we need to setup the jump buffer in the very function which issues the syscall (Ok, we could use a macro). But what would you think of a SIGILL handler which does not longjmp (like Jan suggested, simply print an error message and exit, even if xeno_bind_skin_opt was called) ? Fine with me. Ok. Commited in trunk. Do I commit in v2.4.x branch? Yep. Thanks. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Problems using rt_intr_wait on PowerPC
Hi Based on the user_irq.c I created a simple test program for my PPC405GPr board. We have a FPGA which generates an interrupt every millisecond. It seems to work as simple test (fire it once and assure that it sets the interrupt-bit). When I connect it to the irq_server however (letting the main task sleep 1 second) I get around 2321964 error and not a single OK from rt_intr_wait. Also my debug LED flicker very fast. The FPGA is connected to the External Interrupt 0, which has the number 25. I think that I either got the polarity/level/edge register wrong or I am playing with the wrong interrupt. Could anybody tell me, whether I used the correct interrupt number? Does Linux somewhere overwrite the values for the UIC polarity/level, etc settings written by U-Boot (e.g. for my board in board_early_init_f) Any hints are welcome. Best regards -- NIklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
