Re: [Xenomai-core] crashing 2.6.22
On 9/30/07, Jan Kiszka [EMAIL PROTECTED] wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 13:42 +0200, Jan Kiszka wrote: Jan Kiszka wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 12:22 +0200, Jan Kiszka wrote: ... And a third one only gives me Detected illicit call from domain Xenomai before the box reboots. :( Grmff... Do you run with your smp_processor_id() instrumentation in? Yes, but I suspect this is just a symptom of some severe memory corruption that (also?) hits I-pipe data structures. I just put in some different instrumentation, and that warning is gone, the box just hangs hard at a different point. Very unfriendly. Hah! Got some crash log by hacking a raw printk-to-uart: [...] 6Xenomai: starting RTDM services. 6NET: Registered protocol family 10 6lo: Disabled Privacy Extensions 6ADDRCONF(NETDEV_UP): eth0: link is not ready 3I-pipe: Detected illicit call from domain 'Xenomai' 3into a service reserved for domain 'Linux' and below. f3a6bc18 c05dad6c f3a6bc3c c0105fc3 c03513c7 c05dc100 0009 f3a6bc54 c01479cb c03592f8 c0357ae2 c035e069 f3a6bc88 f3a6bc70 c0127224 c0111df8 f3a6bd74 f3a6bd74 f3a6bc80 c012727f Call Trace: [c010520f] show_trace_log_lvl+0x1f/0x40 [c01052e1] show_stack_log_lvl+0xb1/0xe0 [c0105fc3] show_stack+0x33/0x40 [c01479cb] ipipe_check_context+0x7b/0x90 [c0127224] __atomic_notifier_call_chain+0x24/0x60 [c012727f] atomic_notifier_call_chain+0x1f/0x30 [c0131e02] notify_die+0x32/0x40 [c0105d29] do_invalid_op+0x59/0xa0 [c0111d0b] __ipipe_handle_exception+0x7b/0x144 [c02dfaeb] error_code+0x6f/0x7c Wow. Why that? [c0111d13] __ipipe_handle_exception+0x83/0x144 [c02dfaeb] error_code+0x6f/0x7c And this? We should not get any exception over an IPI3 handler. I guess the double fault may be explained by this root cause. [c01117df] __ipipe_handle_irq+0x4f/0x140 [c0104c5e] ipipe_ipi3+0x26/0x40 Our LAPIC timer vector. Are you running full modular or statically btw? Fully modular. Compiling the nucleus in makes the lock-up move to another, once again invisible spot. I nailed down the fault address in the scenario above. It's in the nucleus module, at the first byte of xntimer_tick_aperiodic. Are we loosing module text pages over the time? This functions must have been executed before as the timer was armed while I collected the /proc/modules and then triggered the crash. There is a pending issue about vmalloced areas, which I completely forgot: https://mail.gna.org/public/xenomai-core/2007-02/msg00138.html -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] crashing 2.6.22
Gilles Chanteperdrix wrote: On 9/30/07, Jan Kiszka [EMAIL PROTECTED] wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 13:42 +0200, Jan Kiszka wrote: Jan Kiszka wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 12:22 +0200, Jan Kiszka wrote: ... And a third one only gives me Detected illicit call from domain Xenomai before the box reboots. :( Grmff... Do you run with your smp_processor_id() instrumentation in? Yes, but I suspect this is just a symptom of some severe memory corruption that (also?) hits I-pipe data structures. I just put in some different instrumentation, and that warning is gone, the box just hangs hard at a different point. Very unfriendly. Hah! Got some crash log by hacking a raw printk-to-uart: [...] 6Xenomai: starting RTDM services. 6NET: Registered protocol family 10 6lo: Disabled Privacy Extensions 6ADDRCONF(NETDEV_UP): eth0: link is not ready 3I-pipe: Detected illicit call from domain 'Xenomai' 3into a service reserved for domain 'Linux' and below. f3a6bc18 c05dad6c f3a6bc3c c0105fc3 c03513c7 c05dc100 0009 f3a6bc54 c01479cb c03592f8 c0357ae2 c035e069 f3a6bc88 f3a6bc70 c0127224 c0111df8 f3a6bd74 f3a6bd74 f3a6bc80 c012727f Call Trace: [c010520f] show_trace_log_lvl+0x1f/0x40 [c01052e1] show_stack_log_lvl+0xb1/0xe0 [c0105fc3] show_stack+0x33/0x40 [c01479cb] ipipe_check_context+0x7b/0x90 [c0127224] __atomic_notifier_call_chain+0x24/0x60 [c012727f] atomic_notifier_call_chain+0x1f/0x30 [c0131e02] notify_die+0x32/0x40 [c0105d29] do_invalid_op+0x59/0xa0 [c0111d0b] __ipipe_handle_exception+0x7b/0x144 [c02dfaeb] error_code+0x6f/0x7c Wow. Why that? [c0111d13] __ipipe_handle_exception+0x83/0x144 [c02dfaeb] error_code+0x6f/0x7c And this? We should not get any exception over an IPI3 handler. I guess the double fault may be explained by this root cause. [c01117df] __ipipe_handle_irq+0x4f/0x140 [c0104c5e] ipipe_ipi3+0x26/0x40 Our LAPIC timer vector. Are you running full modular or statically btw? Fully modular. Compiling the nucleus in makes the lock-up move to another, once again invisible spot. I nailed down the fault address in the scenario above. It's in the nucleus module, at the first byte of xntimer_tick_aperiodic. Are we loosing module text pages over the time? This functions must have been executed before as the timer was armed while I collected the /proc/modules and then triggered the crash. There is a pending issue about vmalloced areas, which I completely forgot: https://mail.gna.org/public/xenomai-core/2007-02/msg00138.html Would this explain my problems which are already visible without any Xenomai application running (and also without unloading the modules again, to answer Philippe's question)? Hell, I would love to find the reason here, debugging this stuff stopped being fun a long time ago... Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] crashing 2.6.22
On 10/1/07, Jan Kiszka [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On 9/30/07, Jan Kiszka [EMAIL PROTECTED] wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 13:42 +0200, Jan Kiszka wrote: Jan Kiszka wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 12:22 +0200, Jan Kiszka wrote: ... And a third one only gives me Detected illicit call from domain Xenomai before the box reboots. :( Grmff... Do you run with your smp_processor_id() instrumentation in? Yes, but I suspect this is just a symptom of some severe memory corruption that (also?) hits I-pipe data structures. I just put in some different instrumentation, and that warning is gone, the box just hangs hard at a different point. Very unfriendly. Hah! Got some crash log by hacking a raw printk-to-uart: [...] 6Xenomai: starting RTDM services. 6NET: Registered protocol family 10 6lo: Disabled Privacy Extensions 6ADDRCONF(NETDEV_UP): eth0: link is not ready 3I-pipe: Detected illicit call from domain 'Xenomai' 3into a service reserved for domain 'Linux' and below. f3a6bc18 c05dad6c f3a6bc3c c0105fc3 c03513c7 c05dc100 0009 f3a6bc54 c01479cb c03592f8 c0357ae2 c035e069 f3a6bc88 f3a6bc70 c0127224 c0111df8 f3a6bd74 f3a6bd74 f3a6bc80 c012727f Call Trace: [c010520f] show_trace_log_lvl+0x1f/0x40 [c01052e1] show_stack_log_lvl+0xb1/0xe0 [c0105fc3] show_stack+0x33/0x40 [c01479cb] ipipe_check_context+0x7b/0x90 [c0127224] __atomic_notifier_call_chain+0x24/0x60 [c012727f] atomic_notifier_call_chain+0x1f/0x30 [c0131e02] notify_die+0x32/0x40 [c0105d29] do_invalid_op+0x59/0xa0 [c0111d0b] __ipipe_handle_exception+0x7b/0x144 [c02dfaeb] error_code+0x6f/0x7c Wow. Why that? [c0111d13] __ipipe_handle_exception+0x83/0x144 [c02dfaeb] error_code+0x6f/0x7c And this? We should not get any exception over an IPI3 handler. I guess the double fault may be explained by this root cause. [c01117df] __ipipe_handle_irq+0x4f/0x140 [c0104c5e] ipipe_ipi3+0x26/0x40 Our LAPIC timer vector. Are you running full modular or statically btw? Fully modular. Compiling the nucleus in makes the lock-up move to another, once again invisible spot. I nailed down the fault address in the scenario above. It's in the nucleus module, at the first byte of xntimer_tick_aperiodic. Are we loosing module text pages over the time? This functions must have been executed before as the timer was armed while I collected the /proc/modules and then triggered the crash. There is a pending issue about vmalloced areas, which I completely forgot: https://mail.gna.org/public/xenomai-core/2007-02/msg00138.html Would this explain my problems which are already visible without any Xenomai application running (and also without unloading the modules again, to answer Philippe's question)? Hell, I would love to find the reason here, debugging this stuff stopped being fun a long time ago... It would explain bugs involving a race between task creation and vmalloc/ioremap. But the bug would only happen with Xenomai tasks running, otherwise, the vmalloced/ioremaped area would be mapped lazily as usual. -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] crashing 2.6.22
Gilles Chanteperdrix wrote: On 10/1/07, Jan Kiszka [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On 9/30/07, Jan Kiszka [EMAIL PROTECTED] wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 13:42 +0200, Jan Kiszka wrote: Jan Kiszka wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 12:22 +0200, Jan Kiszka wrote: ... And a third one only gives me Detected illicit call from domain Xenomai before the box reboots. :( Grmff... Do you run with your smp_processor_id() instrumentation in? Yes, but I suspect this is just a symptom of some severe memory corruption that (also?) hits I-pipe data structures. I just put in some different instrumentation, and that warning is gone, the box just hangs hard at a different point. Very unfriendly. Hah! Got some crash log by hacking a raw printk-to-uart: [...] 6Xenomai: starting RTDM services. 6NET: Registered protocol family 10 6lo: Disabled Privacy Extensions 6ADDRCONF(NETDEV_UP): eth0: link is not ready 3I-pipe: Detected illicit call from domain 'Xenomai' 3into a service reserved for domain 'Linux' and below. f3a6bc18 c05dad6c f3a6bc3c c0105fc3 c03513c7 c05dc100 0009 f3a6bc54 c01479cb c03592f8 c0357ae2 c035e069 f3a6bc88 f3a6bc70 c0127224 c0111df8 f3a6bd74 f3a6bd74 f3a6bc80 c012727f Call Trace: [c010520f] show_trace_log_lvl+0x1f/0x40 [c01052e1] show_stack_log_lvl+0xb1/0xe0 [c0105fc3] show_stack+0x33/0x40 [c01479cb] ipipe_check_context+0x7b/0x90 [c0127224] __atomic_notifier_call_chain+0x24/0x60 [c012727f] atomic_notifier_call_chain+0x1f/0x30 [c0131e02] notify_die+0x32/0x40 [c0105d29] do_invalid_op+0x59/0xa0 [c0111d0b] __ipipe_handle_exception+0x7b/0x144 [c02dfaeb] error_code+0x6f/0x7c Wow. Why that? [c0111d13] __ipipe_handle_exception+0x83/0x144 [c02dfaeb] error_code+0x6f/0x7c And this? We should not get any exception over an IPI3 handler. I guess the double fault may be explained by this root cause. [c01117df] __ipipe_handle_irq+0x4f/0x140 [c0104c5e] ipipe_ipi3+0x26/0x40 Our LAPIC timer vector. Are you running full modular or statically btw? Fully modular. Compiling the nucleus in makes the lock-up move to another, once again invisible spot. I nailed down the fault address in the scenario above. It's in the nucleus module, at the first byte of xntimer_tick_aperiodic. Are we loosing module text pages over the time? This functions must have been executed before as the timer was armed while I collected the /proc/modules and then triggered the crash. There is a pending issue about vmalloced areas, which I completely forgot: https://mail.gna.org/public/xenomai-core/2007-02/msg00138.html Would this explain my problems which are already visible without any Xenomai application running (and also without unloading the modules again, to answer Philippe's question)? Hell, I would love to find the reason here, debugging this stuff stopped being fun a long time ago... It would explain bugs involving a race between task creation and vmalloc/ioremap. But the bug would only happen with Xenomai tasks running, I don't need to start any Xenomai task to trigger the problem. otherwise, the vmalloced/ioremaped area would be mapped lazily as usual. I guess module text pages are not mapped lazily, otherwise quite a lot of things would have fallen apart much earlier, right? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] crashing 2.6.22
On 10/1/07, Jan Kiszka [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On 10/1/07, Jan Kiszka [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On 9/30/07, Jan Kiszka [EMAIL PROTECTED] wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 13:42 +0200, Jan Kiszka wrote: Jan Kiszka wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 12:22 +0200, Jan Kiszka wrote: ... And a third one only gives me Detected illicit call from domain Xenomai before the box reboots. :( Grmff... Do you run with your smp_processor_id() instrumentation in? Yes, but I suspect this is just a symptom of some severe memory corruption that (also?) hits I-pipe data structures. I just put in some different instrumentation, and that warning is gone, the box just hangs hard at a different point. Very unfriendly. Hah! Got some crash log by hacking a raw printk-to-uart: [...] 6Xenomai: starting RTDM services. 6NET: Registered protocol family 10 6lo: Disabled Privacy Extensions 6ADDRCONF(NETDEV_UP): eth0: link is not ready 3I-pipe: Detected illicit call from domain 'Xenomai' 3into a service reserved for domain 'Linux' and below. f3a6bc18 c05dad6c f3a6bc3c c0105fc3 c03513c7 c05dc100 0009 f3a6bc54 c01479cb c03592f8 c0357ae2 c035e069 f3a6bc88 f3a6bc70 c0127224 c0111df8 f3a6bd74 f3a6bd74 f3a6bc80 c012727f Call Trace: [c010520f] show_trace_log_lvl+0x1f/0x40 [c01052e1] show_stack_log_lvl+0xb1/0xe0 [c0105fc3] show_stack+0x33/0x40 [c01479cb] ipipe_check_context+0x7b/0x90 [c0127224] __atomic_notifier_call_chain+0x24/0x60 [c012727f] atomic_notifier_call_chain+0x1f/0x30 [c0131e02] notify_die+0x32/0x40 [c0105d29] do_invalid_op+0x59/0xa0 [c0111d0b] __ipipe_handle_exception+0x7b/0x144 [c02dfaeb] error_code+0x6f/0x7c Wow. Why that? [c0111d13] __ipipe_handle_exception+0x83/0x144 [c02dfaeb] error_code+0x6f/0x7c And this? We should not get any exception over an IPI3 handler. I guess the double fault may be explained by this root cause. [c01117df] __ipipe_handle_irq+0x4f/0x140 [c0104c5e] ipipe_ipi3+0x26/0x40 Our LAPIC timer vector. Are you running full modular or statically btw? Fully modular. Compiling the nucleus in makes the lock-up move to another, once again invisible spot. I nailed down the fault address in the scenario above. It's in the nucleus module, at the first byte of xntimer_tick_aperiodic. Are we loosing module text pages over the time? This functions must have been executed before as the timer was armed while I collected the /proc/modules and then triggered the crash. There is a pending issue about vmalloced areas, which I completely forgot: https://mail.gna.org/public/xenomai-core/2007-02/msg00138.html Would this explain my problems which are already visible without any Xenomai application running (and also without unloading the modules again, to answer Philippe's question)? Hell, I would love to find the reason here, debugging this stuff stopped being fun a long time ago... It would explain bugs involving a race between task creation and vmalloc/ioremap. But the bug would only happen with Xenomai tasks running, I don't need to start any Xenomai task to trigger the problem. otherwise, the vmalloced/ioremaped area would be mapped lazily as usual. I guess module text pages are not mapped lazily, otherwise quite a lot of things would have fallen apart much earlier, right? This would happen when a task and a module are created at the same time, and the module would be mapped lazily only for the newly created task. -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] crashing 2.6.22
-Original Message- From: [EMAIL PROTECTED] on behalf of Jan Kiszka Sent: Mon 2007-10-01 11:32 AM To: Gilles Chanteperdrix Cc: xenomai-core Subject: Re: [Xenomai-core] crashing 2.6.22 Gilles Chanteperdrix wrote: On 10/1/07, Jan Kiszka [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On 9/30/07, Jan Kiszka [EMAIL PROTECTED] wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 13:42 +0200, Jan Kiszka wrote: Jan Kiszka wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 12:22 +0200, Jan Kiszka wrote: ... And a third one only gives me Detected illicit call from domain Xenomai before the box reboots. :( Grmff... Do you run with your smp_processor_id() instrumentation in? Yes, but I suspect this is just a symptom of some severe memory corruption that (also?) hits I-pipe data structures. I just put in some different instrumentation, and that warning is gone, the box just hangs hard at a different point. Very unfriendly. Hah! Got some crash log by hacking a raw printk-to-uart: [...] 6Xenomai: starting RTDM services. 6NET: Registered protocol family 10 6lo: Disabled Privacy Extensions 6ADDRCONF(NETDEV_UP): eth0: link is not ready 3I-pipe: Detected illicit call from domain 'Xenomai' 3into a service reserved for domain 'Linux' and below. f3a6bc18 c05dad6c f3a6bc3c c0105fc3 c03513c7 c05dc100 0009 f3a6bc54 c01479cb c03592f8 c0357ae2 c035e069 f3a6bc88 f3a6bc70 c0127224 c0111df8 f3a6bd74 f3a6bd74 f3a6bc80 c012727f Call Trace: [c010520f] show_trace_log_lvl+0x1f/0x40 [c01052e1] show_stack_log_lvl+0xb1/0xe0 [c0105fc3] show_stack+0x33/0x40 [c01479cb] ipipe_check_context+0x7b/0x90 [c0127224] __atomic_notifier_call_chain+0x24/0x60 [c012727f] atomic_notifier_call_chain+0x1f/0x30 [c0131e02] notify_die+0x32/0x40 [c0105d29] do_invalid_op+0x59/0xa0 [c0111d0b] __ipipe_handle_exception+0x7b/0x144 [c02dfaeb] error_code+0x6f/0x7c Wow. Why that? [c0111d13] __ipipe_handle_exception+0x83/0x144 [c02dfaeb] error_code+0x6f/0x7c And this? We should not get any exception over an IPI3 handler. I guess the double fault may be explained by this root cause. [c01117df] __ipipe_handle_irq+0x4f/0x140 [c0104c5e] ipipe_ipi3+0x26/0x40 Our LAPIC timer vector. Are you running full modular or statically btw? Fully modular. Compiling the nucleus in makes the lock-up move to another, once again invisible spot. I nailed down the fault address in the scenario above. It's in the nucleus module, at the first byte of xntimer_tick_aperiodic. Are we loosing module text pages over the time? This functions must have been executed before as the timer was armed while I collected the /proc/modules and then triggered the crash. There is a pending issue about vmalloced areas, which I completely forgot: https://mail.gna.org/public/xenomai-core/2007-02/msg00138.html Would this explain my problems which are already visible without any Xenomai application running (and also without unloading the modules again, to answer Philippe's question)? Hell, I would love to find the reason here, debugging this stuff stopped being fun a long time ago... It would explain bugs involving a race between task creation and vmalloc/ioremap. But the bug would only happen with Xenomai tasks running, I don't need to start any Xenomai task to trigger the problem. otherwise, the vmalloced/ioremaped area would be mapped lazily as usual. I guess module text pages are not mapped lazily, otherwise quite a lot of things would have fallen apart much earlier, right? AFAIK Once inserted module text pages are part of the kernel, so have to be reliably ready as long as the servicies offered are registred, is the insertion function which allocates memory, access it to write the text of the module and make it part of the kernel, so is keep in main memory. Saverio Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] ARM compiling error
On 10/1/07, Patrick [EMAIL PROTECTED] wrote: On 10/1/07, Patrick [EMAIL PROTECTED] wrote: I install Xenomai 2.3.4 for ARM on 2.6.20 kernel. The prepare-kernel script work well. Which ARM machine ? Which version of the ARM patch ? From your compilation log, I would say that you are using an I-pipe patch which is older than Xenomai v2.3.4, so the general advice is to use the I-pipe patch which comes with the version of Xenomai you use. I use an ARM PXA270 and adeos-ipipe-2.6.20-arm-1.7-05. I use the latest stable version of Xenomai (2.3.4) and the latest version of ipipe for ARM (1.7). The I-pipe patch which comes with Xenomai (2.3.4) is adeos-ipipe-2.6.20-arm-1.7-06, you will find it in the ksrc/arch/arm/patches subdirectory of Xenomai sources. If you call prepare-kernel without any argument it will pick the right patch. Please do send your replies to the mailing list. -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] crashing 2.6.22
-Original Message- From: [EMAIL PROTECTED] on behalf of Labozzetta, Saverio Sent: Mon 2007-10-01 2:42 PM To: Jan Kiszka; Gilles Chanteperdrix Cc: xenomai-core Subject: Re: [Xenomai-core] crashing 2.6.22 -Original Message- From: [EMAIL PROTECTED] on behalf of Jan Kiszka Sent: Mon 2007-10-01 11:32 AM To: Gilles Chanteperdrix Cc: xenomai-core Subject: Re: [Xenomai-core] crashing 2.6.22 Gilles Chanteperdrix wrote: On 10/1/07, Jan Kiszka [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On 9/30/07, Jan Kiszka [EMAIL PROTECTED] wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 13:42 +0200, Jan Kiszka wrote: Jan Kiszka wrote: Philippe Gerum wrote: On Sun, 2007-09-30 at 12:22 +0200, Jan Kiszka wrote: ... And a third one only gives me Detected illicit call from domain Xenomai before the box reboots. :( Grmff... Do you run with your smp_processor_id() instrumentation in? Yes, but I suspect this is just a symptom of some severe memory corruption that (also?) hits I-pipe data structures. I just put in some different instrumentation, and that warning is gone, the box just hangs hard at a different point. Very unfriendly. Hah! Got some crash log by hacking a raw printk-to-uart: [...] 6Xenomai: starting RTDM services. 6NET: Registered protocol family 10 6lo: Disabled Privacy Extensions 6ADDRCONF(NETDEV_UP): eth0: link is not ready 3I-pipe: Detected illicit call from domain 'Xenomai' 3into a service reserved for domain 'Linux' and below. f3a6bc18 c05dad6c f3a6bc3c c0105fc3 c03513c7 c05dc100 0009 f3a6bc54 c01479cb c03592f8 c0357ae2 c035e069 f3a6bc88 f3a6bc70 c0127224 c0111df8 f3a6bd74 f3a6bd74 f3a6bc80 c012727f Call Trace: [c010520f] show_trace_log_lvl+0x1f/0x40 [c01052e1] show_stack_log_lvl+0xb1/0xe0 [c0105fc3] show_stack+0x33/0x40 [c01479cb] ipipe_check_context+0x7b/0x90 [c0127224] __atomic_notifier_call_chain+0x24/0x60 [c012727f] atomic_notifier_call_chain+0x1f/0x30 [c0131e02] notify_die+0x32/0x40 [c0105d29] do_invalid_op+0x59/0xa0 [c0111d0b] __ipipe_handle_exception+0x7b/0x144 [c02dfaeb] error_code+0x6f/0x7c Wow. Why that? [c0111d13] __ipipe_handle_exception+0x83/0x144 [c02dfaeb] error_code+0x6f/0x7c And this? We should not get any exception over an IPI3 handler. I guess the double fault may be explained by this root cause. [c01117df] __ipipe_handle_irq+0x4f/0x140 [c0104c5e] ipipe_ipi3+0x26/0x40 Our LAPIC timer vector. Are you running full modular or statically btw? Fully modular. Compiling the nucleus in makes the lock-up move to another, once again invisible spot. I nailed down the fault address in the scenario above. It's in the nucleus module, at the first byte of xntimer_tick_aperiodic. Are we loosing module text pages over the time? This functions must have been executed before as the timer was armed while I collected the /proc/modules and then triggered the crash. There is a pending issue about vmalloced areas, which I completely forgot: https://mail.gna.org/public/xenomai-core/2007-02/msg00138.html Would this explain my problems which are already visible without any Xenomai application running (and also without unloading the modules again, to answer Philippe's question)? Hell, I would love to find the reason here, debugging this stuff stopped being fun a long time ago... It would explain bugs involving a race between task creation and vmalloc/ioremap. But the bug would only happen with Xenomai tasks running, I don't need to start any Xenomai task to trigger the problem. otherwise, the vmalloced/ioremaped area would be mapped lazily as usual. I guess module text pages are not mapped lazily, otherwise quite a lot of things would have fallen apart much earlier, right? AFAIK Once inserted module text pages are part of the kernel, so have to be reliably ready as long as the servicies offered are registred, is the insertion function which allocates memory, access it to write the text of the module and make it part of the kernel, so is keep in main memory. I've been silly: the pages are directly allocated in kernel space (GFP_KERNEL), and some of their addresses are pointed by the function offered in some kernel tables... BTW: sorry about the following nasty copiright abuse patch, is automatically attached to any mail I send outside, an sorry also for the filthy email client I use, but I've not found other ways since they put exchange on... Saverio Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this
Re: [Xenomai-core] ARM compiling error
On 10/1/07, Patrick [EMAIL PROTECTED] wrote: -Message d'origine- De: Gilles Chanteperdrix [mailto:[EMAIL PROTECTED] Envoyé: lundi, 1. octobre 2007 15:11 À: Patrick Cc: xenomai-core Objet: Re: [Xenomai-core] ARM compiling error On 10/1/07, Patrick [EMAIL PROTECTED] wrote: On 10/1/07, Patrick [EMAIL PROTECTED] wrote: I install Xenomai 2.3.4 for ARM on 2.6.20 kernel. The prepare-kernel script work well. Which ARM machine ? Which version of the ARM patch ? From your compilation log, I would say that you are using an I-pipe patch which is older than Xenomai v2.3.4, so the general advice is to use the I-pipe patch which comes with the version of Xenomai you use. I use an ARM PXA270 and adeos-ipipe-2.6.20-arm-1.7-05. I use the latest stable version of Xenomai (2.3.4) and the latest version of ipipe for ARM (1.7). The I-pipe patch which comes with Xenomai (2.3.4) is adeos-ipipe-2.6.20-arm-1.7-06, you will find it in the ksrc/arch/arm/patches subdirectory of Xenomai sources. If you call prepare-kernel without any argument it will pick the right patch. Please do send your replies to the mailing list. I have already tried this (with arm-1.7-05 from adeos website and arm-1.7-06 from xenomai/ksrc/arch/arm/patches) but the result is the same. I have just tried to build Xenomai-2.3.4 for PXA 270 (LogicPD PXA270 Card Engine Development Platform), and it builds flawlessly. So, I suggest you erase everything, and restart from clean sources, use I-pipe for ARM version 1.7-06, and nothing else. -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [BUG] posix skin thread doesn't respect /proc/xenomai/affinity
Hi Gilles, almost forgot to report this, didn't find time to dig into it. You can easily check this with cyclictest: affinity mask set to 2, the test will still schedule on CPU0. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] posix skin thread doesn't respect /proc/xenomai/affinity
Jan Kiszka wrote: Hi Gilles, almost forgot to report this, didn't find time to dig into it. You can easily check this with cyclictest: affinity mask set to 2, the test will still schedule on CPU0. Ok, what is needed at skin level to get it to work ? -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] posix skin thread doesn't respect /proc/xenomai/affinity
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi Gilles, almost forgot to report this, didn't find time to dig into it. You can easily check this with cyclictest: affinity mask set to 2, the test will still schedule on CPU0. Ok, what is needed at skin level to get it to work ? If the user doesn't care about affinity explicitly, the skin should have set the current task's affinity to XNPOD_ALL_CPUS on xnshadow_map (same for xnpod_start_thread): http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/shadow.c?v=SVN-trunk#1350 Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
