* [Xenomai-help] Using Xenomai in early boot phase. @ 2008-11-03 14:36 Wolfgang Grandegger 2008-11-03 14:39 ` Philippe Gerum 0 siblings, 1 reply; 14+ messages in thread From: Wolfgang Grandegger @ 2008-11-03 14:36 UTC (permalink / raw) To: xenomai-help 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 :-(. Wolfgang. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] Using Xenomai in early boot phase. 2008-11-03 14:36 [Xenomai-help] Using Xenomai in early boot phase Wolfgang Grandegger @ 2008-11-03 14:39 ` Philippe Gerum 2008-11-04 8:16 ` Wolfgang Grandegger 0 siblings, 1 reply; 14+ messages in thread From: Philippe Gerum @ 2008-11-03 14:39 UTC (permalink / raw) To: Wolfgang Grandegger; +Cc: xenomai-help 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? > Wolfgang. > > _______________________________________________ > Xenomai-help mailing list > Xenomai-help@domain.hid > https://mail.gna.org/listinfo/xenomai-help > -- Philippe. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] Using Xenomai in early boot phase. 2008-11-03 14:39 ` Philippe Gerum @ 2008-11-04 8:16 ` Wolfgang Grandegger 2008-11-04 10:06 ` Wolfgang Grandegger 0 siblings, 1 reply; 14+ messages in thread From: Wolfgang Grandegger @ 2008-11-04 8:16 UTC (permalink / raw) To: rpm; +Cc: xenomai-help 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 Wolfgang. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] Using Xenomai in early boot phase. 2008-11-04 8:16 ` Wolfgang Grandegger @ 2008-11-04 10:06 ` Wolfgang Grandegger 2008-11-04 10:21 ` Philippe Gerum 0 siblings, 1 reply; 14+ messages in thread From: Wolfgang Grandegger @ 2008-11-04 10:06 UTC (permalink / raw) To: rpm; +Cc: xenomai-help 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] Using Xenomai in early boot phase. 2008-11-04 10:06 ` Wolfgang Grandegger @ 2008-11-04 10:21 ` Philippe Gerum 2008-11-04 12:05 ` Wolfgang Grandegger 0 siblings, 1 reply; 14+ messages in thread From: Philippe Gerum @ 2008-11-04 10:21 UTC (permalink / raw) To: Wolfgang Grandegger; +Cc: xenomai-help 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, -- Philippe. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] Using Xenomai in early boot phase. 2008-11-04 10:21 ` Philippe Gerum @ 2008-11-04 12:05 ` Wolfgang Grandegger 2008-11-04 12:24 ` Philippe Gerum 0 siblings, 1 reply; 14+ messages in thread From: Wolfgang Grandegger @ 2008-11-04 12:05 UTC (permalink / raw) To: rpm; +Cc: xenomai-help 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. Wolfgang. U-Boot 1.3.4_@domain.hid (Sep 3 2008 - 13:44:11) CPU: MPC5200B v2.2, Core v1.4 at 396 MHz Bus 132 MHz, IPB 132 MHz, PCI 33 MHz Board: MAN UC101 I2C: 85 kHz, ready i2c_read: failed to address chip DTT: 1 FAILED INIT DRAM: 128 MB FLASH: 8 MB In: serial Out: serial Err: serial Net: FEC ETHERNET IDE: Bus 0: OK Device 0: Model: SILICONSYSTEMS INC 64MB Firm: 240-0230 Ser#: 496CTZ63Se611SC00918 Type: Hard Disk Capacity: 62.5 MB = 0.0 GB (128128 x 512) Device 1: Model: Firm: Ser#: Type: # 1F # Capacity: not available Hit any key to stop autoboot: 0 reading uc101_lx.img 992316 bytes read reading uInitrd.img 1059055 bytes read ## Booting kernel from Legacy Image at 00200000 ... Image Name: Linux-2.4.25 Created: 2008-11-04 7:41:51 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 992252 Bytes = 969 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 00400000 ... Image Name: Pivot Root Helper Created: 2008-06-18 8:45:02 UTC Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 1058991 Bytes = 1 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Loading Ramdisk to 07e11000, end 07f138af ... OK Memory BAT mapping: BAT2=128Mb, BAT3=0Mb, residual: 0Mb Linux version 2.4.25 (arowil@domain.hid) (gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-10)) #1 @(#)MR_kernel_UC101_0.62.1.1.8.offen Di 4. Nov 08:36:30 CET 2008 On node 0 totalpages: 32768 zone(0): 32768 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/loop0 ro wdt=off console=ttyS0,38400 trace=on I-pipe 1.2-02: pipeline enabled. Calibrating delay loop... 263.78 BogoMIPS Memory: 125512k available (1736k kernel code, 664k data, 68k init, 0k highmem) Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) Inode cache hash table entries: 8192 (order: 4, 65536 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd Journalled Block Device driver loaded JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc. i2c-core.o: i2c core module version 2.6.1 (20010830) i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830) i2c locking set to 1 i2c-proc.o version 2.6.1 (20010830) pty: 256 Unix98 ptys configured ttyS0 on PSC1 ttyS1 on PSC2 ttyS2 on PSC6 PCF8563 Real-Time Clock Driver $Revision: 1.3 $ wd@domain.hid WDT: Software Watchdog Timer 1.0.0 (disabled) SRAM_DRV: initialized uc101_gpio: 1.1 PCI.IBM-1 found at irq 6 RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize loop: loaded (max 8 devices) Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx Port Config is: 0x4d558044 ipb=132MHz, set clock period to 7 GPIO config: 4d558044 ATA invalid: 01000000 ATA hostcnf: 03000000 ATA pio1 : 100a0a00 ATA pio2 : 02040600 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 5FFFFFF7 07FCF000 08099000 GPR16: C0220000 BFFFFF7F C0230000 7FFE5F97 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.. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] Using Xenomai in early boot phase. 2008-11-04 12:05 ` Wolfgang Grandegger @ 2008-11-04 12:24 ` Philippe Gerum 2008-11-04 12:38 ` Wolfgang Grandegger 0 siblings, 1 reply; 14+ messages in thread From: Philippe Gerum @ 2008-11-04 12:24 UTC (permalink / raw) To: Wolfgang Grandegger; +Cc: xenomai-help 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 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. > Wolfgang. > > > U-Boot 1.3.4_@domain.hid (Sep 3 2008 - 13:44:11) > > CPU: MPC5200B v2.2, Core v1.4 at 396 MHz > Bus 132 MHz, IPB 132 MHz, PCI 33 MHz > Board: MAN UC101 > I2C: 85 kHz, ready > i2c_read: failed to address chip > DTT: 1 FAILED INIT > DRAM: 128 MB > FLASH: 8 MB > In: serial > Out: serial > Err: serial > Net: FEC ETHERNET > IDE: Bus 0: OK > Device 0: Model: SILICONSYSTEMS INC 64MB Firm: 240-0230 Ser#: 496CTZ63Se611SC00918 > Type: Hard Disk > Capacity: 62.5 MB = 0.0 GB (128128 x 512) > Device 1: Model: Firm: Ser#: > Type: # 1F # > Capacity: not available > Hit any key to stop autoboot: 0 > reading uc101_lx.img > > 992316 bytes read > reading uInitrd.img > > 1059055 bytes read > ## Booting kernel from Legacy Image at 00200000 ... > Image Name: Linux-2.4.25 > Created: 2008-11-04 7:41:51 UTC > Image Type: PowerPC Linux Kernel Image (gzip compressed) > Data Size: 992252 Bytes = 969 kB > Load Address: 00000000 > Entry Point: 00000000 > Verifying Checksum ... OK > ## Loading init Ramdisk from Legacy Image at 00400000 ... > Image Name: Pivot Root Helper > Created: 2008-06-18 8:45:02 UTC > Image Type: PowerPC Linux RAMDisk Image (gzip compressed) > Data Size: 1058991 Bytes = 1 MB > Load Address: 00000000 > Entry Point: 00000000 > Verifying Checksum ... OK > Uncompressing Kernel Image ... OK > Loading Ramdisk to 07e11000, end 07f138af ... OK > Memory BAT mapping: BAT2=128Mb, BAT3=0Mb, residual: 0Mb > Linux version 2.4.25 (arowil@domain.hid) (gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-10)) #1 @(#)MR_kernel_UC101_0.62.1.1.8.offen Di 4. Nov 08:36:30 CET 2008 > On node 0 totalpages: 32768 > zone(0): 32768 pages. > zone(1): 0 pages. > zone(2): 0 pages. > Kernel command line: root=/dev/loop0 ro wdt=off console=ttyS0,38400 trace=on > I-pipe 1.2-02: pipeline enabled. > Calibrating delay loop... 263.78 BogoMIPS > Memory: 125512k available (1736k kernel code, 664k data, 68k init, 0k highmem) > Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) > Inode cache hash table entries: 8192 (order: 4, 65536 bytes) > Mount cache hash table entries: 512 (order: 0, 4096 bytes) > Buffer cache hash table entries: 8192 (order: 3, 32768 bytes) > Page-cache hash table entries: 32768 (order: 5, 131072 bytes) > POSIX conformance testing by UNIFIX > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Initializing RT netlink socket > Starting kswapd > Journalled Block Device driver loaded > JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc. > i2c-core.o: i2c core module version 2.6.1 (20010830) > i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830) > i2c locking set to 1 > i2c-proc.o version 2.6.1 (20010830) > pty: 256 Unix98 ptys configured > ttyS0 on PSC1 > ttyS1 on PSC2 > ttyS2 on PSC6 > PCF8563 Real-Time Clock Driver $Revision: 1.3 $ wd@domain.hid > WDT: Software Watchdog Timer 1.0.0 (disabled) > SRAM_DRV: initialized > uc101_gpio: 1.1 > PCI.IBM-1 found at irq 6 > RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize > loop: loaded (max 8 devices) > Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 > ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx > Port Config is: 0x4d558044 > ipb=132MHz, set clock period to 7 > GPIO config: 4d558044 > ATA invalid: 01000000 > ATA hostcnf: 03000000 > ATA pio1 : 100a0a00 > ATA pio2 : 02040600 > 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 5FFFFFF7 07FCF000 08099000 > GPR16: C0220000 BFFFFF7F C0230000 7FFE5F97 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.. > -- Philippe. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] Using Xenomai in early boot phase. 2008-11-04 12:24 ` Philippe Gerum @ 2008-11-04 12:38 ` Wolfgang Grandegger 2008-11-04 14:04 ` Philippe Gerum 0 siblings, 1 reply; 14+ messages in thread From: Wolfgang Grandegger @ 2008-11-04 12:38 UTC (permalink / raw) To: rpm; +Cc: xenomai-help 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. > 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. Wolfgang. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] Using Xenomai in early boot phase. 2008-11-04 12:38 ` Wolfgang Grandegger @ 2008-11-04 14:04 ` Philippe Gerum 2008-11-05 18:52 ` Wolfgang Grandegger 0 siblings, 1 reply; 14+ messages in thread From: Philippe Gerum @ 2008-11-04 14:04 UTC (permalink / raw) To: Wolfgang Grandegger; +Cc: xenomai-help 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(). > > Wolfgang. > -- Philippe. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] Using Xenomai in early boot phase. 2008-11-04 14:04 ` Philippe Gerum @ 2008-11-05 18:52 ` Wolfgang Grandegger 2008-11-05 18:58 ` Jan Kiszka 2008-11-05 19:48 ` Philippe Gerum 0 siblings, 2 replies; 14+ messages in thread From: Wolfgang Grandegger @ 2008-11-05 18:52 UTC (permalink / raw) To: rpm; +Cc: xenomai-help 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: 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] Using Xenomai in early boot phase. 2008-11-05 18:52 ` Wolfgang Grandegger @ 2008-11-05 18:58 ` Jan Kiszka 2008-11-06 7:32 ` Wolfgang Grandegger 2008-11-05 19:48 ` Philippe Gerum 1 sibling, 1 reply; 14+ messages in thread From: Jan Kiszka @ 2008-11-05 18:58 UTC (permalink / raw) To: Wolfgang Grandegger; +Cc: xenomai-help 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: > > 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"!? Of course you did :). This will fall apart if someone decides to build RTDM as a module. But I guess the whole scenario is so special anyway that this doesn't matter (or what prevents registering this in the appropriate order / initcall level?). Jan -- Siemens AG, Corporate Technology, CT SE 2 ES-OS Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] Using Xenomai in early boot phase. 2008-11-05 18:58 ` Jan Kiszka @ 2008-11-06 7:32 ` Wolfgang Grandegger 0 siblings, 0 replies; 14+ messages in thread From: Wolfgang Grandegger @ 2008-11-06 7:32 UTC (permalink / raw) To: Jan Kiszka; +Cc: xenomai-help Jan Kiszka wrote: > 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: >> >> 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"!? > > Of course you did :). This will fall apart if someone decides to build > RTDM as a module. I don't think so because loading the module will fail in that case because of undefined symbols. > But I guess the whole scenario is so special anyway that this doesn't > matter (or what prevents registering this in the appropriate order / > initcall level?). The hardware watchdog needs to be re-started early, first by a Linux timer handler and then by a Xenomai task. Well, the clean solution would be registering late (after the Xenomai/RTMD setup)) a driver starting the RT task and setting the exported variable hw_wdt_rt_active to 1. Wolfgang. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] Using Xenomai in early boot phase. 2008-11-05 18:52 ` Wolfgang Grandegger 2008-11-05 18:58 ` Jan Kiszka @ 2008-11-05 19:48 ` Philippe Gerum 2008-11-05 19:49 ` Philippe Gerum 1 sibling, 1 reply; 14+ messages in thread From: Philippe Gerum @ 2008-11-05 19:48 UTC (permalink / raw) To: Wolfgang Grandegger; +Cc: xenomai-help 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] Using Xenomai in early boot phase. 2008-11-05 19:48 ` Philippe Gerum @ 2008-11-05 19:49 ` Philippe Gerum 0 siblings, 0 replies; 14+ messages in thread From: Philippe Gerum @ 2008-11-05 19:49 UTC (permalink / raw) To: rpm; +Cc: xenomai-help Philippe Gerum wrote: > 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. > Well, except if your RTDM task immediately calls into RTDM when initializing as well. >> 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2008-11-06 7:32 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-11-03 14:36 [Xenomai-help] Using Xenomai in early boot phase Wolfgang Grandegger 2008-11-03 14:39 ` Philippe Gerum 2008-11-04 8:16 ` Wolfgang Grandegger 2008-11-04 10:06 ` Wolfgang Grandegger 2008-11-04 10:21 ` Philippe Gerum 2008-11-04 12:05 ` Wolfgang Grandegger 2008-11-04 12:24 ` Philippe Gerum 2008-11-04 12:38 ` Wolfgang Grandegger 2008-11-04 14:04 ` Philippe Gerum 2008-11-05 18:52 ` Wolfgang Grandegger 2008-11-05 18:58 ` Jan Kiszka 2008-11-06 7:32 ` Wolfgang Grandegger 2008-11-05 19:48 ` Philippe Gerum 2008-11-05 19:49 ` Philippe Gerum
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.