Wolfgang Grandegger wrote:
> Philippe Gerum wrote:
>> Wolfgang Grandegger wrote:
>>> Philippe Gerum wrote:
>>>> Wolfgang Grandegger wrote:
>>>>> Philippe Gerum wrote:
>>>>>> Wolfgang Grandegger wrote:
>>>>>>> Wolfgang Grandegger wrote:
>>>>>>>> Philippe Gerum wrote:
>>>>>>>>> Wolfgang Grandegger wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I want to use a Xenomai task overtaking the duties of a watchdog
>>>>>>>>>> running
>>>>>>>>>> under Linux as soon as the Xenomai layer is available during boot
>>>>>>>>>> up. Is
>>>>>>>>>> there a function or variable I could inspect? With 2.3.x, I called
>>>>>>>>>> rtdm_init_task() until it returned without error but with 2.4.x it
>>>>>>>>>> results in a kernel crash :-(.
>>>>>>>>>>
>>>>>>>>> What is the value of CONFIG_XENO_OPT_SYS_STACKPOOLSZ?
>>>>>>>> #
>>>>>>>> # Nucleus options
>>>>>>>> #
>>>>>>>> CONFIG_XENO_OPT_PERVASIVE=y
>>>>>>>> CONFIG_XENO_OPT_SYS_STACKPOOLSZ=32
>>>>>>>> # CONFIG_XENO_OPT_PRIOCPL is not set
>>>>>>>> CONFIG_XENO_OPT_PIPE=y
>>>>>>> Some more input on that issue. Here is the oops and the NIP location:
>>>>>>>
>>>>>>> XLB Arb cnf: 8000a006
>>>>>>> mpc5xxx_ide: Setting up IDE interface ide0...
>>>>>>> Probing IDE interface ide0...
>>>>>>> Oops: kernel access of bad area, sig: 11
>>>>>>> NIP: C0113364 XER: 20000000 LR: C0113320 SP: C047DB30 REGS: c047da80
>>>>>>> TRAP: 0300 Not tainted
>>>>>>> MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
>>>>>>> DAR: 0000003C, DSISR: 20000000
>>>>>>> TASK = c047c000[1] 'swapper' Last syscall: 120
>>>>>>> last math 00000000 last altivec 00000000
>>>>>>> GPR00: 00000003 C047DB30 C047C000 00000009 FFFFFFF7 C01CF395 C0220000
>>>>>>> 00000000
>>>>>>> GPR08: 00000038 C01ECC00 C02445F4 00000000 00000000 100803B0 07FCF000
>>>>>>> 08099000
>>>>>>> GPR16: C0220000 FFFFFF7F C0230000 FFF75F97 C022B3C0 00000000 C01ECC0C
>>>>>>> C0230000
>>>>>>> GPR24: 00000000 00000000 00000010 C02446F4 3B9A0000 00000000 00000000
>>>>>>> C0244590
>>>>>>> Call backtrace:
>>>>>>> C0113320 C0111F00 C010DD0C C013D810 C00DA48C C001EAB4 C001A70C
>>>>>>> C001A598 C001A254 C00079C0 C000D63C C0024C50 C00243AC C000D298
>>>>>>> C000D508 C0005CF4 0039FBC0 C00F0A4C C00F0EA0 C00F15C0 C00F210C
>>>>>>> C02149C8 C0214A14 C020A64C C00039A0 C0008678
>>>>>>> Kernel panic: Aiee, killing interrupt handler!
>>>>>>> In interrupt handler - not syncing
>>>>>>> <0>Rebooting in 180 seconds..
>>>>>>>
>>>>>>> $ ppc_6xx-gdb vmlinux:
>>>>>>> ...
>>>>>>> (gdb) l *0xC0113364
>>>>>>> 0xc0113364 is in __xntimer_init (queue.h:51).
>>>>>>> 46 holder->last = holder;
>>>>>>> 47 holder->next = holder;
>>>>>>> 48 }
>>>>>>> 49
>>>>>>> 50 static inline void ath(xnholder_t *head, xnholder_t *holder)
>>>>>>> 51 {
>>>>>>> 52 /* Inserts the new element right after the heading one
>>>>>>> */
>>>>>>> 53 holder->last = head;
>>>>>>> 54 holder->next = head->next;
>>>>>>> 55 holder->next->last = holder;
>>>>>>>
>>>>>>> Wolfgang.
>>>>>>>
>>>>>> Thanks. Could you send me the full boot log until the oops occurs as
>>>>>> well? TIA,
>>>>> Ses below. As mentioned earlier, rtdm_task_init() is called early before
>>>>> the
>>>>> Xenomai sub-system gets initialized.
>>>>>
>>>> The point is, how much earlier, and as a matter of fact, at least one skin
>>>> should have initialized before any service creating a Xenomai task could be
>>>> invoked, like rtdm_task_init(). As you mentioned and from your boot log,
>>>> not
>>>> even the nucleus was started, so I don't understand how this could have
>>>> ever
>>>> worked with any Xenomai version actually (the gist of the matter is that we
>>> Maybe just pure luck ;-). At least rtdm_task_init() did not crash and
>>> even return an error under Xenomai 2.3.5 and Linux 2.4.25.
>>>
>> With v2.3.x, it would really depend on the random memory contents the main
>> allocator would use as its internal descriptor for setting up the task stack.
>> v2.4.x does not use the main allocator but a specific stack pool instead;
>> this
>> might be the reason why you can't be lucky anymore.
>>
>>>> don't have the internal allocator set up for grabbing stack memory for the
>>>> new
>>>> task at that point). You may want to make your task creation routine a
>>>> late_initcall to fix this.
>>> It's actually called from the watchdog driver, which needs to be trigger
>>> early. Is there a function or variable telling that the Xenomai layer is
>>> initialized.
>> xnpod_active_p().
>
> It does not work but testing the global variable "rtdm_initialzed" does:
>
Very, very strange. xnpod_active_p() tests a marker that is precisely set when
RTDM has registered itself to the nucleus, at which point rtdm_task_init()
should have no problem to work, despite additional inits remain that RTDM might
need.
> http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/skins/rtdm/module.c#096
>
> Here is a code snippet to make the intended usage in the Linux watchdog
> driver clear:
>
> if (!hw_wdt_rt_active) {
> hw_wdt_restart();
> if (rtdm_initialised) {
> /* hw_wdt_rt_task() will overtake the duty of
> restarting the watchdog */
> err = rtdm_task_init(&hw_wdt_rt_task, "rt-watchdog",
> hw_wdt_rt_func, NULL, prio,
> timer_period);
> if (err) {
> printk("WDT: rtdm_task_init failed (err=%d)\n",
> err);
> } else {
> hw_wdt_rt_active = 1;
> printk("WDT: rt-watchdog started\n");
> }
> }
> }
>
> Hope I did not misuse "rtdm_initialzed"!?
>
> Wolfgang.
>
--
Philippe.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
