* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
@ 2006-11-29 12:19 Nicolas BLANCHARD
2006-12-03 19:32 ` Jan Kiszka
0 siblings, 1 reply; 20+ messages in thread
From: Nicolas BLANCHARD @ 2006-11-29 12:19 UTC (permalink / raw)
To: xenomai, jan.kiszka
>>>> "Nicolas BLANCHARD" <n.blanchard@domain.hid> 29.11 11:25 >>>
>Hello,
>
>I've tested wiith Xenomai 2.3-rc2 (adeos 1.5-02)
>and change the config :
> - CONFIG_M586
> - disable CONFIG_INPUT_PCSPKR
(it was on module)
> - disable prio boosting (check
CONFIG_XENO_OPT_RPDISALBLE)
>
>and it seems to work better, one hour without blocking, it's a record
>for me.
>
>So, i will investigate to find which modification improve my problem.
After somes tests (kernel compil), it seems that prio boost is
responsable of my
problem. When it's disable (kernel option checked) my program run
correctly.
I'm not sure to understand how the prio boost work.
Can someone explain ?
thanks
blanchard nicolas
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
2006-11-29 12:19 Rép. : Re: [Xenomai-help] Switch mode with x86 Nicolas BLANCHARD
@ 2006-12-03 19:32 ` Jan Kiszka
2006-12-03 19:59 ` Philippe Gerum
2006-12-03 21:02 ` Philippe Gerum
0 siblings, 2 replies; 20+ messages in thread
From: Jan Kiszka @ 2006-12-03 19:32 UTC (permalink / raw)
To: Nicolas BLANCHARD; +Cc: xenomai
Nicolas BLANCHARD wrote:
>>>>> "Nicolas BLANCHARD" <n.blanchard@domain.hid> 29.11 11:25 >>>
>> Hello,
>>
>> I've tested wiith Xenomai 2.3-rc2 (adeos 1.5-02)
>> and change the config :
>> - CONFIG_M586
>> - disable CONFIG_INPUT_PCSPKR
> (it was on module)
>> - disable prio boosting (check
> CONFIG_XENO_OPT_RPDISALBLE)
>> and it seems to work better, one hour without blocking, it's a record
>> for me.
>>
>> So, i will investigate to find which modification improve my problem.
>
> After somes tests (kernel compil), it seems that prio boost is
> responsable of my
> problem. When it's disable (kernel option checked) my program run
> correctly.
Confirmed!
root@domain.hid :/root# cat /proc/xenomai/sched
CPU PID PRI PERIOD TIMEOUT STAT NAME
0 0 99 0 0 R ROOT
0 837 99 9999312 0 X TASK1
0 838 0 10999998 0 R TASK2
So far "only" on real hardware (P-I 133) with CONFIG_M586 and (this is
likely also very important) CONFIG_PREEMPT. I'm now about to check if I
can migrate this problem into qemu and/or capture it with the I-pipe tracer.
Jan
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
2006-12-03 19:32 ` Jan Kiszka
@ 2006-12-03 19:59 ` Philippe Gerum
2006-12-03 20:10 ` Jan Kiszka
2006-12-03 21:09 ` Jan Kiszka
2006-12-03 21:02 ` Philippe Gerum
1 sibling, 2 replies; 20+ messages in thread
From: Philippe Gerum @ 2006-12-03 19:59 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
On Sun, 2006-12-03 at 20:32 +0100, Jan Kiszka wrote:
> Nicolas BLANCHARD wrote:
> >>>>> "Nicolas BLANCHARD" <n.blanchard@domain.hid> 29.11 11:25 >>>
> >> Hello,
> >>
> >> I've tested wiith Xenomai 2.3-rc2 (adeos 1.5-02)
> >> and change the config :
> >> - CONFIG_M586
> >> - disable CONFIG_INPUT_PCSPKR
> > (it was on module)
> >> - disable prio boosting (check
> > CONFIG_XENO_OPT_RPDISALBLE)
> >> and it seems to work better, one hour without blocking, it's a record
> >> for me.
> >>
> >> So, i will investigate to find which modification improve my problem.
> >
> > After somes tests (kernel compil), it seems that prio boost is
> > responsable of my
> > problem. When it's disable (kernel option checked) my program run
> > correctly.
>
> Confirmed!
>
> root@domain.hid :/root# cat /proc/xenomai/sched
> CPU PID PRI PERIOD TIMEOUT STAT NAME
> 0 0 99 0 0 R ROOT
> 0 837 99 9999312 0 X TASK1
> 0 838 0 10999998 0 R TASK2
>
> So far "only" on real hardware (P-I 133) with CONFIG_M586 and (this is
> likely also very important) CONFIG_PREEMPT. I'm now about to check if I
> can migrate this problem into qemu and/or capture it with the I-pipe tracer.
>
Please also try moving task2 to the SCHED_FIFO class to see if things
evolve.
> Jan
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
2006-12-03 19:59 ` Philippe Gerum
@ 2006-12-03 20:10 ` Jan Kiszka
2006-12-03 21:09 ` Jan Kiszka
1 sibling, 0 replies; 20+ messages in thread
From: Jan Kiszka @ 2006-12-03 20:10 UTC (permalink / raw)
To: rpm; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]
Philippe Gerum wrote:
> On Sun, 2006-12-03 at 20:32 +0100, Jan Kiszka wrote:
>> Nicolas BLANCHARD wrote:
>>>>>>> "Nicolas BLANCHARD" <n.blanchard@domain.hid> 29.11 11:25 >>>
>>>> Hello,
>>>>
>>>> I've tested wiith Xenomai 2.3-rc2 (adeos 1.5-02)
>>>> and change the config :
>>>> - CONFIG_M586
>>>> - disable CONFIG_INPUT_PCSPKR
>>> (it was on module)
>>>> - disable prio boosting (check
>>> CONFIG_XENO_OPT_RPDISALBLE)
>>>> and it seems to work better, one hour without blocking, it's a record
>>>> for me.
>>>>
>>>> So, i will investigate to find which modification improve my problem.
>>> After somes tests (kernel compil), it seems that prio boost is
>>> responsable of my
>>> problem. When it's disable (kernel option checked) my program run
>>> correctly.
>> Confirmed!
>>
>> root@domain.hid :/root# cat /proc/xenomai/sched
>> CPU PID PRI PERIOD TIMEOUT STAT NAME
>> 0 0 99 0 0 R ROOT
>> 0 837 99 9999312 0 X TASK1
>> 0 838 0 10999998 0 R TASK2
>>
>> So far "only" on real hardware (P-I 133) with CONFIG_M586 and (this is
>> likely also very important) CONFIG_PREEMPT. I'm now about to check if I
>> can migrate this problem into qemu and/or capture it with the I-pipe tracer.
>>
>
> Please also try moving task2 to the SCHED_FIFO class to see if things
> evolve.
No difference:
root@domain.hid :/root# cat /proc/xenomai/sched
CPU PID PRI PERIOD TIMEOUT STAT NAME
0 0 99 0 0 R ROOT
0 829 99 9999312 0 X TASK1
0 830 1 3002894 0 R TASK2
qemu over my notebook is somehow too fast to reproduce the race, I'm now
instrumenting the target.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
2006-12-03 19:59 ` Philippe Gerum
2006-12-03 20:10 ` Jan Kiszka
@ 2006-12-03 21:09 ` Jan Kiszka
2006-12-03 23:30 ` Philippe Gerum
2006-12-04 9:46 ` Gilles Chanteperdrix
1 sibling, 2 replies; 20+ messages in thread
From: Jan Kiszka @ 2006-12-03 21:09 UTC (permalink / raw)
To: rpm; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 3867 bytes --]
Philippe Gerum wrote:
> On Sun, 2006-12-03 at 20:32 +0100, Jan Kiszka wrote:
>> Nicolas BLANCHARD wrote:
>>>>>>> "Nicolas BLANCHARD" <n.blanchard@domain.hid> 29.11 11:25 >>>
>>>> Hello,
>>>>
>>>> I've tested wiith Xenomai 2.3-rc2 (adeos 1.5-02)
>>>> and change the config :
>>>> - CONFIG_M586
>>>> - disable CONFIG_INPUT_PCSPKR
>>> (it was on module)
>>>> - disable prio boosting (check
>>> CONFIG_XENO_OPT_RPDISALBLE)
>>>> and it seems to work better, one hour without blocking, it's a record
>>>> for me.
>>>>
>>>> So, i will investigate to find which modification improve my problem.
>>> After somes tests (kernel compil), it seems that prio boost is
>>> responsable of my
>>> problem. When it's disable (kernel option checked) my program run
>>> correctly.
>> Confirmed!
>>
>> root@domain.hid :/root# cat /proc/xenomai/sched
>> CPU PID PRI PERIOD TIMEOUT STAT NAME
>> 0 0 99 0 0 R ROOT
>> 0 837 99 9999312 0 X TASK1
>> 0 838 0 10999998 0 R TASK2
>>
>> So far "only" on real hardware (P-I 133) with CONFIG_M586 and (this is
>> likely also very important) CONFIG_PREEMPT. I'm now about to check if I
>> can migrate this problem into qemu and/or capture it with the I-pipe tracer.
>>
>
> Please also try moving task2 to the SCHED_FIFO class to see if things
> evolve.
>
Here is the Xenomai scheduling sequence that leads to the deadlock. I
raised the frequency of TASK2 a bit, and this seems to accelerate the
lock-up.
...
> :| *+[ 844] TASK2 1 -5061+ 4.436 xnpod_resume_thread+0x48 (gatekeeper_thread+0xf7)
> :| *+[ 827] sshd -1 -5055+ 4.015 xnpod_schedule_runnable+0x45 (gatekeeper_thread+0x12e)
> :| # [ 827] sshd -1 -5015+ 6.646 xnpod_schedule+0x81 (xnpod_schedule_handler+0x17)
> :| # [ 844] TASK2 1 -4981+ 3.721 xnpod_schedule+0x81 (xnpod_suspend_thread+0x1e4)
> :| # [ 75] gatekee -1 -4971+ 6.451 xnpod_schedule+0x7a2 (xnpod_schedule_handler+0x17)
So far everything is fine. Now the thrilling parts start:
> :| # [ 844] TASK2 1 -2992+ 9.954 xnpod_resume_thread+0x48 (xnthread_periodic_handler+0x28)
> :| # [ 75] gatekee -1 -2978! 13.759 xnpod_schedule+0x81 (xnintr_irq_handler+0xec)
> :| # [ 844] TASK2 1 -2955+ 7.842 xnpod_schedule+0x7a2 (xnpod_suspend_thread+0x1e4)
> :| # [ 843] TASK1 99 -2858+ 7.977 xnpod_resume_thread+0x48 (xnthread_periodic_handler+0x28)
> :| # [ 844] TASK2 1 -2848+ 8.466 xnpod_schedule+0x81 (xnintr_irq_handler+0xec)
> :| # [ 843] TASK1 99 -2831+ 4.421 xnpod_schedule+0x7a2 (xnpod_suspend_thread+0x1e4)
> :| # [ 843] TASK1 99 -2789+ 4.315 xnpod_schedule_runnable+0x45 (xnshadow_relax+0xd9)
> :| # [ 843] TASK1 99 -2777+ 6.932 xnpod_schedule+0x81 (xnpod_suspend_thread+0x1e4)
> :| # [ 827] sshd 99 -2762+ 4.917 xnpod_schedule+0x7a2 (xnintr_irq_handler+0xec)
The trace captured almost 200 further milliseconds, but no more
switching takes place (full dump available on request).
So we have
TASK2 resume -> TASK2 relax -> TASK1 resume/TASK2 preempted ->
TASK2 relax -> Lock-up
Gilles, are we able to produce such a sequence with the switchtest?
OK, it's time now to think a bit about what we see here. Any ideas welcome.
Jan
PS: Here are the stats you asked for, Philippe:
CPU PID MSW CSW PF STAT %CPU NAME
0 0 0 5493 0 01400080 99.1 ROOT
0 843 646 1294 0 00c00180 0.0 TASK1
0 844 2152 4337 0 00c00088 0.0 TASK2
0 0 0 689962 0 00000000 0.9 IRQ0: [timer]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
2006-12-03 21:09 ` Jan Kiszka
@ 2006-12-03 23:30 ` Philippe Gerum
2006-12-04 8:13 ` Jan Kiszka
2006-12-04 9:46 ` Gilles Chanteperdrix
1 sibling, 1 reply; 20+ messages in thread
From: Philippe Gerum @ 2006-12-03 23:30 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
On Sun, 2006-12-03 at 22:09 +0100, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Sun, 2006-12-03 at 20:32 +0100, Jan Kiszka wrote:
> >> Nicolas BLANCHARD wrote:
> >>>>>>> "Nicolas BLANCHARD" <n.blanchard@domain.hid> 29.11 11:25 >>>
> >>>> Hello,
> >>>>
> >>>> I've tested wiith Xenomai 2.3-rc2 (adeos 1.5-02)
> >>>> and change the config :
> >>>> - CONFIG_M586
> >>>> - disable CONFIG_INPUT_PCSPKR
> >>> (it was on module)
> >>>> - disable prio boosting (check
> >>> CONFIG_XENO_OPT_RPDISALBLE)
> >>>> and it seems to work better, one hour without blocking, it's a record
> >>>> for me.
> >>>>
> >>>> So, i will investigate to find which modification improve my problem.
> >>> After somes tests (kernel compil), it seems that prio boost is
> >>> responsable of my
> >>> problem. When it's disable (kernel option checked) my program run
> >>> correctly.
> >> Confirmed!
> >>
> >> root@domain.hid :/root# cat /proc/xenomai/sched
> >> CPU PID PRI PERIOD TIMEOUT STAT NAME
> >> 0 0 99 0 0 R ROOT
> >> 0 837 99 9999312 0 X TASK1
> >> 0 838 0 10999998 0 R TASK2
> >>
> >> So far "only" on real hardware (P-I 133) with CONFIG_M586 and (this is
> >> likely also very important) CONFIG_PREEMPT. I'm now about to check if I
> >> can migrate this problem into qemu and/or capture it with the I-pipe tracer.
> >>
> >
> > Please also try moving task2 to the SCHED_FIFO class to see if things
> > evolve.
> >
>
> Here is the Xenomai scheduling sequence that leads to the deadlock. I
> raised the frequency of TASK2 a bit, and this seems to accelerate the
> lock-up.
>
> ...
> > :| *+[ 844] TASK2 1 -5061+ 4.436 xnpod_resume_thread+0x48 (gatekeeper_thread+0xf7)
> > :| *+[ 827] sshd -1 -5055+ 4.015 xnpod_schedule_runnable+0x45 (gatekeeper_thread+0x12e)
Damnit. What about this?
--- ksrc/nucleus/shadow.c~ 2006-11-19 11:09:00.000000000 +0100
+++ ksrc/nucleus/shadow.c 2006-12-04 00:29:13.000000000 +0100
@@ -551,9 +551,6 @@
thread->sched = xnpod_sched_slot(cpu);
#endif /* CONFIG_SMP */
xnpod_resume_thread(thread, XNRELAX);
-#ifndef CONFIG_XENO_OPT_RPIDISABLE
- xnpod_renice_root(XNPOD_ROOT_PRIO_BASE);
-#endif /* CONFIG_XENO_OPT_RPIDISABLE */
#ifdef CONFIG_XENO_OPT_ISHIELD
disengage_irq_shield();
#endif /* CONFIG_XENO_OPT_ISHIELD */
--
Philippe.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
2006-12-03 23:30 ` Philippe Gerum
@ 2006-12-04 8:13 ` Jan Kiszka
2006-12-04 21:06 ` Jan Kiszka
0 siblings, 1 reply; 20+ messages in thread
From: Jan Kiszka @ 2006-12-04 8:13 UTC (permalink / raw)
To: rpm; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 8302 bytes --]
Philippe Gerum wrote:
> On Sun, 2006-12-03 at 22:09 +0100, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Sun, 2006-12-03 at 20:32 +0100, Jan Kiszka wrote:
>>>> Nicolas BLANCHARD wrote:
>>>>>>>>> "Nicolas BLANCHARD" <n.blanchard@domain.hid> 29.11 11:25 >>>
>>>>>> Hello,
>>>>>>
>>>>>> I've tested wiith Xenomai 2.3-rc2 (adeos 1.5-02)
>>>>>> and change the config :
>>>>>> - CONFIG_M586
>>>>>> - disable CONFIG_INPUT_PCSPKR
>>>>> (it was on module)
>>>>>> - disable prio boosting (check
>>>>> CONFIG_XENO_OPT_RPDISALBLE)
>>>>>> and it seems to work better, one hour without blocking, it's a record
>>>>>> for me.
>>>>>>
>>>>>> So, i will investigate to find which modification improve my problem.
>>>>> After somes tests (kernel compil), it seems that prio boost is
>>>>> responsable of my
>>>>> problem. When it's disable (kernel option checked) my program run
>>>>> correctly.
>>>> Confirmed!
>>>>
>>>> root@domain.hid :/root# cat /proc/xenomai/sched
>>>> CPU PID PRI PERIOD TIMEOUT STAT NAME
>>>> 0 0 99 0 0 R ROOT
>>>> 0 837 99 9999312 0 X TASK1
>>>> 0 838 0 10999998 0 R TASK2
>>>>
>>>> So far "only" on real hardware (P-I 133) with CONFIG_M586 and (this is
>>>> likely also very important) CONFIG_PREEMPT. I'm now about to check if I
>>>> can migrate this problem into qemu and/or capture it with the I-pipe tracer.
>>>>
>>> Please also try moving task2 to the SCHED_FIFO class to see if things
>>> evolve.
>>>
>> Here is the Xenomai scheduling sequence that leads to the deadlock. I
>> raised the frequency of TASK2 a bit, and this seems to accelerate the
>> lock-up.
>>
>> ...
>>> :| *+[ 844] TASK2 1 -5061+ 4.436 xnpod_resume_thread+0x48 (gatekeeper_thread+0xf7)
>>> :| *+[ 827] sshd -1 -5055+ 4.015 xnpod_schedule_runnable+0x45 (gatekeeper_thread+0x12e)
>
> Damnit. What about this?
>
> --- ksrc/nucleus/shadow.c~ 2006-11-19 11:09:00.000000000 +0100
> +++ ksrc/nucleus/shadow.c 2006-12-04 00:29:13.000000000 +0100
> @@ -551,9 +551,6 @@
> thread->sched = xnpod_sched_slot(cpu);
> #endif /* CONFIG_SMP */
> xnpod_resume_thread(thread, XNRELAX);
> -#ifndef CONFIG_XENO_OPT_RPIDISABLE
> - xnpod_renice_root(XNPOD_ROOT_PRIO_BASE);
> -#endif /* CONFIG_XENO_OPT_RPIDISABLE */
> #ifdef CONFIG_XENO_OPT_ISHIELD
> disengage_irq_shield();
> #endif /* CONFIG_XENO_OPT_ISHIELD */
>
Stalls on relaxing TASK1:
CPU PID PRI PERIOD TIMEOUT STAT NAME
0 0 99 0 0 R ROOT
0 831 99 10000000 0 R TASK1
0 832 1 11000000 0 R TASK2
My excerpt may have suggested a priority adjustment bug, but there is
non. When TASK2 is resumed, the currently running root thread still has
prio -1, all correct.
But here is the full trace of the problematic path:
> :| # [ 844] TASK2 1 -2992+ 9.954 xnpod_resume_thread+0x48 (xnthread_periodic_handler+0x28)
> :| # func -2982+ 3.368 xnpod_schedule+0xe (xnintr_irq_handler+0xec)
> :| # [ 75] gatekee -1 -2978! 13.759 xnpod_schedule+0x81 (xnintr_irq_handler+0xec)
> :| # func -2965+ 2.285 __switch_to+0xb (xnpod_schedule+0x6ce)
> :| # func -2962+ 7.879 debug_smp_processor_id+0x9 (__switch_to+0x1e)
> :| # [ 844] TASK2 1 -2955+ 7.842 xnpod_schedule+0x7a2 (xnpod_suspend_thread+0x1e4)
> :| # func -2947! 39.947 __ipipe_restore_pipeline_head+0x8 (xnpod_wait_thread_period+0x1a8)
> : + func -2907+ 2.406 __ipipe_syscall_root+0x9 (system_call+0x20)
> : + func -2904+ 2.857 __ipipe_dispatch_event+0xe (__ipipe_syscall_root+0x73)
> : + func -2902+ 4.375 hisyscall_event+0xe (__ipipe_dispatch_event+0x82)
> : + func -2897+ 2.225 xnshadow_relax+0xe (hisyscall_event+0x1ed)
> : + func -2895+ 2.330 schedule_linux_call+0xe (xnshadow_relax+0x7d)
> :| # func -2893+ 2.962 __ipipe_restore_pipeline_head+0x8 (schedule_linux_call+0xaf)
> : + func -2890+ 2.323 rthal_apc_schedule+0x8 (schedule_linux_call+0xb9)
> : + func -2887+ 3.511 __ipipe_schedule_irq+0xa (rthal_apc_schedule+0x31)
> :| + func -2884+ 2.240 __ipipe_handle_irq+0xe (common_interrupt+0x18)
> :| + func -2882+ 1.639 __ipipe_ack_common_irq+0xa (__ipipe_handle_irq+0x80)
> :| + func -2880+ 2.067 ipipe_test_and_stall_pipeline_from+0x8 (__ipipe_ack_common_irq+0x16)
> :| # func -2878+ 2.879 mask_and_ack_8259A+0xb (__ipipe_ack_common_irq+0x3e)
> :| + func -2875+ 2.812 __ipipe_dispatch_wired+0xe (__ipipe_handle_irq+0x8a)
> :| # func -2872+ 1.759 xnintr_clock_handler+0x8 (__ipipe_dispatch_wired+0x7d)
> :| # func -2870+ 1.969 xnintr_irq_handler+0xe (xnintr_clock_handler+0x17)
> :| # func -2868+ 1.864 xnpod_announce_tick+0x8 (xnintr_irq_handler+0x39)
> :| # func -2867+ 3.052 xntimer_do_tick_aperiodic+0xe (xnpod_announce_tick+0xf)
> :| # func -2863+ 2.511 xnthread_periodic_handler+0x8 (xntimer_do_tick_aperiodic+0x7b)
> :| # func -2861+ 2.789 xnpod_resume_thread+0xe (xnthread_periodic_handler+0x28)
> :| # [ 843] TASK1 99 -2858+ 7.977 xnpod_resume_thread+0x48 (xnthread_periodic_handler+0x28)
> :| # func -2850+ 2.270 xnpod_schedule+0xe (xnintr_irq_handler+0xec)
> :| # [ 844] TASK2 1 -2848+ 8.466 xnpod_schedule+0x81 (xnintr_irq_handler+0xec)
> :| # func -2839+ 1.751 __switch_to+0xb (xnpod_schedule+0x6ce)
> :| # func -2838+ 6.593 debug_smp_processor_id+0x9 (__switch_to+0x1e)
> :| # [ 843] TASK1 99 -2831+ 4.421 xnpod_schedule+0x7a2 (xnpod_suspend_thread+0x1e4)
> :| # func -2827! 17.894 __ipipe_restore_pipeline_head+0x8 (xnpod_wait_thread_period+0x1a8)
> : + func -2809+ 2.360 __ipipe_syscall_root+0x9 (system_call+0x20)
> : + func -2806+ 2.210 __ipipe_dispatch_event+0xe (__ipipe_syscall_root+0x73)
> : + func -2804+ 3.458 hisyscall_event+0xe (__ipipe_dispatch_event+0x82)
> : + func -2801+ 2.421 xnshadow_relax+0xe (hisyscall_event+0x1ed)
> : + func -2798+ 2.691 schedule_linux_call+0xe (xnshadow_relax+0x7d)
> :| # func -2796+ 1.984 __ipipe_restore_pipeline_head+0x8 (schedule_linux_call+0xaf)
> : + func -2794+ 2.631 rthal_apc_schedule+0x8 (schedule_linux_call+0xb9)
> :| # func -2791+ 2.180 xnpod_schedule_runnable+0xe (xnshadow_relax+0xd9)
> :| # [ 843] TASK1 99 -2789+ 4.315 xnpod_schedule_runnable+0x45 (xnshadow_relax+0xd9)
> :| # func -2785+ 5.593 xnpod_suspend_thread+0xe (xnshadow_relax+0x104)
> :| # func -2779+ 2.045 xnpod_schedule+0xe (xnpod_suspend_thread+0x1e4)
> :| # [ 843] TASK1 99 -2777+ 6.932 xnpod_schedule+0x81 (xnpod_suspend_thread+0x1e4)
> :| # func -2770+ 2.368 __switch_to+0xb (xnpod_schedule+0x6ce)
> :| # func -2768+ 5.736 debug_smp_processor_id+0x9 (__switch_to+0x1e)
> :| # [ 827] sshd 99 -2762+ 4.917 xnpod_schedule+0x7a2 (xnintr_irq_handler+0xec)
> :| +func -2757+ 3.744 __ipipe_walk_pipeline+0xe (__ipipe_handle_irq+0x182)
> :| +func -2753+ 2.135 __ipipe_unstall_iret_root+0x8 (restore_raw+0x0)
> : +func -2751+ 2.360 tcp_cong_avoid+0xa (tcp_ack+0x14d3)
> : +func -2749+ 5.909 bictcp_cong_avoid+0xb (tcp_cong_avoid+0x1b)
> : +func -2743+ 2.496 __kfree_skb+0xa (tcp_rcv_established+0x109)
This indicates that we face an I-pipe bug: the scheduled Linux call on
relaxation of TASK2 and then later TASK1 somehow gets lost (there is no
rthal_apc_handler in the remaining trace).
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
2006-12-04 8:13 ` Jan Kiszka
@ 2006-12-04 21:06 ` Jan Kiszka
2006-12-05 22:17 ` Philippe Gerum
2006-12-05 22:18 ` Philippe Gerum
0 siblings, 2 replies; 20+ messages in thread
From: Jan Kiszka @ 2006-12-04 21:06 UTC (permalink / raw)
To: rpm; +Cc: xenomai
[-- Attachment #1.1: Type: text/plain, Size: 1376 bytes --]
Jan Kiszka wrote:
> ...
> This indicates that we face an I-pipe bug: the scheduled Linux call on
> relaxation of TASK2 and then later TASK1 somehow gets lost (there is no
> rthal_apc_handler in the remaining trace).
I think I got it. No I-pipe bug, but one in the HAL.
What happened? A weird race caused by the unprotected optimisation to
only call rthal_schedule_irq() if there is no APC pending yet. This is
the constellation I finally worked out via instrumenting and tracing:
PRIO 1:
rthal_apc_schedule()
test&set rthal_apc_pending
(but no rthal_schedule_irq() yet)
-PREEMPTION-
PRIO 99:
...
rthal_apc_schedule()
test rthal_apc_pending
(already set => no
rthal_schedule_irq()!)
So, no one reported the ACP to I-pipe, and no one ever will in Nicolas
scenario - soft lock-up!
Nicolas, please give the attached patch a try. Your test is running fine
for me now.
At this chance: do we need rthal_apc_schedule() returning the previous
state at all? No current caller checks the return value. If it's OK to
clean this up, I will post a combined patch.
Jan
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: fix-rthal_apc_schedule.patch --]
[-- Type: text/x-patch; name="fix-rthal_apc_schedule.patch", Size: 885 bytes --]
Index: ksrc/arch/generic/hal.c
===================================================================
--- ksrc/arch/generic/hal.c (Revision 1918)
+++ ksrc/arch/generic/hal.c (Arbeitskopie)
@@ -596,18 +596,19 @@ int rthal_apc_free(int apc)
int rthal_apc_schedule(int apc)
{
rthal_declare_cpuid;
+ int ret = 1;
if (apc < 0 || apc >= RTHAL_NR_APCS)
return -EINVAL;
rthal_load_cpuid(); /* Migration would be harmless here. */
- if (!test_and_set_bit(apc, &rthal_apc_pending[cpuid])) {
- rthal_schedule_irq(rthal_apc_virq);
- return 1;
- }
+ if (test_and_set_bit(apc, &rthal_apc_pending[cpuid]))
+ ret = 0; /* Already pending. */
+
+ rthal_schedule_irq(rthal_apc_virq);
- return 0; /* Already pending. */
+ return ret;
}
#ifdef CONFIG_PROC_FS
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
2006-12-04 21:06 ` Jan Kiszka
@ 2006-12-05 22:17 ` Philippe Gerum
2006-12-06 8:37 ` Jan Kiszka
2006-12-05 22:18 ` Philippe Gerum
1 sibling, 1 reply; 20+ messages in thread
From: Philippe Gerum @ 2006-12-05 22:17 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
On Mon, 2006-12-04 at 22:06 +0100, Jan Kiszka wrote:
> Jan Kiszka wrote:
> > ...
> > This indicates that we face an I-pipe bug: the scheduled Linux call on
> > relaxation of TASK2 and then later TASK1 somehow gets lost (there is no
> > rthal_apc_handler in the remaining trace).
>
> I think I got it. No I-pipe bug, but one in the HAL.
>
> What happened? A weird race caused by the unprotected optimisation to
> only call rthal_schedule_irq() if there is no APC pending yet. This is
> the constellation I finally worked out via instrumenting and tracing:
>
> PRIO 1:
> rthal_apc_schedule()
> test&set rthal_apc_pending
> (but no rthal_schedule_irq() yet)
>
> -PREEMPTION-
>
> PRIO 99:
> ...
> rthal_apc_schedule()
> test rthal_apc_pending
> (already set => no
> rthal_schedule_irq()!)
>
> So, no one reported the ACP to I-pipe, and no one ever will in Nicolas
> scenario - soft lock-up!
>
> Nicolas, please give the attached patch a try. Your test is running fine
> for me now.
>
>
> At this chance: do we need rthal_apc_schedule() returning the previous
> state at all? No current caller checks the return value. If it's OK to
> clean this up, I will post a combined patch.
It's pointless to return this info, the caller would not be able to
exploit it in any way.
Could you please try this other form of your fix? This would prevent the
virq to be fired twice (or more) uselessly, with no request pending.
Masking interrupts to enforce atomicity is ok here, since
rthal_schedule_irq() will run this way in any case. Additionally, my
comment about migration was suspicious, I do see a case where CPU
migration would leave this code in limbos. But to get the cpuid
properly, we need the local interrupts to be masked first. TIA,
--- arch/generic/hal.c (revision 1919)
+++ arch/generic/hal.c (working copy)
@@ -596,18 +596,24 @@
int rthal_apc_schedule(int apc)
{
rthal_declare_cpuid;
+ unsigned long flags;
+ int ret = 0;
if (apc < 0 || apc >= RTHAL_NR_APCS)
- return -EINVAL;
+ return -EINVAL;
- rthal_load_cpuid(); /* Migration would be harmless here. */
+ rthal_local_irq_save(flags);
- if (!test_and_set_bit(apc, &rthal_apc_pending[cpuid])) {
- rthal_schedule_irq(rthal_apc_virq);
- return 1;
- }
+ rthal_load_cpuid();
- return 0; /* Already pending. */
+ if (__test_and_set_bit(apc, &rthal_apc_pending[cpuid]))
+ ret = 1;
+ else
+ rthal_schedule_irq(rthal_apc_virq);
+
+ rthal_local_irq_restore(flags);
+
+ return ret;
}
#ifdef CONFIG_PROC_FS
--
Philippe.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
2006-12-05 22:17 ` Philippe Gerum
@ 2006-12-06 8:37 ` Jan Kiszka
2006-12-06 9:06 ` Philippe Gerum
0 siblings, 1 reply; 20+ messages in thread
From: Jan Kiszka @ 2006-12-06 8:37 UTC (permalink / raw)
To: rpm; +Cc: xenomai
[-- Attachment #1.1: Type: text/plain, Size: 2204 bytes --]
Philippe Gerum wrote:
> On Mon, 2006-12-04 at 22:06 +0100, Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>> ...
>>> This indicates that we face an I-pipe bug: the scheduled Linux call on
>>> relaxation of TASK2 and then later TASK1 somehow gets lost (there is no
>>> rthal_apc_handler in the remaining trace).
>> I think I got it. No I-pipe bug, but one in the HAL.
>>
>> What happened? A weird race caused by the unprotected optimisation to
>> only call rthal_schedule_irq() if there is no APC pending yet. This is
>> the constellation I finally worked out via instrumenting and tracing:
>>
>> PRIO 1:
>> rthal_apc_schedule()
>> test&set rthal_apc_pending
>> (but no rthal_schedule_irq() yet)
>>
>> -PREEMPTION-
>>
>> PRIO 99:
>> ...
>> rthal_apc_schedule()
>> test rthal_apc_pending
>> (already set => no
>> rthal_schedule_irq()!)
>>
>> So, no one reported the ACP to I-pipe, and no one ever will in Nicolas
>> scenario - soft lock-up!
>>
>> Nicolas, please give the attached patch a try. Your test is running fine
>> for me now.
>>
>>
>> At this chance: do we need rthal_apc_schedule() returning the previous
>> state at all? No current caller checks the return value. If it's OK to
>> clean this up, I will post a combined patch.
>
> It's pointless to return this info, the caller would not be able to
> exploit it in any way.
>
> Could you please try this other form of your fix? This would prevent the
> virq to be fired twice (or more) uselessly, with no request pending.
> Masking interrupts to enforce atomicity is ok here, since
> rthal_schedule_irq() will run this way in any case. Additionally, my
> comment about migration was suspicious, I do see a case where CPU
> migration would leave this code in limbos. But to get the cpuid
> properly, we need the local interrupts to be masked first. TIA,
Yes, works fine as well.
Then go for the attached fix+cleanup?
Jan
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: fix-rthal_apc_schedule-v2.patch --]
[-- Type: text/x-patch; name="fix-rthal_apc_schedule-v2.patch", Size: 1479 bytes --]
Index: ksrc/arch/generic/hal.c
===================================================================
--- ksrc/arch/generic/hal.c (Revision 1920)
+++ ksrc/arch/generic/hal.c (Arbeitskopie)
@@ -565,7 +565,7 @@ int rthal_apc_free(int apc)
/**
* @fn int rthal_apc_schedule (int apc)
- *
+ *
* @brief Schedule an APC invocation.
*
* This service marks the APC as pending for the Linux domain, so that
@@ -580,8 +580,7 @@ int rthal_apc_free(int apc)
*
* @param apc The APC id. to schedule.
*
- * @return 0 or 1 are returned upon success, the former meaning that
- * the APC was already pending. Otherwise:
+ * @return 0 is returned upon success. Otherwise:
*
* - -EINVAL is returned if @a apc is invalid.
*
@@ -596,18 +595,21 @@ int rthal_apc_free(int apc)
int rthal_apc_schedule(int apc)
{
rthal_declare_cpuid;
+ unsigned long flags;
if (apc < 0 || apc >= RTHAL_NR_APCS)
return -EINVAL;
- rthal_load_cpuid(); /* Migration would be harmless here. */
+ rthal_local_irq_save(flags);
+
+ rthal_load_cpuid();
- if (!test_and_set_bit(apc, &rthal_apc_pending[cpuid])) {
+ if (!__test_and_set_bit(apc, &rthal_apc_pending[cpuid]))
rthal_schedule_irq(rthal_apc_virq);
- return 1;
- }
- return 0; /* Already pending. */
+ rthal_local_irq_restore(flags);
+
+ return 0;
}
#ifdef CONFIG_PROC_FS
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
2006-12-04 21:06 ` Jan Kiszka
2006-12-05 22:17 ` Philippe Gerum
@ 2006-12-05 22:18 ` Philippe Gerum
1 sibling, 0 replies; 20+ messages in thread
From: Philippe Gerum @ 2006-12-05 22:18 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
On Mon, 2006-12-04 at 22:06 +0100, Jan Kiszka wrote:
> Jan Kiszka wrote:
> > ...
> > This indicates that we face an I-pipe bug: the scheduled Linux call on
> > relaxation of TASK2 and then later TASK1 somehow gets lost (there is no
> > rthal_apc_handler in the remaining trace).
>
> I think I got it. No I-pipe bug, but one in the HAL.
>
> What happened? A weird race caused by the unprotected optimisation to
> only call rthal_schedule_irq() if there is no APC pending yet. This is
> the constellation I finally worked out via instrumenting and tracing:
>
Btw, really nice spot. This one was really bad to the bone. Thanks.
--
Philippe.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
2006-12-03 21:09 ` Jan Kiszka
2006-12-03 23:30 ` Philippe Gerum
@ 2006-12-04 9:46 ` Gilles Chanteperdrix
1 sibling, 0 replies; 20+ messages in thread
From: Gilles Chanteperdrix @ 2006-12-04 9:46 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
Jan Kiszka wrote:
> Philippe Gerum wrote:
>
>>On Sun, 2006-12-03 at 20:32 +0100, Jan Kiszka wrote:
>>
>>>Nicolas BLANCHARD wrote:
>>>
>>>>>>>>"Nicolas BLANCHARD" <n.blanchard@domain.hid> 29.11 11:25 >>>
>>>>>
>>>>>Hello,
>>>>>
>>>>>I've tested wiith Xenomai 2.3-rc2 (adeos 1.5-02)
>>>>>and change the config :
>>>>> - CONFIG_M586
>>>>> - disable CONFIG_INPUT_PCSPKR
>>>>
>>>>(it was on module)
>>>>
>>>>> - disable prio boosting (check
>>>>
>>>>CONFIG_XENO_OPT_RPDISALBLE)
>>>>
>>>>>and it seems to work better, one hour without blocking, it's a record
>>>>>for me.
>>>>>
>>>>>So, i will investigate to find which modification improve my problem.
>>>>
>>>>After somes tests (kernel compil), it seems that prio boost is
>>>>responsable of my
>>>>problem. When it's disable (kernel option checked) my program run
>>>>correctly.
>>>
>>>Confirmed!
>>>
>>>root@domain.hid :/root# cat /proc/xenomai/sched
>>>CPU PID PRI PERIOD TIMEOUT STAT NAME
>>> 0 0 99 0 0 R ROOT
>>> 0 837 99 9999312 0 X TASK1
>>> 0 838 0 10999998 0 R TASK2
>>>
>>>So far "only" on real hardware (P-I 133) with CONFIG_M586 and (this is
>>>likely also very important) CONFIG_PREEMPT. I'm now about to check if I
>>>can migrate this problem into qemu and/or capture it with the I-pipe tracer.
>>>
>>
>>Please also try moving task2 to the SCHED_FIFO class to see if things
>>evolve.
>>
>
>
> Here is the Xenomai scheduling sequence that leads to the deadlock. I
> raised the frequency of TASK2 a bit, and this seems to accelerate the
> lock-up.
>
> ...
>
>>:| *+[ 844] TASK2 1 -5061+ 4.436 xnpod_resume_thread+0x48 (gatekeeper_thread+0xf7)
>>:| *+[ 827] sshd -1 -5055+ 4.015 xnpod_schedule_runnable+0x45 (gatekeeper_thread+0x12e)
>>:| # [ 827] sshd -1 -5015+ 6.646 xnpod_schedule+0x81 (xnpod_schedule_handler+0x17)
>>:| # [ 844] TASK2 1 -4981+ 3.721 xnpod_schedule+0x81 (xnpod_suspend_thread+0x1e4)
>>:| # [ 75] gatekee -1 -4971+ 6.451 xnpod_schedule+0x7a2 (xnpod_schedule_handler+0x17)
>
>
> So far everything is fine. Now the thrilling parts start:
>
>
>>:| # [ 844] TASK2 1 -2992+ 9.954 xnpod_resume_thread+0x48 (xnthread_periodic_handler+0x28)
>>:| # [ 75] gatekee -1 -2978! 13.759 xnpod_schedule+0x81 (xnintr_irq_handler+0xec)
>>:| # [ 844] TASK2 1 -2955+ 7.842 xnpod_schedule+0x7a2 (xnpod_suspend_thread+0x1e4)
>>:| # [ 843] TASK1 99 -2858+ 7.977 xnpod_resume_thread+0x48 (xnthread_periodic_handler+0x28)
>>:| # [ 844] TASK2 1 -2848+ 8.466 xnpod_schedule+0x81 (xnintr_irq_handler+0xec)
>>:| # [ 843] TASK1 99 -2831+ 4.421 xnpod_schedule+0x7a2 (xnpod_suspend_thread+0x1e4)
>>:| # [ 843] TASK1 99 -2789+ 4.315 xnpod_schedule_runnable+0x45 (xnshadow_relax+0xd9)
>>:| # [ 843] TASK1 99 -2777+ 6.932 xnpod_schedule+0x81 (xnpod_suspend_thread+0x1e4)
>>:| # [ 827] sshd 99 -2762+ 4.917 xnpod_schedule+0x7a2 (xnintr_irq_handler+0xec)
>
>
> The trace captured almost 200 further milliseconds, but no more
> switching takes place (full dump available on request).
>
> So we have
>
> TASK2 resume -> TASK2 relax -> TASK1 resume/TASK2 preempted ->
> TASK2 relax -> Lock-up
>
> Gilles, are we able to produce such a sequence with the switchtest?
Probably not, with switchtest, only the task that is currently switching
is running, all other tasks are suspended.
--
Gilles Chanteperdrix
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
2006-12-03 19:32 ` Jan Kiszka
2006-12-03 19:59 ` Philippe Gerum
@ 2006-12-03 21:02 ` Philippe Gerum
1 sibling, 0 replies; 20+ messages in thread
From: Philippe Gerum @ 2006-12-03 21:02 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
On Sun, 2006-12-03 at 20:32 +0100, Jan Kiszka wrote:
> Nicolas BLANCHARD wrote:
> >>>>> "Nicolas BLANCHARD" <n.blanchard@domain.hid> 29.11 11:25 >>>
> >> Hello,
> >>
> >> I've tested wiith Xenomai 2.3-rc2 (adeos 1.5-02)
> >> and change the config :
> >> - CONFIG_M586
> >> - disable CONFIG_INPUT_PCSPKR
> > (it was on module)
> >> - disable prio boosting (check
> > CONFIG_XENO_OPT_RPDISALBLE)
> >> and it seems to work better, one hour without blocking, it's a record
> >> for me.
> >>
> >> So, i will investigate to find which modification improve my problem.
> >
> > After somes tests (kernel compil), it seems that prio boost is
> > responsable of my
> > problem. When it's disable (kernel option checked) my program run
> > correctly.
>
> Confirmed!
>
> root@domain.hid :/root# cat /proc/xenomai/sched
> CPU PID PRI PERIOD TIMEOUT STAT NAME
> 0 0 99 0 0 R ROOT
> 0 837 99 9999312 0 X TASK1
> 0 838 0 10999998 0 R TASK2
>
> So far "only" on real hardware (P-I 133) with CONFIG_M586 and (this is
> likely also very important) CONFIG_PREEMPT. I'm now about to check if I
> can migrate this problem into qemu and/or capture it with the I-pipe tracer.
>
I did not jump on that initially, but if task2 is supposedly in ready
state, then there must be a rescheduling missing somewhere, maybe task2
trying to migrate to primary mode, and for some reason, no rescheduling
took place on behalf of the gatekeeper. It would be interesting to know
the output of /proc/xenomai/stat, to get the full task states.
> Jan
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <s575af89.064@domain.hid>]
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
[not found] <s575af89.064@domain.hid>
@ 2006-12-05 17:15 ` Jan Kiszka
0 siblings, 0 replies; 20+ messages in thread
From: Jan Kiszka @ 2006-12-05 17:15 UTC (permalink / raw)
To: Nicolas BLANCHARD; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 3539 bytes --]
Nicolas BLANCHARD wrote:
> hello Jan,
>
>>>>> Jan Kiszka <jan.kiszka@domain.hid> 04.12 22:06 >>>
>> Jan Kiszka wrote:
>>> ...
>>> This indicates that we face an I-pipe bug: the scheduled Linux call
> on
>>> relaxation of TASK2 and then later TASK1 somehow gets lost (there is
> no
>>> rthal_apc_handler in the remaining trace).
>> I think I got it. No I-pipe bug, but one in the HAL.
>>
>> What happened? A weird race caused by the unprotected optimisation to
>> only call rthal_schedule_irq() if there is no APC pending yet. This
> is
>> the constellation I finally worked out via instrumenting and tracing:
>>
>> PRIO 1:
>> rthal_apc_schedule()
>> test&set rthal_apc_pending
>> (but no rthal_schedule_irq() yet)
>>
>> -PREEMPTION-
>>
>> PRIO 99:
>> ...
>> rthal_apc_schedule()
>> test rthal_apc_pending
>> (already set => no
>> rthal_schedule_irq()!)
>>
>> So, no one reported the ACP to I-pipe, and no one ever will in
> Nicolas
>> scenario - soft lock-up!
>>
>> Nicolas, please give the attached patch a try. Your test is running
> fine
>> for me now.
>
> I've applied your patch and it seems to run correctly ...
> congratulation.
> I've read you discussion about this problem with Gilles, but I've don't
> really
> understand how you have solved the problem (and what was exactly the
> problem).
> If you have time to explain, i'm interested ...
That's a fairly long story to explain. Trying to make it short: The
essence is that your low prio thread was about to signal some soft-IRQ
to Linux on its way from primary to secondary mode. Right after storing
internally that this IRQ was sent but before actually sending it, it got
preempted by the high prio thread. That one tried the same, i.e. migrate
to secondary mode, but didn't sent out that soft-IRQ as it was already
marked as pending. Still, Linux was entered (with priority 99 of the
high prio thread), but not with any of the jobs the Xenomai threads
wanted to be worked on...
How I debugged this? You don't want to know. ;)
(It's a combination of understanding the code details + instrumenting it
via appropriate tools like the Ipipe tracer to produce a backlog of what
happened.)
>
>>
>> At this chance: do we need rthal_apc_schedule() returning the
> previous
>> state at all? No current caller checks the return value. If it's OK
> to
>> clean this up, I will post a combined patch.
>>
>> Jan
>
> An other things with switch mode, sometime i lose my i/o privilege put
> with the
> system call ioperm (in the main function of my program).
Sigh.
> My application stop with a "killed" message in the console and
> in /proc/xenomai/fault i've an "general fault".
> To ignore this problem, i use the call system iopl (with full
> privilege) or
> recall ioperm before each inb or outb.
> But there is a problem, why i/o privilege are losted ?
> I've read an similar problem in an archive of Rtai/fusion help
> mailing-list ...
> If you have an idea.
I'm not up-to-date /wrt ioperm usability. I also only vaguely recall
some older issues. Unless someone now screams "This cannot work, use
iopl!", I would suggest to create yet another nice test-case like the
last one and post it in a new thread.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
@ 2006-12-05 12:33 Nicolas BLANCHARD
0 siblings, 0 replies; 20+ messages in thread
From: Nicolas BLANCHARD @ 2006-12-05 12:33 UTC (permalink / raw)
To: jan.kiszka, rpm; +Cc: xenomai
hello Jan,
>>>> Jan Kiszka <jan.kiszka@domain.hid> 04.12 22:06 >>>
>Jan Kiszka wrote:
>> ...
>> This indicates that we face an I-pipe bug: the scheduled Linux call
on
>> relaxation of TASK2 and then later TASK1 somehow gets lost (there is
no
>> rthal_apc_handler in the remaining trace).
>
>I think I got it. No I-pipe bug, but one in the HAL.
>
>What happened? A weird race caused by the unprotected optimisation to
>only call rthal_schedule_irq() if there is no APC pending yet. This
is
>the constellation I finally worked out via instrumenting and tracing:
>
>PRIO 1:
>rthal_apc_schedule()
> test&set rthal_apc_pending
> (but no rthal_schedule_irq() yet)
>
> -PREEMPTION-
>
> PRIO 99:
> ...
> rthal_apc_schedule()
> test rthal_apc_pending
> (already set => no
> rthal_schedule_irq()!)
>
>So, no one reported the ACP to I-pipe, and no one ever will in
Nicolas
>scenario - soft lock-up!
>
>Nicolas, please give the attached patch a try. Your test is running
fine
>for me now.
I've applied your patch and it seems to run correctly ...
congratulation.
I've read you discussion about this problem with Gilles, but I've don't
really
understand how you have solved the problem (and what was exactly the
problem).
If you have time to explain, i'm interested ...
>
>
>At this chance: do we need rthal_apc_schedule() returning the
previous
>state at all? No current caller checks the return value. If it's OK
to
>clean this up, I will post a combined patch.
>
>Jan
An other things with switch mode, sometime i lose my i/o privilege put
with the
system call ioperm (in the main function of my program).
My application stop with a "killed" message in the console and
in /proc/xenomai/fault i've an "general fault".
To ignore this problem, i use the call system iopl (with full
privilege) or
recall ioperm before each inb or outb.
But there is a problem, why i/o privilege are losted ?
I've read an similar problem in an archive of Rtai/fusion help
mailing-list ...
If you have an idea.
thanks
nicolas blanchard
^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <s56d88c0.000@domain.hid>]
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
[not found] <s56d88c0.000@domain.hid>
@ 2006-11-29 13:52 ` Jan Kiszka
0 siblings, 0 replies; 20+ messages in thread
From: Jan Kiszka @ 2006-11-29 13:52 UTC (permalink / raw)
To: Nicolas BLANCHARD; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]
Nicolas BLANCHARD wrote:
>>>>> "Nicolas BLANCHARD" <n.blanchard@domain.hid> 29.11 11:25 >>>
>> Hello,
>>
>> I've tested wiith Xenomai 2.3-rc2 (adeos 1.5-02)
>> and change the config :
>> - CONFIG_M586
>> - disable CONFIG_INPUT_PCSPKR
> (it was on module)
>> - disable prio boosting (check
> CONFIG_XENO_OPT_RPDISALBLE)
>> and it seems to work better, one hour without blocking, it's a record
>> for me.
>>
>> So, i will investigate to find which modification improve my problem.
>
> After somes tests (kernel compil), it seems that prio boost is
> responsable of my
> problem. When it's disable (kernel option checked) my program run
> correctly.
Yeah, that's what I assumed now as well. Full output of
/proc/xenomai/sched would be interesting now.
>
> I'm not sure to understand how the prio boost work.
> Can someone explain ?
Any Linux service, including those requested by Xenomai threads in
secondary mode, runs over the root thread. The root thread normally runs
at priority -1, i.e. below all Xenomai tasks. When
CONFIG_XENO_OPT_RPDISALBLE is *not* set and a Xenomai thread switches to
secondary mode, Xenomai raises the root thread's prio to the level of
that thread. This boosts Linux temporarily above any lower priority RT
thread, aiming at accelerating the completion of the requested Linux
service. If you do not depend on such boosting for your system design,
switching the service off improves the mode switch performance (and
obviously avoids a bug here we have to fix nevertheless).
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
@ 2006-11-29 10:25 Nicolas BLANCHARD
0 siblings, 0 replies; 20+ messages in thread
From: Nicolas BLANCHARD @ 2006-11-29 10:25 UTC (permalink / raw)
To: xenomai, jan.kiszka
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]
Hello,
I've tested wiith Xenomai 2.3-rc2 (adeos 1.5-02)
and change the config :
- CONFIG_M586
- disable CONFIG_INPUT_PCSPKR
(it was on module)
- disable prio boosting (check
CONFIG_XENO_OPT_RPDISALBLE)
and it seems to work better, one hour without blocking, it's a record
for me.
So, i will investigate to find which modification improve my problem.
Perhaps it's the xenomai 2.3-rc2,this version correct a problem with
the FPU
(x86: Handle issues raised by hidden uses of the FPU from regular Linux
drivers).
For remenber my problem was that sometime task wich switch to secondary
mode remain block
in secondary mode.
My test is base on 2 tasks with differents priority, and they just make
a switch to secondary
mode before returns to primary mode with the wait_period.
I've no crash, no fault, gdb don't give information, but the
/proc/xenomai/stat show that task
with the highest priority is block (stat X) and the other task is with
stat R.
(in /proc/xenomai/sched period is always on zero for both task).
Task are block in less than 2 minutes (less than 10 000 switch mode
with 10 ms periodic tasks).
If thoses two task have the same priority nothing happens, program run
correctly.
In my original program (10 tasks) tasks which don't switch to secondary
mode are always
alive and not blocked.
If you have an explanation ...
thanks
nicolas blanchard
PS : see in attachment original .config and archive containing test
program and sources.
[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 33238 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.17.13
# Mon Nov 27 10:53:28 2006
#
CONFIG_X86_32=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_UID16=y
CONFIG_VM86=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
#
# Block layer
#
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
#
# Real-time sub-system
#
CONFIG_XENOMAI=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
# CONFIG_XENO_OPT_ISHIELD is not set
# CONFIG_XENO_OPT_RPIDISABLE is not set
CONFIG_XENO_OPT_SECURITY_ACCESS=y
CONFIG_XENO_OPT_PIPELINE_HEAD=y
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY=y
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=128
CONFIG_XENO_OPT_STATS=y
# CONFIG_XENO_OPT_DEBUG is not set
CONFIG_XENO_OPT_WATCHDOG=y
#
# Timing
#
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_PERIOD=0
CONFIG_XENO_OPT_TIMING_TIMERLAT=0
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
#
# Scalability
#
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
#
# Shared interrupts
#
CONFIG_XENO_OPT_SHIRQ_LEVEL=y
CONFIG_XENO_OPT_SHIRQ_EDGE=y
#
# Machine
#
CONFIG_XENO_HW_FPU=y
#
# NMI watchdog
#
#
# SMI workaround
#
# CONFIG_XENO_HW_SMI_DETECT_DISABLE is not set
CONFIG_XENO_HW_SMI_DETECT=y
CONFIG_XENO_HW_SMI_WORKAROUND=y
CONFIG_XENO_HW_SMI_ALL=y
#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
CONFIG_XENO_OPT_NATIVE_REGISTRY=y
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_SKIN_POSIX=y
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
#
# RTAI emulator unavailable, disable native API or build it as module
#
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_FILDES=128
# CONFIG_XENO_SKIN_UVM is not set
#
# Drivers
#
CONFIG_XENO_DRIVERS_16550A=m
CONFIG_XENO_DRIVERS_TIMERBENCH=y
CONFIG_XENO_DRIVERS_IRQBENCH=y
CONFIG_XENO_DRIVERS_SWITCHTEST=y
#
# Processor type and features
#
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
CONFIG_M486=y
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_F00F_BUG=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_INTEL_USERCOPY=y
# CONFIG_HPET_TIMER is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_IPIPE=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_REGPARM=y
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_KEXEC is not set
CONFIG_PHYSICAL_START=0x100000
#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set
#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCIEPORTBUS=y
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_MULTIPATH_CACHED=y
CONFIG_IP_ROUTE_MULTIPATH_RR=m
CONFIG_IP_ROUTE_MULTIPATH_RANDOM=m
CONFIG_IP_ROUTE_MULTIPATH_WRANDOM=m
CONFIG_IP_ROUTE_MULTIPATH_DRR=m
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
#
# IP: Virtual Server Configuration
#
CONFIG_IP_VS=m
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12
#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
# CONFIG_NETFILTER_XTABLES is not set
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
CONFIG_IP_NF_CONNTRACK_NETLINK=m
CONFIG_IP_NF_CT_PROTO_SCTP=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_NETBIOS_NS=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_PPTP=m
# CONFIG_IP_NF_H323 is not set
CONFIG_IP_NF_QUEUE=m
#
# Bridge: Netfilter Configuration
#
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_ULOG=m
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
CONFIG_ATM=y
CONFIG_ATM_CLIP=y
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
CONFIG_ATM_MPOA=m
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
# CONFIG_DECNET is not set
CONFIG_LLC=m
CONFIG_LLC2=m
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_HAMRADIO=y
#
# Packet Radio protocols
#
CONFIG_AX25=m
# CONFIG_AX25_DAMA_SLAVE is not set
CONFIG_NETROM=m
CONFIG_ROSE=m
#
# AX.25 network device drivers
#
CONFIG_MKISS=m
CONFIG_6PACK=m
CONFIG_BPQETHER=m
CONFIG_BAYCOM_SER_FDX=m
CONFIG_BAYCOM_SER_HDX=m
CONFIG_YAM=m
CONFIG_IRDA=m
#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
CONFIG_IRDA_ULTRA=y
#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
CONFIG_IRDA_DEBUG=y
#
# Infrared-port device drivers
#
#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m
#
# Dongle support
#
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
# CONFIG_TOIM3232_DONGLE is not set
CONFIG_LITELINK_DONGLE=m
CONFIG_MA600_DONGLE=m
CONFIG_GIRBIL_DONGLE=m
CONFIG_MCP2120_DONGLE=m
CONFIG_OLD_BELKIN_DONGLE=m
CONFIG_ACT200L_DONGLE=m
#
# Old SIR device drivers
#
CONFIG_IRPORT_SIR=m
#
# Old Serial dongle support
#
# CONFIG_DONGLE_OLD is not set
#
# FIR device drivers
#
CONFIG_USB_IRDA=m
CONFIG_SIGMATEL_FIR=m
CONFIG_NSC_FIR=m
CONFIG_WINBOND_FIR=m
CONFIG_TOSHIBA_FIR=m
CONFIG_SMC_IRCC_FIR=m
CONFIG_ALI_FIR=m
CONFIG_VLSI_FIR=m
CONFIG_VIA_FIR=m
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=m
#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIVHCI=m
CONFIG_IEEE80211=m
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=m
CONFIG_IEEE80211_CRYPT_CCMP=m
CONFIG_IEEE80211_SOFTMAC=m
# CONFIG_IEEE80211_SOFTMAC_DEBUG is not set
CONFIG_WIRELESS_EXT=y
#
# Device Drivers
#
#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play support
#
#
# Block devices
#
CONFIG_BLK_DEV_FD=m
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_SX8=m
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=65536
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=y
# CONFIG_IDE_TASK_IOCTL is not set
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_IDEPCI_SHARE_IRQ is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
CONFIG_BLK_DEV_SIS5513=y
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
#
# SCSI Transport Attributes
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
CONFIG_SCSI_SATA=y
# CONFIG_SCSI_SATA_AHCI is not set
# CONFIG_SCSI_SATA_SVW is not set
# CONFIG_SCSI_ATA_PIIX is not set
# CONFIG_SCSI_SATA_MV is not set
# CONFIG_SCSI_SATA_NV is not set
# CONFIG_SCSI_PDC_ADMA is not set
# CONFIG_SCSI_SATA_QSTOR is not set
# CONFIG_SCSI_SATA_PROMISE is not set
# CONFIG_SCSI_SATA_SX4 is not set
# CONFIG_SCSI_SATA_SIL is not set
# CONFIG_SCSI_SATA_SIL24 is not set
CONFIG_SCSI_SATA_SIS=y
# CONFIG_SCSI_SATA_ULI is not set
# CONFIG_SCSI_SATA_VIA is not set
# CONFIG_SCSI_SATA_VITESSE is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# PHY device support
#
# CONFIG_PHYLIB is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
# CONFIG_TYPHOON is not set
#
# Tulip family network device support
#
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
# CONFIG_TULIP_MMIO is not set
# CONFIG_TULIP_NAPI is not set
CONFIG_DE4X5=m
CONFIG_WINBOND_840=m
CONFIG_DM9102=m
CONFIG_ULI526X=m
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
CONFIG_8139TOO=y
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
# CONFIG_SUNDANCE_MMIO is not set
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
# CONFIG_VIA_RHINE_MMIO is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
#
# ATM drivers
#
# CONFIG_ATM_DUMMY is not set
# CONFIG_ATM_TCP is not set
# CONFIG_ATM_LANAI is not set
# CONFIG_ATM_ENI is not set
# CONFIG_ATM_FIRESTREAM is not set
# CONFIG_ATM_ZATM is not set
# CONFIG_ATM_NICSTAR is not set
# CONFIG_ATM_IDT77252 is not set
# CONFIG_ATM_AMBASSADOR is not set
# CONFIG_ATM_HORIZON is not set
# CONFIG_ATM_IA is not set
# CONFIG_ATM_FORE200E_MAYBE is not set
# CONFIG_ATM_HE is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=y
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=m
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_UINPUT is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
CONFIG_SERIO_CT82C710=m
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=48
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
CONFIG_AGP_ALI=m
CONFIG_AGP_ATI=m
CONFIG_AGP_AMD=m
CONFIG_AGP_AMD64=m
CONFIG_AGP_INTEL=m
CONFIG_AGP_NVIDIA=m
CONFIG_AGP_SIS=m
CONFIG_AGP_SWORKS=m
CONFIG_AGP_VIA=m
CONFIG_AGP_EFFICEON=m
# CONFIG_DRM is not set
CONFIG_MWAVE=m
# CONFIG_CS5535_GPIO is not set
CONFIG_RAW_DRIVER=m
CONFIG_MAX_RAW_DEVS=256
CONFIG_HANGCHECK_TIMER=m
#
# TPM devices
#
# CONFIG_TCG_TPM is not set
CONFIG_TELCLOCK=m
#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m
#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
CONFIG_SCx200_ACB=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
CONFIG_I2C_STUB=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
CONFIG_I2C_PCA_ISA=m
#
# Miscellaneous I2C Chip support
#
CONFIG_SENSORS_DS1337=m
CONFIG_SENSORS_DS1374=m
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCA9539=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_MAX6875=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set
#
# Misc devices
#
# CONFIG_IBM_ASM is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
CONFIG_VIDEO_V4L2=y
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
# CONFIG_USB_DABUSB is not set
#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
#
# USB HID Boot Protocol drivers
#
CONFIG_USB_KBD=m
CONFIG_USB_MOUSE=m
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_TOUCHSCREEN is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_ATI_REMOTE2 is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_MON is not set
#
# USB port drivers
#
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TEST is not set
#
# USB DSL modem support
#
# CONFIG_USB_ATM is not set
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# LED devices
#
# CONFIG_NEW_LEDS is not set
#
# LED drivers
#
#
# LED Triggers
#
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
# CONFIG_EDAC is not set
#
# Real Time Clock
#
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
#
# RTC drivers
#
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_TEST is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=m
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_IPIPE_DEBUG is not set
CONFIG_IPIPE_TRACE_ENABLE_VALUE=0
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_FS is not set
# CONFIG_UNWIND_INFO is not set
CONFIG_EARLY_PRINTK=y
CONFIG_STACK_BACKTRACE_COLS=2
CONFIG_DOUBLEFAULT=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
CONFIG_CRYPTO_AES=m
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set
#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set
#
# Library routines
#
CONFIG_CRC_CCITT=y
CONFIG_CRC16=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y
[-- Attachment #3: xeno-Nico_03.tar.gz --]
[-- Type: application/octet-stream, Size: 6850 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread[parent not found: <s56c97a4.096@domain.hid>]
* Re: Rép. : Re: [Xenomai-help] Switch mode with x86
[not found] <s56c97a4.096@domain.hid>
@ 2006-11-28 20:27 ` Jan Kiszka
0 siblings, 0 replies; 20+ messages in thread
From: Jan Kiszka @ 2006-11-28 20:27 UTC (permalink / raw)
To: Nicolas BLANCHARD; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 4206 bytes --]
Nicolas BLANCHARD wrote:
>>>>> Jan Kiszka <jan.kiszka@domain.hid> 28/11/06 19:02 >>>
>> Nicolas BLANCHARD wrote:
>>> Hi !
>>>
>>> I'm newbie in xenomai world,
>>> I've write an application which make a lot of switch mode
>>> (Primary->secondary ...)
>>> and sometime tasks are block in secondary mode (/proc/xenomai/sched
> ->
>>> stat X).
>>> (no watchod message in dmesg, it's block in secondary mode).
>>>
>>> I use xenomai 2.2.5, adeos 1.5.02 (same probleme with 2.2.3 et adeos
>>> 1.4)
>>> It' run on x86 (486 vortex 166Mhz).
>>> So, i've write an litle example that failed. It failed on my x86 (in
>>> less than 2 minutes),
>>> but this example run corectly with a pentium 4 or an Amd processor :
>> How does it fail precisely? Which tasks are stuck? Attach
>> /proc/xenomai/sched output e.g. Already tried to attach gdb to that
>> process after the lock-up?
>
> I've no "crash", Tasks are blocked :
>
> /proc/xenomai/stat -> state of TASK_1 (Hight priority) : X
> -> state of TASK_2 (Low priority) : R or sometime X
> /proc/xenomai/sched -> period of TASK_1 always 0, CPU 0%
> -> period of TASK_2 always 0, CPU 0%
>
> In my original program, all others tasks which don't switch to secondary
> mode
> are still alive and runs correctly ...
>
> I've tested gdb, nothing special, it's like if it was normal,
> But block tasks seems to be in a infinite sleep under secondary mode.
I was targeting with gdb on the question "blocked on what?"
>
>>
>> One difference of vortex vs. P4 might be (besides speed) that for the
>> former Xenomai uses TSC emulation, for the latter the CPU already comes
>> with this support. You can force the high-end systems into that mode by
>> compiling the kernel with CONFIG_M586. Or did you use the same kernel
>> images on all systems?
>>
>
> No, kernel are not similar(both xenomai 2.2.5 + adeos 1.5-02 + linux
> 2.6.17.13),
> ->Pentium 4 under windowsXP with Vmware worstation vm ubuntu,
> different kernel config
> for run with Vmware, it's run fine.
> In xenomai options there is nothing different.
>
> I will try CONFIG_M586 (actually 486)
Given the information below, I suspect now it is a race that is more
likely on slow boxes. Anyway, it's worth a test.
>
>> Your .config would be interesting. You can already check if
>> CONFIG_INPUT_PCSPKR is set. Must be off for TSC emulation (Xenomai 2.2
>> doesn't check for this conflict, 2.3 will do so).
>
> Ok
> (With Xenomai configure script i've passed options : disable-x86-tsc and
> disable-x86-sep)
>
>>> #include <sys/mman.h>
>>> #include <stdio.h>
>>> #include <signal.h>
>>> #include <native/task.h>
>>> #include <string.h>
>>>
>>> static int iStop = 0;
>>> RT_TASK Task_1, Task_2;
>>>
> //----------------------------------------------------------------------THREAD
>>> 1
>>> void thread_1(void *arg)
>>> {
>>> while(1)
>>> {
>>> unsigned long overruns;
>>> int iErr;
>>>
>>> iErr = rt_task_wait_period(&overruns);
>>> if (iErr || overruns)
>>> printf("Echec wait_period task_1 err %d,
>>> overruns: %lu\n",iErr,overruns);
>>
>> Would have been better to attach the program instead of inlining it. :)
>>
>>> //iErr = rt_task_set_mode(T_PRIMARY, 0, NULL);
>>> if(iErr)
>>> printf("Echec set_mod Secondary task_1\n");
>>> printf("r\n");
>>> if(iStop == 1)
>>> {
>>> iErr = rt_task_delete(&Task_1);
>>> if (iErr )
>>> printf("Echec delete task_1 err %d\n",
>>> iErr);
>>> break;
>>> }
>>> }
>> There is no mode switch in this thread and the second one. Is this not
>> required to cause the lock-up???
>>
>> ...
>
> There is a switch with printf, if you comment this line and uncomment
> rt_task_set_mode line the probleme is the same.
Ah, uum, just found my glasses.
So there must be two tasks in secondary mode, and they must run at
different prio levels? Then I have two more things to try:
- CONFIG_XENO_OPT_RPIDISABLE (Nucleus feature to disable prio boosting
in secondary mode)
- Xenomai 2.3-rc2 (to check if some recent change improves the
situation)
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Rép. : Re: [Xenomai-help] Switch mode with x86
@ 2006-11-28 19:09 Nicolas BLANCHARD
0 siblings, 0 replies; 20+ messages in thread
From: Nicolas BLANCHARD @ 2006-11-28 19:09 UTC (permalink / raw)
To: jan.kiszka; +Cc: xenomai
>>>> Jan Kiszka <jan.kiszka@domain.hid> 28/11/06 19:02 >>>
>Nicolas BLANCHARD wrote:
>> Hi !
>>
>> I'm newbie in xenomai world,
>> I've write an application which make a lot of switch mode
>> (Primary->secondary ...)
>> and sometime tasks are block in secondary mode (/proc/xenomai/sched
->
>> stat X).
>> (no watchod message in dmesg, it's block in secondary mode).
>>
>> I use xenomai 2.2.5, adeos 1.5.02 (same probleme with 2.2.3 et adeos
>> 1.4)
>> It' run on x86 (486 vortex 166Mhz).
>> So, i've write an litle example that failed. It failed on my x86 (in
>> less than 2 minutes),
>> but this example run corectly with a pentium 4 or an Amd processor :
>
>How does it fail precisely? Which tasks are stuck? Attach
>/proc/xenomai/sched output e.g. Already tried to attach gdb to that
>process after the lock-up?
I've no "crash", Tasks are blocked :
/proc/xenomai/stat -> state of TASK_1 (Hight priority) : X
-> state of TASK_2 (Low priority) : R or sometime X
/proc/xenomai/sched -> period of TASK_1 always 0, CPU 0%
-> period of TASK_2 always 0, CPU 0%
In my original program, all others tasks which don't switch to secondary
mode
are still alive and runs correctly ...
I've tested gdb, nothing special, it's like if it was normal,
But block tasks seems to be in a infinite sleep under secondary mode.
>
>
>One difference of vortex vs. P4 might be (besides speed) that for the
>former Xenomai uses TSC emulation, for the latter the CPU already comes
>with this support. You can force the high-end systems into that mode by
>compiling the kernel with CONFIG_M586. Or did you use the same kernel
>images on all systems?
>
No, kernel are not similar(both xenomai 2.2.5 + adeos 1.5-02 + linux
2.6.17.13),
->Pentium 4 under windowsXP with Vmware worstation vm ubuntu,
different kernel config
for run with Vmware, it's run fine.
In xenomai options there is nothing different.
I will try CONFIG_M586 (actually 486)
>Your .config would be interesting. You can already check if
>CONFIG_INPUT_PCSPKR is set. Must be off for TSC emulation (Xenomai 2.2
>doesn't check for this conflict, 2.3 will do so).
>>
Ok
(With Xenomai configure script i've passed options : disable-x86-tsc and
disable-x86-sep)
>>
>> #include <sys/mman.h>
>> #include <stdio.h>
>> #include <signal.h>
>> #include <native/task.h>
>> #include <string.h>
>>
>> static int iStop = 0;
>> RT_TASK Task_1, Task_2;
>>
//----------------------------------------------------------------------THREAD
>> 1
>> void thread_1(void *arg)
>> {
>> while(1)
>> {
>> unsigned long overruns;
>> int iErr;
>>
>> iErr = rt_task_wait_period(&overruns);
>> if (iErr || overruns)
>> printf("Echec wait_period task_1 err %d,
>> overruns: %lu\n",iErr,overruns);
>
>
>Would have been better to attach the program instead of inlining it. :)
>
>>
>> //iErr = rt_task_set_mode(T_PRIMARY, 0, NULL);
>> if(iErr)
>> printf("Echec set_mod Secondary task_1\n");
>> printf("r\n");
>> if(iStop == 1)
>> {
>> iErr = rt_task_delete(&Task_1);
>> if (iErr )
>> printf("Echec delete task_1 err %d\n",
>> iErr);
>> break;
>> }
>> }
>
>There is no mode switch in this thread and the second one. Is this not
>required to cause the lock-up???
>
>...
There is a switch with printf, if you comment this line and uncomment
rt_task_set_mode line the probleme is the same.
>>
>> If thoses two task have the same priority it looks to not failed,
>> perhaps a problem
>> with the scheduler in secondary mode when two task comes from primary
>> mode ?
>> Is it a know probleme with x86 ?
>
>
>Nope. Fairly unusual. Does the switchtest from the Xenomai test-suite
>fail as well?
>
Nothing failed with xenomai 2.2.5 (FPU problem with switchtest and
xenomai 2.2.3)
>> Or perhaps a big error in my example ...
>
>Nothing I can see.
>
>>
>>Have you an idea ?
>> thanks in advance
>>
>> nicolas blanchard
>>
>
>Jan
>
I will post /proc/xenomai/stat and sched and attach the example program
tomorrow.
thanks
nicolas blanchard
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2006-12-06 9:06 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-29 12:19 Rép. : Re: [Xenomai-help] Switch mode with x86 Nicolas BLANCHARD
2006-12-03 19:32 ` Jan Kiszka
2006-12-03 19:59 ` Philippe Gerum
2006-12-03 20:10 ` Jan Kiszka
2006-12-03 21:09 ` Jan Kiszka
2006-12-03 23:30 ` Philippe Gerum
2006-12-04 8:13 ` Jan Kiszka
2006-12-04 21:06 ` Jan Kiszka
2006-12-05 22:17 ` Philippe Gerum
2006-12-06 8:37 ` Jan Kiszka
2006-12-06 9:06 ` Philippe Gerum
2006-12-05 22:18 ` Philippe Gerum
2006-12-04 9:46 ` Gilles Chanteperdrix
2006-12-03 21:02 ` Philippe Gerum
[not found] <s575af89.064@domain.hid>
2006-12-05 17:15 ` Jan Kiszka
-- strict thread matches above, loose matches on Subject: below --
2006-12-05 12:33 Nicolas BLANCHARD
[not found] <s56d88c0.000@domain.hid>
2006-11-29 13:52 ` Jan Kiszka
2006-11-29 10:25 Nicolas BLANCHARD
[not found] <s56c97a4.096@domain.hid>
2006-11-28 20:27 ` Jan Kiszka
2006-11-28 19:09 Nicolas BLANCHARD
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.