[Xenomai-help] [REMINDER] Migrating Xenomai mailing lists
We will soon be moving all our mailing lists out of gna.org to host them on xenomai.org instead. At this chance, xenomai-help@gna.org, xenomai-c...@gna.org and adeos-m...@gna.org will be merged into a single list named xeno...@xenomai.org. These are low traffic lists, so we want to group all Xenomai-related discussions in one place. Commits to the development trees will be sent to xenomai-...@xenomai.org. The migration is scheduled for May 19, all current subscribers of the former lists will be automatically subscribed to xeno...@xenomai.org. You will receive an automated mail from our Mailman when this happens. The Mailman interface to the new lists is available at: http://www.xenomai.org/mailman/listinfo/xenomai. Please drop a mail to mail...@xenomai.org in case of issue. Thanks, -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai on kernel 3.x and x86
On 05/14/2012 09:45 AM, Leopold Palomo-Avellaneda wrote: Hi, sorry if the question it's obvious but I have not understood the information that I have found. I have read the roadmap of Xenomai [1] and it's not clear to me what should I have to do if I would want to use xenomai in a kernel 3.x. As far as I understand the idea it's to go to Xenomai 3 with the prempt patch or a co-kernel option. Then xenomai will be the interface to the realtime kernel. From the user point of view, no matter if xenomai will use the rt- preemt or the co-kernel option. Also, the driver option will be the rtdm. But I don't understand if the Adeos patch will survive (at least in x86) or what will happen. I understand that the co-kernel option is the same that we have now (2.6) with the adeos patch, but I have not be able to find an Adeos patch for a x86 platform in a 3.x kernel. The interrupt pipeline will be maintained for running the co-kernel incarnation of Xenomai 3, and for updating the 2.6.x maintenance branch as well. To run 3.2 kernels and above, using Xenomai 2.6.1 or later will be a requirement. There is an upcoming patch for linux 3.2, which is the first of the new pipeline core series, a massive refactoring of the I-pipe implementation and API, aimed at a better integration with Xenomai: http://git.denx.de/?p=ipipe-2.6.git;a=shortlog;h=refs/heads/core-3.2 It currently supports powerpc, arm, x86 and blackfin, and can be used with Xenomai 2.6.1+ and Xenomai 3 systems in dual kernel mode. I will roll this patch out officially when Gilles and I are done with fixing the rough edges. The plan is to have it shipped with the upcoming 2.6.1. To sum up: the interrupt pipeline for x86 is maintained, a release for 3.x kernels is upcoming. Please, someone could clarify this. Thanks in advance, Leo [1] http://www.xenomai.org/index.php/Xenomai:Roadmap -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] Migrating Xenomai mailing lists
We will soon be moving all our mailing lists out of gna.org to host them on xenomai.org instead. At this chance, xenomai-help@gna.org, xenomai-c...@gna.org and adeos-m...@gna.org will be merged into a single list named xeno...@xenomai.org. These are low traffic lists, so we want to group all Xenomai-related discussions in one place. Commits to the development trees will be sent to xenomai-...@xenomai.org. The migration is scheduled for May 19, all current subscribers of the former lists will be automatically subscribed to xeno...@xenomai.org. You will receive an automated mail from our Mailman when this happens. The Mailman interface to the new lists is available at: http://www.xenomai.org/mailman/listinfo/xenomai. Please drop a mail to mail...@xenomai.org in case of issue. Thanks, -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Powerpc alignment exception
On 04/30/2012 07:55 PM, Makarand Pradhan wrote: Hi, There has been a thread on this topic in the past: https://mail.gna.org/public/xenomai-help/2009-08/msg00023.html A quick background: We get the alignment exception, as we pass -fpack-struct option to gcc and some data in structures is misaligned. I have been testing the patch on Linux 3.0.0, Xenomai 2.6 and it seems to work well. Do you think, it requires any additional changes to be used with Xenomai 2.6? This is not related to the Xenomai core, this is a pipeline issue. You can use whatever pipeline patch you need to. Also, I am trying to understand how it works and have a question. Am summarizing my understanding below. Would appreciate your comments: alignment_exception: + if (test_bit(IPIPE_NOSTACK_FLAG, ipipe_this_cpudom_var(status)) + ipipe_trap_notify(IPIPE_TRAP_ALIGNMENT, regs)) return; I believe, the IPIPE_NOSTACK_FLAG is set when we are running in Linux. NOSTACK means no linux task stack, i.e. Xenomai kernel thread context, i.e. primary only, therefore non-linux. So we should invoke ipipe_trap_notify only while we are running in linux. While running in the primary domain, we would go ahead and fix the alignment. + if (!ipipe_root_domain_p + ipipe_trap_notify(IPIPE_TRAP_ALIGNMENT, regs)) + return; + I am not able to figure this part properly. If we are not in the root domain we invoke ipipe_trap_notify. (I believe root domain = Linux). So if we are in the primary, we would invoke ipipe_trap_notify. ipipe_trap_notify in turn would invoke the event handler (xnpod_trap_fault). This would send us to the secondary domain. All the same, we stay int he primary as per my tests. So, I am making a mistake somewhere. Would appreciate your opinion. The kernel is able to do some dynamic fixup when an alignment fault occurs, by decoding the offending instruction manually, unless this could only be resolved as an access fault. If the entry context is not a linux task, then we can only divert the code to the Xenomai fault handler, which will suspend the Xenomai kernel thread then tell us to return (first patch hunk). Otherwise we want to let the kernel attempt a fix up for current. If that does not work, then we need Xenomai to handle the fault for switching the context to secondary mode in case we entered the alignment handler in primary mode (second patch hunk). The bottom line is that we shall either do the fix up then return immediately with no mode change, or run the linux access fault handler in secondary mode. Rgds, Makarand. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt latency greater than 250ms
On 04/12/2012 05:57 PM, Philippe Gerum wrote: On 04/12/2012 05:45 PM, Michael Pustylnik wrote: The code masking the interrupt in IPIC (call for ipipe_pre_cascade_noeoi()) initially showed up in the patch you recommended (see your email attached). Later on it was integrated in Xenomai commit 9a5e42df8bccc59620c08caeb4b9fe92dbf94a1b. As shown in the trail below, it keeps interrupts all the time until the scheduler returns, thus breaking real-time responsiveness. A solution to this is probably to remove calling ipipe_pre_cascade_noeoi() and let the cascading handler mask the interrupt. Am I missing something? Do you think it is safe to use this solution? No, as interrupts could be re-enabled before invoking the handler, you would get an IRQ storm. The solution is to rework the cascaded IRQ handling in the generic pipeline core, so that all decoded IRQs are acked/masked, then the multiplex IRQ unmasked, then all the decoded IRQ handlers fired when syncing the relevant pipeline stage. A fix for this will follow when enough testing will have been done on arm and ppc, to check whether that logic does not raise other issue. This is the patch series fixing the issue in the newest pipeline core implementation, currently for kernel 3.2. Something along these lines would work for earlier kernels as well. http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=0a9a7b4e4ce9f4196a574471ad58f4389820c438 http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=f2ca3c2baf58bf43f4c00fb05b91b16da9fd77f2 http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=a4b909ccf80c5afa132aa7a9ccf0022cb8a6e6f2 http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=b47bc773ff07ce886aaf490921ac59e98ed9575a Michael Pustylnik, P.Eng. Senior Software Engineer *RuggedCom Inc.* www.ruggedcom.com http://www.ruggedcom.com/ 300 Applewood Crescent Concord, Ontario, L4K 5C7 Tel: (905)482-4523 Fax: (905)856-1995 *From:*xenomai-help-boun...@gna.org [mailto:xenomai-help-boun...@gna.org] *On Behalf Of *Makarand Pradhan *Sent:* Wednesday, April 04, 2012 12:59 PM *To:* Philippe Gerum *Cc:* xenomai-help@gna.org *Subject:* Re: [Xenomai-help] Interrupt latency greater than 250ms. Question. Hi Philippe, We have found that the problem is that the interrupt is unexpectedly held masked at the IPIC level for a long time. Please find the trace below: 2552 :| + func -54413 0.590 qe_ic_cascade_low_ipic+0x8 (__ipipe_ack_irq+0x2c) 2553 :| + func -54412 0.696 qe_ic_get_low_irq+0x8 (qe_ic_cascade_low_ipic+0x30) 2554 :| + func -54411 0.666 irq_linear_revmap+0x8 (qe_ic_get_low_irq+0x5c) *MASK in IPIC (SIMSR_H register bit 1)* 2555 :| + func -54411 0.606 ipic_mask_irq+0x8 (qe_ic_cascade_low_ipic+0x48) 2556 :| + func -54410 0.590 irqd_to_hwirq+0x8 (ipic_mask_irq+0x30) 2557 :| + func -54410 0.909 __ipipe_spin_lock_irqsave+0x8 (ipic_mask_irq+0x40) 2558 :| # func -54409 0.727 __ipipe_spin_unlock_irqrestore+0x8 (ipic_mask_irq+0xa8 ) 2559 :| + func -54408 0.560 __ipipe_qe_ic_cascade_irq+0x8 (qe_ic_cascade_low_ipic+ 0x5c) 2560 :| + begin 0x002b -54407 0.530 __ipipe_qe_ic_cascade_irq+0x2c (qe_ic_cascade_low_ipic +0x5c) 2561 :| + func -54407 0.651 __ipipe_handle_irq+0x8 (__ipipe_qe_ic_cascade_irq+0x38 ) 2562 :| + func -54406 0.939 __ipipe_ack_level_irq+0x8 (__ipipe_handle_irq+0xbc) *MASK in QUICC (CIMR register bit 11)* 2563 :| + func -54405 0.787 qe_ic_mask_irq+0x8 (__ipipe_ack_level_irq+0x40) *XENOMAI SCHEDULER IS INVOKED* 2576 :| # func -54393 0.590 __xnpod_schedule+0x8 (xnintr_irq_handler+0x1f8) * UNMASK in QUICC (done by our user space handler)* 2595 : + func -54377 0.621 __rt_intr_enable+0x8 [xeno_native] (hisyscall_event+0x 1e4) *UNMASK in IPIC (after 50ms, i.e. only after the scheduler returns):* 31637 :| #end 0x002b -518+ 2.272 __ipipe_qe_ic_cascade_irq+0x40 (qe_ic_cascade_low_ipic+ 0x5c) 31638 :| #func -516+ 1.090 ipic_unmask_irq+0x8 (qe_ic_cascade_low_ipic+0x70) As you can see from the trace above, the interrupt is held masked at the IPIC level all the time until the Xenomai scheduler returns and is only unmasked after that. Is it really the way it should be? Shouldn’t the interrupt be unmasked at the IPIC level right after masking it at the QUICC engine level? Rgds, Mak. On 28/03/12 02:23 PM, Makarand Pradhan wrote: Hi Philippe, On 28/03/12 12:17 PM, Philippe Gerum wrote: The log says your code wants to control when the IRQ is enabled again, by calling rt_intr_enable() from userland. I guess you are setting I_NOAUTOENA too. Correct? That is correct. I_NOAUTOENA is used in rt_intr_create. Otherwise the level trigerred interrupt will not allow the userland processing of the int. The userland handler is very small and it unconditionally rt_intr_enables the intr. Testing indicates that the interrupt is always enabled from user space within 250 usec after kernel gets the interrupt
Re: [Xenomai-help] Smi workaround on ICH8M
On 04/23/2012 03:51 AM, Willy Lambert wrote: Hi, I have a message in dmesg about SMI workaround : Xenomai: SMI-enabled chipset found, but SMI workaround disabled (check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter high interrupt latencies! My kernel should be configured properly and following the In case of high latencies of http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did some tests. Latency test is here (if it is us it should be ok no ?): Yes, this looks ok, but you need to run this test longer, and try a few usual suspects like plugging in/out USB devices while doing so (e.g. mouse, netdev). The point of this message is to tell you that your chipset is known to create latency issues in some cases (like most Intel chipset these days), but you did not enable the Xenomai code which works around such issues by shutting down problematic SMI sources. That may be right, or even required to leave all the SMI sources enabled (e.g. thermal control), but this might also lead to unacceptable latency spots. YMMV. This is basically a heads up message. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
On 04/23/2012 02:57 PM, Andrey Nechypurenko wrote: retval = rtdm_task_init(pwm_task[i], // there is currently only one element in this array pwm-task, pwm_task_proc, 0, RTDM_TASK_HIGHEST_PRIORITY, 2000); // 20ms period Do not use a thread, use a timer. So you mean instead of starting periodic task with rtdm_task_init() it is better use timer functions to trigger pin toggling piece of code? Could you please elaborate on it a little? I thought that rtdm_task_sleep() and rtdm_task_wait_period() are using timers internally to wake up the thread at the right moment. Is not they? Yes, but once the timer is woken up, a context switch is needed to wake up the thread, this adds time. I see... Nevertheless, I am surprised that context switch is so expensive. Keep in mind that in a dual kernel system, the RTOS part is competing with the linux kernel on core resources such as CPU caches. So each time your code sleeps for the next period, it leaves a 20 ms time window to linux to run and happily trash all I/D caches, which is a lot. Now, if you have to schedule a thread, you have to traverse the Xenomai scheduling core to do the switch, in addition to the timer interrupt handling, which translates into significantly more code and data being accessed. You can check this effect using the latency test: the faster the sampling period, the shorter the latencies, and conversely. The other alternative I describe in my last mail, that is, using a dedicated hardware timer with its own irq handler, is a bit more of a workaround, but still not uncommon in the RTOS world. Well, if nothing else would help, I'll try this way :-) . Thank you! Andrey. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rt_event_wait makes linux crash if executed while debugging with gdbserver
On 04/13/12 16:49, Fabio Visona wrote:
Hello,
I am trying to debug a Xenomai task through gdbserver over ethernet, with:
gdbserver host:12345 --attach 240
where 240 is the PID of the Xenomai real-time task I want to debug.
After connecting with the gdb client, running continuosly is fine, but
if I put a breakpoint and afterwards make the software execute an
rt_event_wait call, the system crashes (gdb client stuck, no more
ethernet connection, no panic message on the debug console serial port).
By going step by step with the debugger, the exact point of the problem
can be isolated:
int rt_event_wait(RT_EVENT *event,
unsigned long mask,
unsigned long *mask_r, int mode, RTIME timeout)
{
int ret;
ret = XENOMAI_SKINCALL5(__native_muxid,
__native_event_wait,
event, mask, mode, XN_RELATIVE, timeout);
if (ret)
return ret;
*mask_r = mask;
return 0;
}
with mode = EV_ANY, timeout is 1 - 10 ns about.
Showing the assembly code of the XENOMAI_SKINCALL5 macro:
0x64fc4e rt_event_wait+42: R3 = 0x0 (X); /* R3=0x0( 0) */
0x64fc50 rt_event_wait+44: R7.L = 0x22b; /* (555)
R7=0x0x27022b(2556459) */
0x64fc54 rt_event_wait+48: JUMP.S 0x0x64fc60 rt_event_wait+60;
0x64fc56 rt_event_wait+50: R0 = P1;
0x64fc58 rt_event_wait+52: R1 = -0x55 (X); /* R1=0x0xffab(-85) */
0x64fc5c rt_event_wait+56: CC = R0 == R1;
0x64fc5e rt_event_wait+58: IF !CC JUMP 0x0x64fc9e rt_event_wait+122;
0x64fc60 rt_event_wait+60: [FP + -0x848] = R3;
0x64fc64 rt_event_wait+64: R1 = R6;
0x64fc66 rt_event_wait+66: R2 = P4;
0x64fc68 rt_event_wait+68: R0 = [P5];
0x64fc6a rt_event_wait+70: R0 = R0 | R7;
0x64fc6c rt_event_wait+72: P0 = R0;
0x64fc6e rt_event_wait+74: R0 = P3;
0x64fc70 rt_event_wait+76: EXCPT 0x0;
0x64fc72 rt_event_wait+78: P1 = R0;
0x64fc74 rt_event_wait+80: R0 = [FP + -0x848];
Execution crashes at EXCPT 0x0, which should be a system call, according
to Xenomai sources (syscall.h).
Xenomai version is 2.5.3, Linux 2.6.34.7, running on a Blackfin BF518
processor.
Note that everything works fine running the application without debugger.
Any hint?
This could be a pipeline (adeos) issue, or a Xenomai core issue.
Quite a bunch of nasty bugs were fixed since 2.5.3, and the interrupt
pipeline patch shipped with this release in ksrc/arch/blackfin/patches.
Some of them were even specific to ptracing a Xenomai application.
For narrowing the issue, I would suggest the following steps, incrementally:
- to upgrade the pipeline to this one, in case you are running any
earlier version:
http://download.gna.org/adeos/patches/v2.6/blackfin/older/adeos-ipipe-2.6.34-blackfin-1.15-01.patch
If the issue still shows up:
- to upgrade the Xenomai stack to 2.5.6.
I have a pipeline upgrade pending for the 3.2/blackfin kernel, so I'd be
interested to know whether that gremlin still hides in recent releases,
so that I might fix it prior to issuing that patch. I don't have any
bf518 at hand, but if you have any simple test code reproducing the
issue to send me, I could try it on my oldish bf561 in single core mode.
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] P2020RDB with 3.1.5 kernel oops
On 04/19/2012 03:07 PM, Roger Kalt wrote:
I've applied Xenomai patch from xenomai-head
commit 0ce3ed58074fa4d593ba556157d1edc288aff3f1
Author: Philippe Gerumr...@xenomai.org
Date: Wed Dec 14 10:46:27 2011 +0100
powerpc: upgrade I-pipe support to 3.0.13-powerpc-2.13-06,
ipipe-3.1.5-powerpc-2.13-06
to linux mainline 3.1.5 kernel.
The board is a P2020RDB where I've used defconfig: mpc85xx_smp_defconfig
Please advice.
Try disabling CONFIG_DEBUGGER.
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 0100 ...
Image Name: Linux-3.1.5-xenomai-KR84-mpc85xx
Created: 2012-04-19 12:37:26 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:3419182 Bytes = 3.3 MiB
Load Address:
Entry Point:
Verifying Checksum ... OK
## Flattened Device Tree blob at 00c0
Booting using the fdt blob at 0x00c0
Uncompressing Kernel Image ... OK
Loading Device Tree to 03ffa000, end 03fffb55 ... OK
WARNING: could not find compatible node fsl-usb2-dr: FDT_ERR_NOTFOUND.
Using P2020 RDB machine description
Memory CAM mapping: 256/256/256 Mb, residual: 256Mb
Linux version 3.1.5-xenomai-KR84-mpc85xx_defconfig-ipipe (kalt_r@pc7916) (gcc
version 4.6.1 20110627 (prerelease) (GCC) ) #1 SMP Thu Apr 19 14:36:41 CEST 2012
CPU maps initialized for 1 thread per core
bootconsole [udbg0] enabled
setup_arch: bootmem
mpc85xx_rdb_setup_arch()
Found FSL PCI host bridge at 0xffe0a000. Firmware bus number: 0-16
PCI host bridge /pcie@ffe0a000 ranges:
MEM 0xa000..0xdfff - 0xa000
IO 0xffc3..0xffc3 - 0x
/pcie@ffe0a000: PCICSRBAR @ 0xfff0
MPC85xx RDB board from Freescale Semiconductor
arch: exit
Zone PFN ranges:
DMA 0x - 0x0003
Normal empty
HighMem 0x0003 - 0x0004
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x - 0x0004
MMU: Allocated 1088 bytes of context maps for 255 contexts
PERCPU: Embedded 9 pages/cpu @c0f4c000 s14912 r8192 d13760 u36864
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096
Kernel command line: ip=dhcp root=/dev/nfs rw
nfsroot=129.129.145.35:/export/eldk9 console=ttyS0,115200
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1031932k/1048576k available (6900k kernel code, 16644k reserved, 196k
data, 333k bss, 276k init)
Kernel virtual memory layout:
* 0xfff5f000..0xf000 : fixmap
* 0xffc0..0xffe0 : highmem PTEs
* 0xffbec000..0xffc0 : early ioremap
* 0xf100..0xffbec000 : vmalloc ioremap
SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:512 nr_irqs:512 16
mpic: Setting up MPIC OpenPIC version 1.2 at ffe4, max 2 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
clocksource: timebase mult[355] shift[22] registered
I-pipe 2.13-06: pipeline enabled.
Console: colour dummy device 80x25
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
mpic: requesting IPIs...
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=8 P2020 RDB
Modules linked in:
NIP: LR: c000e924 CTR:
REGS: ef03fea0 TRAP: 0400 Not tainted
(3.1.5-xenomai-KR84-mpc85xx_defconfig-ipipe)
MSR: 00029000EE,ME,CE CR: 84044082 XER:
TASK = ef04[1] 'swapper' THREAD: ef03e000 CPU: 0
GPR00: ef03ff50 ef04 ef007e40 00fe
GPR08: ef008064 ef007e40 fffa 84044088 0649cac0
GPR16: 3ff926dc 3fe315b8 3fe313c8 3ffb0bf0 3ff37aa4 c06e8000
GPR24: c0f4c1c8 c06ec530 c06f ffea 00fe ef008000 0003
NIP [] (null)
LR [c000e924] __ipipe_register_ipi+0x38/0x48
Call Trace:
[ef03ff50] [c000e908] __ipipe_register_ipi+0x1c/0x48 (unreliable)
[ef03ff60] [c00112f8] smp_request_message_ipi+0x78/0xb8
[ef03ff80] [c001a108] mpic_request_ipis+0x64/0xa0
[ef03ffa0] [c067fdf4] smp_mpic_probe+0x2c/0x40
[ef03ffb0] [c067cf04] smp_prepare_cpus+0x178/0x18c
[ef03ffe0] [c067880c] kernel_init+0x50/0x12c
[ef03fff0] [c000e574] kernel_thread+0x4c/0x68
Instruction dump:
---[ end trace 31fd0ba7d8756001 ]---
Kernel panic - not syncing: Attempted to kill init!
Call Trace:
[ef03fd60] [c0008004] show_stack+0x4c/0x174 (unreliable)
[ef03fda0] [c04f85e4] panic+0xa8/0x1ec
[ef03fe00] [c004cb10] do_exit+0x648/0x728
[ef03fe60] [c000a730] die+0xfc/0x1f4
[ef03fe80] [c0014550] bad_page_fault+0xbc/0x110
[ef03fe90]
Re: [Xenomai-help] P2020RDB with 3.1.5 kernel oops
On 04/19/2012 03:57 PM, Philippe Gerum wrote:
On 04/19/2012 03:07 PM, Roger Kalt wrote:
I've applied Xenomai patch from xenomai-head
commit 0ce3ed58074fa4d593ba556157d1edc288aff3f1
Author: Philippe Gerumr...@xenomai.org
Date: Wed Dec 14 10:46:27 2011 +0100
powerpc: upgrade I-pipe support to 3.0.13-powerpc-2.13-06,
ipipe-3.1.5-powerpc-2.13-06
to linux mainline 3.1.5 kernel.
The board is a P2020RDB where I've used defconfig: mpc85xx_smp_defconfig
Please advice.
Try disabling CONFIG_DEBUGGER.
It's the opposite: try enabling it instead.
WARNING: adjusting available memory to 3000
## Booting kernel from Legacy Image at 0100 ...
Image Name: Linux-3.1.5-xenomai-KR84-mpc85xx
Created: 2012-04-19 12:37:26 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 3419182 Bytes = 3.3 MiB
Load Address:
Entry Point:
Verifying Checksum ... OK
## Flattened Device Tree blob at 00c0
Booting using the fdt blob at 0x00c0
Uncompressing Kernel Image ... OK
Loading Device Tree to 03ffa000, end 03fffb55 ... OK
WARNING: could not find compatible node fsl-usb2-dr: FDT_ERR_NOTFOUND.
Using P2020 RDB machine description
Memory CAM mapping: 256/256/256 Mb, residual: 256Mb
Linux version 3.1.5-xenomai-KR84-mpc85xx_defconfig-ipipe
(kalt_r@pc7916) (gcc
version 4.6.1 20110627 (prerelease) (GCC) ) #1 SMP Thu Apr 19 14:36:41
CEST 2012
CPU maps initialized for 1 thread per core
bootconsole [udbg0] enabled
setup_arch: bootmem
mpc85xx_rdb_setup_arch()
Found FSL PCI host bridge at 0xffe0a000. Firmware bus number:
0-16
PCI host bridge /pcie@ffe0a000 ranges:
MEM 0xa000..0xdfff - 0xa000
IO 0xffc3..0xffc3 - 0x
/pcie@ffe0a000: PCICSRBAR @ 0xfff0
MPC85xx RDB board from Freescale Semiconductor
arch: exit
Zone PFN ranges:
DMA 0x - 0x0003
Normal empty
HighMem 0x0003 - 0x0004
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x - 0x0004
MMU: Allocated 1088 bytes of context maps for 255 contexts
PERCPU: Embedded 9 pages/cpu @c0f4c000 s14912 r8192 d13760 u36864
Built 1 zonelists in Zone order, mobility grouping on. Total pages:
260096
Kernel command line: ip=dhcp root=/dev/nfs rw
nfsroot=129.129.145.35:/export/eldk9 console=ttyS0,115200
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1031932k/1048576k available (6900k kernel code, 16644k
reserved, 196k
data, 333k bss, 276k init)
Kernel virtual memory layout:
* 0xfff5f000..0xf000 : fixmap
* 0xffc0..0xffe0 : highmem PTEs
* 0xffbec000..0xffc0 : early ioremap
* 0xf100..0xffbec000 : vmalloc ioremap
SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:512 nr_irqs:512 16
mpic: Setting up MPIC OpenPIC version 1.2 at ffe4, max 2 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
clocksource: timebase mult[355] shift[22] registered
I-pipe 2.13-06: pipeline enabled.
Console: colour dummy device 80x25
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
mpic: requesting IPIs...
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=8 P2020 RDB
Modules linked in:
NIP: LR: c000e924 CTR:
REGS: ef03fea0 TRAP: 0400 Not tainted
(3.1.5-xenomai-KR84-mpc85xx_defconfig-ipipe)
MSR: 00029000EE,ME,CE CR: 84044082 XER:
TASK = ef04[1] 'swapper' THREAD: ef03e000 CPU: 0
GPR00: ef03ff50 ef04 ef007e40 00fe
GPR08: ef008064 ef007e40 fffa 84044088 0649cac0
GPR16: 3ff926dc 3fe315b8 3fe313c8 3ffb0bf0 3ff37aa4 c06e8000
GPR24: c0f4c1c8 c06ec530 c06f ffea 00fe ef008000
0003
NIP [] (null)
LR [c000e924] __ipipe_register_ipi+0x38/0x48
Call Trace:
[ef03ff50] [c000e908] __ipipe_register_ipi+0x1c/0x48 (unreliable)
[ef03ff60] [c00112f8] smp_request_message_ipi+0x78/0xb8
[ef03ff80] [c001a108] mpic_request_ipis+0x64/0xa0
[ef03ffa0] [c067fdf4] smp_mpic_probe+0x2c/0x40
[ef03ffb0] [c067cf04] smp_prepare_cpus+0x178/0x18c
[ef03ffe0] [c067880c] kernel_init+0x50/0x12c
[ef03fff0] [c000e574] kernel_thread+0x4c/0x68
Instruction dump:
---[ end trace 31fd0ba7d8756001 ]---
Kernel panic - not syncing: Attempted to kill init!
Call Trace:
[ef03fd60] [c0008004] show_stack+0x4c/0x174 (unreliable)
[ef03fda0] [c04f85e4] panic+0xa8/0x1ec
[ef03fe00] [c004cb10] do_exit+0x648/0x728
[ef03fe60] [c000a730] die+0xfc/0x1f4
[ef03fe80] [c0014550] bad_page_fault+0xbc/0x110
[ef03fe90] [c00108ac
Re: [Xenomai-help] kernel panic unload xeno_nucleus module
On 04/11/2012 10:58 AM, Alessio Margan @ IIT wrote: Hi all, when I try to unload xeno_nucleus module I get a kernel panic and on the next power on the bios system date is reset. when configure xenomai nucleus built into the kernel I can reboot correctly. Kernel panic log would help. In the bios I disabled HPET and most of the things regarding PM and ACPI. Here attached same info about system and kernel config. If possible, I prefer have xenomai configured as modules, is there anything wrong about my system configuration ? This should not be a configuration issue. Either some kernel-based Xenomai threads (e.g. RTDM driver thread) are still running when attempting to unload the nucleus, or a real-time IRQ is still hooked to a handler being unmapped, or there is a nucleus bug. TIA Alessio -- ISTITUTO ITALIANO DI TECNOLOGIA Alessio Margan /Senior Technician/ mail me mailto:alessio.mar...@iit.it Via Morego, 30 16163 Genova http://maps.google.com/maps?f=qhl=engeocode=q=via+morego,+30+genovasll=37.0625,-95.677068sspn=85.420533,191.601563ie=UTF8ll=44.474913,8.907037spn=0.004685,0.011652t=hz=17iwloc=addr www.iit.it http://www.iit.it *Legal Disclaimer* This electronic message contains information that is confidential. The information is intended for the use of the addressee only. If you are not the addressee we would appreciate your notification in this respect. Please note that any disclosure, copy, distribution or use of the contents of this message is prohibited and may be unlawful. We have taken every reasonable precaution to ensure that any kind of attachment to this e-mail has been swept for viruses. However, we cannot accept liability for any damage sustained as a result of software viruses and would advise you to carry out your own virus checks before opening any attachment. *Avvertenza legale* Questo messaggio Email contiene informazioni confidenziali riservate ai soli destinatari. Qualora veniate in possesso di tali informazioni senza essere definito come destinatario vi reghiamo di leggere le seguenti note. Ogni apertura, copia, distribuzione del contenuto del messaggio e dei suoi allegati è proibito e potrebbe violare le presenti leggi. Abbiamo attivato ogni possibile e ragionevole precauzione per assicurare che gli allegati non contengano virus. Comunque non assumeremo alcuna responsabilità per ogni eventuale danno causato da virus software e simili in quanto è onere del destinatario verificarne l’assenza in ogni allegato attuando propri indipendenti controlli. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] kernel panic unload xeno_nucleus module
On 04/11/2012 11:21 AM, Alessio Margan @ IIT wrote: On 04/11/2012 11:14 AM, Philippe Gerum wrote: On 04/11/2012 10:58 AM, Alessio Margan @ IIT wrote: Hi all, when I try to unload xeno_nucleus module I get a kernel panic and on the next power on the bios system date is reset. when configure xenomai nucleus built into the kernel I can reboot correctly. Kernel panic log would help. I'll try to get it In the bios I disabled HPET and most of the things regarding PM and ACPI. Here attached same info about system and kernel config. If possible, I prefer have xenomai configured as modules, is there anything wrong about my system configuration ? This should not be a configuration issue. Either some kernel-based Xenomai threads (e.g. RTDM driver thread) are still running when attempting to unload the nucleus, or a real-time IRQ is still hooked to a handler being unmapped, or there is a nucleus bug. after boot the only thing I do is load nucleus and unload it, no other xenomai modules are loaded Ok, so this must be a Xenomai bug. Thanks Alessio -- ISTITUTO ITALIANO DI TECNOLOGIA Alessio Margan /Senior Technician/ mail me mailto:alessio.mar...@iit.it Via Morego, 30 16163 Genova http://maps.google.com/maps?f=qhl=engeocode=q=via+morego,+30+genovasll=37.0625,-95.677068sspn=85.420533,191.601563ie=UTF8ll=44.474913,8.907037spn=0.004685,0.011652t=hz=17iwloc=addr www.iit.it http://www.iit.it *Legal Disclaimer* This electronic message contains information that is confidential. The information is intended for the use of the addressee only. If you are not the addressee we would appreciate your notification in this respect. Please note that any disclosure, copy, distribution or use of the contents of this message is prohibited and may be unlawful. We have taken every reasonable precaution to ensure that any kind of attachment to this e-mail has been swept for viruses. However, we cannot accept liability for any damage sustained as a result of software viruses and would advise you to carry out your own virus checks before opening any attachment. *Avvertenza legale* Questo messaggio Email contiene informazioni confidenziali riservate ai soli destinatari. Qualora veniate in possesso di tali informazioni senza essere definito come destinatario vi reghiamo di leggere le seguenti note. Ogni apertura, copia, distribuzione del contenuto del messaggio e dei suoi allegati è proibito e potrebbe violare le presenti leggi. Abbiamo attivato ogni possibile e ragionevole precauzione per assicurare che gli allegati non contengano virus. Comunque non assumeremo alcuna responsabilità per ogni eventuale danno causato da virus software e simili in quanto è onere del destinatario verificarne l’assenza in ogni allegato attuando propri indipendenti controlli. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] kernel panic unload xeno_nucleus module
On 04/11/2012 11:21 AM, Alessio Margan @ IIT wrote: On 04/11/2012 11:14 AM, Philippe Gerum wrote: On 04/11/2012 10:58 AM, Alessio Margan @ IIT wrote: Hi all, when I try to unload xeno_nucleus module I get a kernel panic and on the next power on the bios system date is reset. when configure xenomai nucleus built into the kernel I can reboot correctly. Kernel panic log would help. I'll try to get it In the bios I disabled HPET and most of the things regarding PM and ACPI. Here attached same info about system and kernel config. If possible, I prefer have xenomai configured as modules, is there anything wrong about my system configuration ? This should not be a configuration issue. Either some kernel-based Xenomai threads (e.g. RTDM driver thread) are still running when attempting to unload the nucleus, or a real-time IRQ is still hooked to a handler being unmapped, or there is a nucleus bug. after boot the only thing I do is load nucleus and unload it, no other xenomai modules are loaded Btw, you should try with the latest Xenomai code from the 2.6.x maintenance branch, to make sure this has not been fixed already. git://git.xenomai.org/xenomai-2.6.git Thanks Alessio -- ISTITUTO ITALIANO DI TECNOLOGIA Alessio Margan /Senior Technician/ mail me mailto:alessio.mar...@iit.it Via Morego, 30 16163 Genova http://maps.google.com/maps?f=qhl=engeocode=q=via+morego,+30+genovasll=37.0625,-95.677068sspn=85.420533,191.601563ie=UTF8ll=44.474913,8.907037spn=0.004685,0.011652t=hz=17iwloc=addr www.iit.it http://www.iit.it *Legal Disclaimer* This electronic message contains information that is confidential. The information is intended for the use of the addressee only. If you are not the addressee we would appreciate your notification in this respect. Please note that any disclosure, copy, distribution or use of the contents of this message is prohibited and may be unlawful. We have taken every reasonable precaution to ensure that any kind of attachment to this e-mail has been swept for viruses. However, we cannot accept liability for any damage sustained as a result of software viruses and would advise you to carry out your own virus checks before opening any attachment. *Avvertenza legale* Questo messaggio Email contiene informazioni confidenziali riservate ai soli destinatari. Qualora veniate in possesso di tali informazioni senza essere definito come destinatario vi reghiamo di leggere le seguenti note. Ogni apertura, copia, distribuzione del contenuto del messaggio e dei suoi allegati è proibito e potrebbe violare le presenti leggi. Abbiamo attivato ogni possibile e ragionevole precauzione per assicurare che gli allegati non contengano virus. Comunque non assumeremo alcuna responsabilità per ogni eventuale danno causato da virus software e simili in quanto è onere del destinatario verificarne l’assenza in ogni allegato attuando propri indipendenti controlli. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Is it compulsory to apply the PREEMPT_RT patch (to Linux) when running Xenomai on the top of it?
On 04/03/2012 08:56 AM, Anisha Kaul wrote: Greetings, From Life with Adeos: http://www.xenomai.org/documentation/branches/v2.3.x/pdf/Life-with-Adeos-rev-B.pdf Both the realtime nucleus and the Linux kernel should handle the case where a high priority thread is kept from running because a low priority one holds a contended resource for a possibly unbounded amount of time. Xenomai provides this support, but only the PREEMPT_RT variant does so for the Linux kernel. For this reason, Xenomai keeps an eye and provides support for the current developments of PREEMPT_RT, albeit the mainline kernel still remains the system of reference for now. I don't understand whether the above quote implies that it necessary to apply the PREEMPT_RT patch (to Linux) when working with Xenomai on Linux? Please guide. No. -Anisha ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Is it compulsory to apply the PREEMPT_RT patch (to Linux) when running Xenomai on the top of it?
On 04/03/2012 09:17 AM, Philippe Gerum wrote: On 04/03/2012 08:56 AM, Anisha Kaul wrote: Greetings, From Life with Adeos: http://www.xenomai.org/documentation/branches/v2.3.x/pdf/Life-with-Adeos-rev-B.pdf Both the realtime nucleus and the Linux kernel should handle the case where a high priority thread is kept from running because a low priority one holds a contended resource for a possibly unbounded amount of time. Xenomai provides this support, but only the PREEMPT_RT variant does so for the Linux kernel. For this reason, Xenomai keeps an eye and provides support for the current developments of PREEMPT_RT, albeit the mainline kernel still remains the system of reference for now. I don't understand whether the above quote implies that it necessary to apply the PREEMPT_RT patch (to Linux) when working with Xenomai on Linux? Please guide. No. I mean: this is not implied, and you don't need _RT (actually, to have it, you would need a specific interrupt pipeline patch). -Anisha ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Is it compulsory to apply the PREEMPT_RT patch (to Linux) when running Xenomai on the top of it?
On 04/03/2012 09:37 AM, Anisha Kaul wrote: On 3 April 2012 12:48, Philippe Gerumr...@xenomai.org wrote: No. I mean: this is not implied, and you don't need _RT (actually, to have it, you would need a specific interrupt pipeline patch). Thanks for replying. I read that this patch allows nearly all of the kernel to be preempted, with the exception of a few very small regions of code (raw_spinlock critical regions), can you please point out a few cases in which actually we should apply this patch? Xenomai already gives a hard real time, so why would we need this patch? Any hints please? This is a different approach to a same problem: - _RT attempts to make the whole regular kernel real-time aware. - Xenomai 2.x provides a co-kernel for exclusively handling real-time processing. There are pros and cons in the two approaches, this is basically why Xenomai 3 will allow both. -Anisha -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt latency greater than 250ms. Question.
On 03/28/2012 08:23 PM, Makarand Pradhan wrote: Hi Philippe, On 28/03/12 12:17 PM, Philippe Gerum wrote: The log says your code wants to control when the IRQ is enabled again, by calling rt_intr_enable() from userland. I guess you are setting I_NOAUTOENA too. Correct? That is correct. I_NOAUTOENA is used in rt_intr_create. Otherwise the level trigerred interrupt will not allow the userland processing of the int. The userland handler is very small and it unconditionally rt_intr_enables the intr. Testing indicates that the interrupt is always enabled from user space within 250 usec after kernel gets the interrupt. I have noted that unless I see #end 0x002b and a hit to the ipic_unmask_irq, the next interrupt is not processed. And this is getting delayed once in a while which causes a delay in processing the next interrupt. So the sequence of events leading to the problem is: 1. Get interrupt: #begin 0x002b noted in ipipe trace 2. Intr enabled from user space. Always happens roughly within 250usec. 3. #end 0x002b noted in ipipe trace where the int is unmasked by ipipe. When I see the problem, step 3 is delayed. I am trying to capture a trace where the begin, int enable and end are captured. Your thoughts on what might cause this delay would be appreciated. Which IRQ are you re-enabling from user-space, the multiplexed IRQ 33, or the cascaded one you receive? Rgds, Mak. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Intermixing native and POSIX skins
On 03/27/2012 11:35 PM, Doug Brunner wrote: The usage pattern would be a bit like BSD ptys--the server maintains a few ports, say named server0 through server15 and clients that need a port try server0, if it's busy then try server1, etc.. An option to mimic this partially might be to define a fixed port number clients would use to ask the server for a free port to connect to later on? The server would let the RTIPC layer pick a free port when binding, then return it to the client via a converse message to the fixed port. I suppose the problem here is really that the application running over these sockets is stateful, the configuration of the nodes (processes) that are communicating is not known until run time, and nodes may appear and disappear as the server runs, so the transport needs to be connection-oriented rather than message-oriented. The semaphore is still a bit of a kludge, since it doesn't notify a thread blocked on recv() that the remote has hung up, but it works well enough in conjunction with a message that says I'm a client that's newly connected to this server to reset the state associated with the connection. I suppose I could implement a sort of TCP handshake on top of the IDDP socket layer and use that to provide true connection-oriented behavior. Yep, RTIPC won't help that much by default in that area, it only exhibits connectionless semantics. Good to know about in-order delivery; a quick glance at the source code seemed to suggest that, but I wasn't sure. Doug Brunner -Original Message- From: Philippe Gerumr...@xenomai.org Sent: Tuesday, March 27, 2012 9:26am To: Doug Brunnerdbrun...@ebus.com Cc: xenomai-help@gna.org Subject: Re: [Xenomai-help] Intermixing native and POSIX skins On 03/26/2012 06:14 PM, Doug Brunner wrote: Thanks for the information--the issue is not about picking a free port on the server side, but rather about communicating the information on which ports are free to the clients (server has connected its end, but no other client is using the port). The semaphore mechanism isn't that much of a problem, though; I've been able to build a satisfactory implementation. Mm, still scratching my head to understand the issue. Both the client and server side accept -1 as the port spec, telling the kernel to draw a free port. I understand the issue is not on the server side, so is it on the client side? Could you sketch the usage pattern? One other question: although I know in-order delivery isn't necessarily a feature of datagram based protocols, would I get that with an IDDP socket connection between just two processes, and/or an XDDP connection to a /dev/rtpN? Yes, in-order delivery is guaranteed with all RTIPC protocols. This is written in stone. Doug Brunner -Original Message- From: Philippe Gerumr...@xenomai.org Sent: Friday, March 16, 2012 11:29am To: Doug Brunnerdbrun...@ebus.com Cc: xenomai-help@gna.org Subject: Re: [Xenomai-help] Intermixing native and POSIX skins On 03/15/2012 05:30 PM, Doug Brunner wrote: Thanks Philippe. I hadn't even known about the existence of the RTIPC driver, and I definitely like the idea. I've been experimenting with it a bit today, and found that it seems to be allowed for more than two sockets to connect to the same port. I modified iddp-sendrecv.c to have two client processes, both of which now connect to the same port as the server, then did the same thing with iddp-label.c (two clients both connect()ing to the same label). This would cause havoc with the communications that go on between my processes--they need a one-to-one channel. I could implement semaphores to enforce this, but it would be nice to avoid that complication. Is there a way to make it happen using just the socket interface? The RTIPC protocols are fundamentally datagram-based, so allowing N:1 data paths is wanted. If the issue is about picking a different port each time you bind a server socket in the AF_RTIPC domain, then I would suggest to set sipc_port to -1 when binding the server-side socket: a free port will be picked automatically. You could then use getsockname() to retrieve the actual port #, and pass it to the clients. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt latency greater than 250ms. Question.
On 03/28/2012 05:53 PM, Makarand Pradhan wrote: Hi All, I am working with MPC8360, Linux 3.0.0, Xenomai 2.6. I am experiencing delays as high as 250ms in processing interrupt 43 (2b). Interrupt 43 indicates that the power quicc engine has transmitted/received a frame. This interrupt is being handled in Xenomai. The ipipe trace indicates that ipipe has kept the interrupt masked which may be the cause of the problem. The problem is seen intermittently after upgrading to Xenomai 2.6. This problem was never seen in Xenomai 2.4.10. * Normal operation:* Under normal operation, the irq is unmasked roughly within 300usecs. after it is masked on receipt of an int: e.g. From attached file: *good_int2b_ipipe_frozen* The log says your code wants to control when the IRQ is enabled again, by calling rt_intr_enable() from userland. I guess you are setting I_NOAUTOENA too. Correct? Int masked for 647 - 370 = 277 usec Int received: :| +begin 0x002b *-647 * 0.590 __ipipe_qe_ic_cascade_irq+0x2c (qe_ic_cascade_low_ipic+0x5c) :| +func -646 0.575 __ipipe_handle_irq+0x8 (__ipipe_qe_ic_cascade_irq+0x38) :| +func -646 0.787 __ipipe_ack_level_irq+0x8 (__ipipe_handle_irq+0xbc) :| +func -645 0.666 qe_ic_mask_irq+0x8 (__ipipe_ack_level_irq+0x40) Int unmasked: :| +end 0x002b *-370*+ 1.151 __ipipe_qe_ic_cascade_irq+0x40 (qe_ic_cascade_low_ipic+0x5c) :| +func -369 0.742 ipic_unmask_irq+0x8 (qe_ic_cascade_low_ipic+0x70) *Problem scenario:* The ipipe trace indicates that the irq stayed masked for a long time: From: bad_int2b_ipipe_frozen The int stayed masked for more than 50ms after which it was unmasked: Int received: No begin 0x002b for more than 50ms. So the int has occurred more than 50ms ago. Int unmasked: :| #end 0x002b -434+ 2.272 __ipipe_qe_ic_cascade_irq+0x40 (qe_ic_cascade_low_ipic+0x5c) :| #func -432+ 1.212 ipic_unmask_irq+0x8 (qe_ic_cascade_low_ipic+0x70) The ipipe traces are attached to this email for reference. Can you please help me understand the cause for this behavior? Any pointers would be appreciated. The interrupt is being handled in user space thorugh rt_intr_wait. Do I need to invoke a rt call to tell ipipe to unmask the intr? Please feel free to correct me if the traces are being interpreted wrongly. Warm Rgds, Mak. -- ___ NOTICE OF CONFIDENTIALITY: This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail and delete this e-mail and any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. _ ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Intermixing native and POSIX skins
On 03/26/2012 06:14 PM, Doug Brunner wrote: Thanks for the information--the issue is not about picking a free port on the server side, but rather about communicating the information on which ports are free to the clients (server has connected its end, but no other client is using the port). The semaphore mechanism isn't that much of a problem, though; I've been able to build a satisfactory implementation. Mm, still scratching my head to understand the issue. Both the client and server side accept -1 as the port spec, telling the kernel to draw a free port. I understand the issue is not on the server side, so is it on the client side? Could you sketch the usage pattern? One other question: although I know in-order delivery isn't necessarily a feature of datagram based protocols, would I get that with an IDDP socket connection between just two processes, and/or an XDDP connection to a /dev/rtpN? Yes, in-order delivery is guaranteed with all RTIPC protocols. This is written in stone. Doug Brunner -Original Message- From: Philippe Gerumr...@xenomai.org Sent: Friday, March 16, 2012 11:29am To: Doug Brunnerdbrun...@ebus.com Cc: xenomai-help@gna.org Subject: Re: [Xenomai-help] Intermixing native and POSIX skins On 03/15/2012 05:30 PM, Doug Brunner wrote: Thanks Philippe. I hadn't even known about the existence of the RTIPC driver, and I definitely like the idea. I've been experimenting with it a bit today, and found that it seems to be allowed for more than two sockets to connect to the same port. I modified iddp-sendrecv.c to have two client processes, both of which now connect to the same port as the server, then did the same thing with iddp-label.c (two clients both connect()ing to the same label). This would cause havoc with the communications that go on between my processes--they need a one-to-one channel. I could implement semaphores to enforce this, but it would be nice to avoid that complication. Is there a way to make it happen using just the socket interface? The RTIPC protocols are fundamentally datagram-based, so allowing N:1 data paths is wanted. If the issue is about picking a different port each time you bind a server socket in the AF_RTIPC domain, then I would suggest to set sipc_port to -1 when binding the server-side socket: a free port will be picked automatically. You could then use getsockname() to retrieve the actual port #, and pass it to the clients. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/21/2012 05:46 AM, Glen Wernersbach wrote: I am going to start trying to see if I can figure out what is not getting set. You could get useful information from the pipeline tracer, by enabling CONFIG_IPIPE_TRACE, observing what exactly happens in kernel space from the issuing of the ioctl() syscall until the the read() syscall on the serial link. You could set markers using Xenomai's I-pipe trace API in userland to highlight portions of interest in your app code, freezing the capture to snapshot a particular moment in the execution timeline. See http://xenomai.org/index.php/I-pipe:Tracer. NOTE: pay attention to the value in /proc/ipipe/trace/back_trace_points to hold enough data. By the way. This board also has 4 other serial ports on a 8250.c driver. It also fails under the xeno build. On 3/20/12 4:35 PM, Gilles Chanteperdrix gilles.chanteperd...@xenomai.org wrote: On 03/20/2012 09:19 PM, Glen Wernersbach wrote: I actually think in is in the settings because if run just the setup part of the code without reading and writing, on the kernel that works my activity LED turns off. On the xeno kernel the LED never changes. I actually think that CONFIG_XENO_OPT_PERVASIVE does not make any difference which could cause a difference of hardware behaviour. So, it must be another option triggered by this config change. So, if you want us to help you, please post the .configs. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/21/2012 03:41 PM, Glen Wernersbach wrote: Hi guys, One thing about both of these drivers is they have been modified to set some GPIO pins. The come down to the pca9539_gpio_set_value() in this file. Do you see any reason why those would not take under Xenomai? If these are input GPIOs to deliver IRQs, yes, in which case this might be a problem with the interrupt pipeline; as Gilles told you already, 1.13 is fairly outdated. But in that case, you should see the problem even with CONFIG_XENOMAI* fully disabled, provided CONFIG_IPIPE is still on. If you don't, meaning that something in the Xenomai core does make a difference, then you could try disabling all Xenomai interfaces (i.e. CONFIG_XENO_OPEN_SKIN_RTDM, .._NATIVE, .._POSIX, etc.), only leaving the core enabled. Glen On 3/21/12 4:38 AM, Philippe Gerumr...@xenomai.org wrote: On 03/21/2012 05:46 AM, Glen Wernersbach wrote: I am going to start trying to see if I can figure out what is not getting set. You could get useful information from the pipeline tracer, by enabling CONFIG_IPIPE_TRACE, observing what exactly happens in kernel space from the issuing of the ioctl() syscall until the the read() syscall on the serial link. You could set markers using Xenomai's I-pipe trace API in userland to highlight portions of interest in your app code, freezing the capture to snapshot a particular moment in the execution timeline. See http://xenomai.org/index.php/I-pipe:Tracer. NOTE: pay attention to the value in /proc/ipipe/trace/back_trace_points to hold enough data. By the way. This board also has 4 other serial ports on a 8250.c driver. It also fails under the xeno build. On 3/20/12 4:35 PM, Gilles Chanteperdrix gilles.chanteperd...@xenomai.org wrote: On 03/20/2012 09:19 PM, Glen Wernersbach wrote: I actually think in is in the settings because if run just the setup part of the code without reading and writing, on the kernel that works my activity LED turns off. On the xeno kernel the LED never changes. I actually think that CONFIG_XENO_OPT_PERVASIVE does not make any difference which could cause a difference of hardware behaviour. So, it must be another option triggered by this config change. So, if you want us to help you, please post the .configs. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 02:28 PM, Glen Wernersbach wrote: Hi All, I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux serial write then read serial program does not work. If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work. Any ideas why? A possible explanation would be that your application links with the Xenomai POSIX lib (libpthread_rt), albeit it should not. With pervasive support disabled, any routing from the overloaded POSIX I/O calls to the Xenomai kernel would then fail. If so, you should not link against the Xenomai libs if you need no -rt service, or prevent symbol wrapping only for the POSIX I/O calls by prefixing them by __real_* if you want Xenomai-enabled POSIX services except the I/O support. See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error: CC kernel/xenomai/nucleus/synch.o kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread': kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of function 'xnthread_get_rescnt' kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of function 'xnshadow_send_sig' I had to go in and make the code for that option befor it always false. http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a788b762b5cf662b1d4108 Glen -- Glen Wernersbach President CTO Jetsoft Development Co. 629 Old St Rt. 74 – Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 Cell 513-240-9929 Partner for Software Technology Jacobs Automation 2365 Progress Drive Hebron, KY 41048 (513) 297-7550 Support Dyslexia Research ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 02:48 PM, Glen Wernersbach wrote: I don't think this is it directly. This program was made on the same kernel prior to patching it with Xeno. It should still run like any other linux program. - what does program not working mean in your case? Any errno return we could interpret? Any strace output? - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on? On 3/20/12 9:44 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 02:28 PM, Glen Wernersbach wrote: Hi All, I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux serial write then read serial program does not work. If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work. Any ideas why? A possible explanation would be that your application links with the Xenomai POSIX lib (libpthread_rt), albeit it should not. With pervasive support disabled, any routing from the overloaded POSIX I/O calls to the Xenomai kernel would then fail. If so, you should not link against the Xenomai libs if you need no -rt service, or prevent symbol wrapping only for the POSIX I/O calls by prefixing them by __real_* if you want Xenomai-enabled POSIX services except the I/O support. See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error: CC kernel/xenomai/nucleus/synch.o kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread': kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of function 'xnthread_get_rescnt' kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of function 'xnshadow_send_sig' I had to go in and make the code for that option befor it always false. http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a788b76 2b5cf662b1d4108 Glen -- Glen Wernersbach President CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 Cell 513-240-9929 Partner for Software Technology Jacobs Automation 2365 Progress Drive Hebron, KY 41048 (513) 297-7550 Support Dyslexia Research ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 03:07 PM, Glen Wernersbach wrote: I went through and disabled everything in xeno except CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it works. Take that option out at anytime it works. My program basic writes a few characters a serial port and then reads them back in from the same port. I have a loop back cable connected to the port. It writes the data but waits forever to read them back in Ok, so what about answering the questions below? From my tests, it appears that the termois tcsetaddr settings is not getting set when I call it when this option is on. On 3/20/12 9:57 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 02:48 PM, Glen Wernersbach wrote: I don't think this is it directly. This program was made on the same kernel prior to patching it with Xeno. It should still run like any other linux program. - what does program not working mean in your case? Any errno return we could interpret? Any strace output? - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on? On 3/20/12 9:44 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 02:28 PM, Glen Wernersbach wrote: Hi All, I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux serial write then read serial program does not work. If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work. Any ideas why? A possible explanation would be that your application links with the Xenomai POSIX lib (libpthread_rt), albeit it should not. With pervasive support disabled, any routing from the overloaded POSIX I/O calls to the Xenomai kernel would then fail. If so, you should not link against the Xenomai libs if you need no -rt service, or prevent symbol wrapping only for the POSIX I/O calls by prefixing them by __real_* if you want Xenomai-enabled POSIX services except the I/O support. See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error: CC kernel/xenomai/nucleus/synch.o kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread': kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of function 'xnthread_get_rescnt' kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of function 'xnshadow_send_sig' I had to go in and make the code for that option befor it always false. http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a788b 76 2b5cf662b1d4108 Glen -- Glen Wernersbach President CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 Cell 513-240-9929 Partner for Software Technology Jacobs Automation 2365 Progress Drive Hebron, KY 41048 (513) 297-7550 Support Dyslexia Research ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 03:07 PM, Glen Wernersbach wrote: I went through and disabled everything in xeno except CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it works. Take that option out at anytime it works. My program basic writes a few characters a serial port and then reads them back in from the same port. I have a loop back cable connected to the port. It writes the data but waits forever to read them back in From my tests, it appears that the termois tcsetaddr settings is not getting set when I call it when this option is on. Can you strace your app when it runs, please? On 3/20/12 9:57 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 02:48 PM, Glen Wernersbach wrote: I don't think this is it directly. This program was made on the same kernel prior to patching it with Xeno. It should still run like any other linux program. - what does program not working mean in your case? Any errno return we could interpret? Any strace output? - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on? On 3/20/12 9:44 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 02:28 PM, Glen Wernersbach wrote: Hi All, I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux serial write then read serial program does not work. If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work. Any ideas why? A possible explanation would be that your application links with the Xenomai POSIX lib (libpthread_rt), albeit it should not. With pervasive support disabled, any routing from the overloaded POSIX I/O calls to the Xenomai kernel would then fail. If so, you should not link against the Xenomai libs if you need no -rt service, or prevent symbol wrapping only for the POSIX I/O calls by prefixing them by __real_* if you want Xenomai-enabled POSIX services except the I/O support. See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error: CC kernel/xenomai/nucleus/synch.o kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread': kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of function 'xnthread_get_rescnt' kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of function 'xnshadow_send_sig' I had to go in and make the code for that option befor it always false. http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a788b 76 2b5cf662b1d4108 Glen -- Glen Wernersbach President CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 Cell 513-240-9929 Partner for Software Technology Jacobs Automation 2365 Progress Drive Hebron, KY 41048 (513) 297-7550 Support Dyslexia Research ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 03:17 PM, Philippe Gerum wrote: On 03/20/2012 03:07 PM, Glen Wernersbach wrote: I went through and disabled everything in xeno except CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it works. Take that option out at anytime it works. My program basic writes a few characters a serial port and then reads them back in from the same port. I have a loop back cable connected to the port. It writes the data but waits forever to read them back in From my tests, it appears that the termois tcsetaddr settings is not getting set when I call it when this option is on. Can you strace your app when it runs, please? The interrupt pipeline release number would help as well (/proc/xenomai/hal). On 3/20/12 9:57 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 02:48 PM, Glen Wernersbach wrote: I don't think this is it directly. This program was made on the same kernel prior to patching it with Xeno. It should still run like any other linux program. - what does program not working mean in your case? Any errno return we could interpret? Any strace output? - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on? On 3/20/12 9:44 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 02:28 PM, Glen Wernersbach wrote: Hi All, I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux serial write then read serial program does not work. If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work. Any ideas why? A possible explanation would be that your application links with the Xenomai POSIX lib (libpthread_rt), albeit it should not. With pervasive support disabled, any routing from the overloaded POSIX I/O calls to the Xenomai kernel would then fail. If so, you should not link against the Xenomai libs if you need no -rt service, or prevent symbol wrapping only for the POSIX I/O calls by prefixing them by __real_* if you want Xenomai-enabled POSIX services except the I/O support. See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error: CC kernel/xenomai/nucleus/synch.o kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread': kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of function 'xnthread_get_rescnt' kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of function 'xnshadow_send_sig' I had to go in and make the code for that option befor it always false. http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a788b 76 2b5cf662b1d4108 Glen -- Glen Wernersbach President CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 Cell 513-240-9929 Partner for Software Technology Jacobs Automation 2365 Progress Drive Hebron, KY 41048 (513) 297-7550 Support Dyslexia Research ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] How do I increase CPU time limit.
On 03/20/2012 03:09 PM, Chris Stone wrote: I have a thread which uses a lot of CPU and it is receiving a SIGXCPU: Cpu time limit exceeded. Does this message really mean I have exceeded some CPU time limit? If so, how do I increase or disable the CPU time limit? The code that I am running has been working for quite some time under regular Linux and I have just ported it to Xenomai, so I doubt there are any infinite loops in it. This could be the runaway thread detector triggering, after 4s of uninterrupted runtime (which is huge, is this intended?). This is a debug mechanism Xenomai implements to recover from a runaway thread chewing CPU in primary mode, without having to resort to the reset button. You can either extend the grace period above the default 4s, using CONFIG_XENO_OPT_WATCHDOG_TIMEOUT, or disable the watchdog entirely by switching off CONFIG_XENO_OPT_WATCHDOG. This said, 4s is really long already, so the regular kernel might not cope with even more starvation from normal interrupts. Other explanation would be not time-related. If CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX is enabled, any attempt to switch to secondary mode while holding a real-time (Xenomai created) mutex in the code would trigger such signal, as a warning to point out a priority inversion. *Chris Stone* Senior Software Engineer Optelian 1 Brewer Hunt Way Ottawa, Ontario K2K 2B5 Phone: 613-287-2000 x2106 _www.optelian.com http://www.optelian.com_ ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 03:34 PM, Glen Wernersbach wrote: Working on the Strace. I don't have the /proc/xenomai/hal file?? /proc/ipipe/version then. Again. Nothing I am running is xeno. Its just a xeno patched kernel. Ok, but you do have the Xenomai co-kernel enabled in your kernel build, and the interrupt pipeline is enabled as well, right? On 3/20/12 10:31 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 03:17 PM, Philippe Gerum wrote: On 03/20/2012 03:07 PM, Glen Wernersbach wrote: I went through and disabled everything in xeno except CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it works. Take that option out at anytime it works. My program basic writes a few characters a serial port and then reads them back in from the same port. I have a loop back cable connected to the port. It writes the data but waits forever to read them back in From my tests, it appears that the termois tcsetaddr settings is not getting set when I call it when this option is on. Can you strace your app when it runs, please? The interrupt pipeline release number would help as well (/proc/xenomai/hal). On 3/20/12 9:57 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 02:48 PM, Glen Wernersbach wrote: I don't think this is it directly. This program was made on the same kernel prior to patching it with Xeno. It should still run like any other linux program. - what does program not working mean in your case? Any errno return we could interpret? Any strace output? - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on? On 3/20/12 9:44 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 02:28 PM, Glen Wernersbach wrote: Hi All, I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux serial write then read serial program does not work. If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work. Any ideas why? A possible explanation would be that your application links with the Xenomai POSIX lib (libpthread_rt), albeit it should not. With pervasive support disabled, any routing from the overloaded POSIX I/O calls to the Xenomai kernel would then fail. If so, you should not link against the Xenomai libs if you need no -rt service, or prevent symbol wrapping only for the POSIX I/O calls by prefixing them by __real_* if you want Xenomai-enabled POSIX services except the I/O support. See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error: CC kernel/xenomai/nucleus/synch.o kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread': kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of function 'xnthread_get_rescnt' kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of function 'xnshadow_send_sig' I had to go in and make the code for that option befor it always false. http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a7 88b 76 2b5cf662b1d4108 Glen -- Glen Wernersbach President CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 Cell 513-240-9929 Partner for Software Technology Jacobs Automation 2365 Progress Drive Hebron, KY 41048 (513) 297-7550 Support Dyslexia Research ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 03:53 PM, Glen Wernersbach wrote: Ipipe version: 1.13-05 Yes, I do have the co kernel and interrupt pipeline enabled ldd your-serial-app ? On 3/20/12 10:47 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 03:34 PM, Glen Wernersbach wrote: Working on the Strace. I don't have the /proc/xenomai/hal file?? /proc/ipipe/version then. Again. Nothing I am running is xeno. Its just a xeno patched kernel. Ok, but you do have the Xenomai co-kernel enabled in your kernel build, and the interrupt pipeline is enabled as well, right? On 3/20/12 10:31 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 03:17 PM, Philippe Gerum wrote: On 03/20/2012 03:07 PM, Glen Wernersbach wrote: I went through and disabled everything in xeno except CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it works. Take that option out at anytime it works. My program basic writes a few characters a serial port and then reads them back in from the same port. I have a loop back cable connected to the port. It writes the data but waits forever to read them back in From my tests, it appears that the termois tcsetaddr settings is not getting set when I call it when this option is on. Can you strace your app when it runs, please? The interrupt pipeline release number would help as well (/proc/xenomai/hal). On 3/20/12 9:57 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 02:48 PM, Glen Wernersbach wrote: I don't think this is it directly. This program was made on the same kernel prior to patching it with Xeno. It should still run like any other linux program. - what does program not working mean in your case? Any errno return we could interpret? Any strace output? - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on? On 3/20/12 9:44 AM, Philippe Gerumr...@xenomai.org wrote: On 03/20/2012 02:28 PM, Glen Wernersbach wrote: Hi All, I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux serial write then read serial program does not work. If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work. Any ideas why? A possible explanation would be that your application links with the Xenomai POSIX lib (libpthread_rt), albeit it should not. With pervasive support disabled, any routing from the overloaded POSIX I/O calls to the Xenomai kernel would then fail. If so, you should not link against the Xenomai libs if you need no -rt service, or prevent symbol wrapping only for the POSIX I/O calls by prefixing them by __real_* if you want Xenomai-enabled POSIX services except the I/O support. See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error: CC kernel/xenomai/nucleus/synch.o kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread': kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of function 'xnthread_get_rescnt' kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of function 'xnshadow_send_sig' I had to go in and make the code for that option befor it always false. http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107 a7 88b 76 2b5cf662b1d4108 Glen -- Glen Wernersbach President CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 Cell 513-240-9929 Partner for Software Technology Jacobs Automation 2365 Progress Drive Hebron, KY 41048 (513) 297-7550 Support Dyslexia Research ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 04:17 PM, Glen Wernersbach wrote:
Don't have a full dev enviroment on my embedded arm. Here is the
program. Very very basic:
Ok, actually I was after the link flags used for building this app.
---
#include stdio.h
#include termios.h
#include errno.h
#include fcntl.h
/*Artila*/
#define MATRIX500_GET_UART_TYPE 0xe001
#define MATRIX500_SET_UART_TYPE 0xe002
#define MATRIX500_GET_UART_MODE9 0xe003
#define MATRIX500_SET_UART_MODE9 0xe004
#define MATRIX500_UART_SET_BAUD 0xe006
#define MATRIX500_UART_TYPE_232 232
#define MATRIX500_UART_TYPE_422 422
#define MATRIX500_UART_TYPE_485 485
int
main(argc, argv)
int argc;
char *argv[];
{
int fd, ret;
struct termios term;
char buf[]=XBCDEFHIJKM\0;
char buf2[1024] ;
struct termios T_new;
/*open tty port*/
fd = open(/dev/ttyS4, O_RDWR | O_NOCTTY | O_NDELAY);
if (fd == -1) {
printf(open /dev/ttyS0 Failed, errno: %d\r\n, errno);
return 0;
}
unsigned long interface2=0;
ioctl(fd, MATRIX500_GET_UART_TYPE, interface2) ;
printf(set UART type: %d...Failed, errno: %d\r\n, interface2, errno);
/*set serial interface: RS-422*/
interface2 = MATRIX500_UART_TYPE_422;
if(ioctl(fd, MATRIX500_SET_UART_TYPE, interface2) != 0) {
printf(set UART type: %d...Failed, errno: %d\r\n, interface2, errno);
close(fd);
return 0;
}
unsigned long mode9 = 0;
ioctl(fd, MATRIX500_GET_UART_MODE9, mode9);
printf(mode: %d...Failed, errno: %d\r\n, mode9, errno);
mode9=0;
if (ioctl(fd, MATRIX500_SET_UART_MODE9, mode9)!= 0) {
printf(mode: %d...Failed, errno: %d\r\n, mode9, errno);
close(fd);
return 0;
}
//it appears this is not getting set but no error.
if(tcgetattr(fd,term) != 0) {
printf(tcgetattr failed\n);
}
term.c_cflag = (B921600 | CS8 | CREAD | CLOCAL | HUPCL);
term.c_oflag = 0;
term.c_iflag = 0;
term.c_lflag = 0;
if(tcsetattr(fd,TCSANOW,term) != 0) {
printf(tcsetattr failed\n);
}
//set baud rate at 4 times 921.6m
unsigned long baud = 921600UL*4;
if (ioctl(fd , MATRIX500_UART_SET_BAUD , baud ) != 0) {
printf(set baud: %d...Failed, errno: %d\r\n, baud, errno);
close(fd);
return 0;
}
close(fd);
fd = open(/dev/ttyS4, O_RDWR | O_NOCTTY | O_NDELAY);
if (fd == -1) {
printf(open /dev/ttyS0 Failed, errno: %d\r\n, errno);
return 0;
}
//write the data to my device which echos them back
write(fd, buf, sizeof(buf)-1);
//will wait forever here.
while(1) {
//wait for all 12 characters to received in fifo and then print them to
the console
ret = read(fd, buf2, sizeof(buf)-1);
if (ret ==sizeof(buf)-1) {
buf2[ret] ='\0' ;
printf(got data %s\n, buf2) ;
break;
}
}
close(fd) ;
return 0;
}
--
On 3/20/12 11:06 AM, Philippe Gerum r...@xenomai.org wrote:
On 03/20/2012 03:53 PM, Glen Wernersbach wrote:
Ipipe version:
1.13-05
Yes, I do have the co kernel and interrupt pipeline enabled
ldd your-serial-app ?
On 3/20/12 10:47 AM, Philippe Gerumr...@xenomai.org wrote:
On 03/20/2012 03:34 PM, Glen Wernersbach wrote:
Working on the Strace.
I don't have the /proc/xenomai/hal file??
/proc/ipipe/version then.
Again. Nothing I am running is xeno. Its just a xeno patched kernel.
Ok, but you do have the Xenomai co-kernel enabled in your kernel build,
and the interrupt pipeline is enabled as well, right?
On 3/20/12 10:31 AM, Philippe Gerumr...@xenomai.org wrote:
On 03/20/2012 03:17 PM, Philippe Gerum wrote:
On 03/20/2012 03:07 PM, Glen Wernersbach wrote:
I went through and disabled everything in xeno except
CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it
works.
Take that option out at anytime it works.
My program basic writes a few characters a serial port and then
reads
them
back in from the same port. I have a loop back cable connected
to the
port.
It writes the data but waits forever to read them back in
From my tests, it appears that the termois tcsetaddr settings
is not
getting
set when I call it when this option is on.
Can you strace your app when it runs, please?
The interrupt pipeline release number would help as well
(/proc/xenomai/hal).
On 3/20/12 9:57 AM, Philippe Gerumr...@xenomai.org wrote:
On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
I don't think this is it directly.
This program was made on the same kernel prior to patching it with
Xeno.
It should still run like any other linux program.
- what does program not working mean in your case? Any errno
return
we
could interpret? Any strace output?
- what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving
PERVASIVE on?
On 3/20/12 9:44 AM, Philippe Gerumr...@xenomai.org wrote:
On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
Hi All,
I install Xenomai 2.6.0 on AT91SAM9G20 system and have found
that
when
CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real
time linux
serial write then read serial program does not work.
If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does
work.
Any ideas why?
A possible explanation would be that your application links
with the
Xenomai
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 10:20 PM, Glen Wernersbach wrote: I know that there are some compile bugs if you turn off CONFIG_XENO_OPT_PERVASIVE. What is the downside to running without it? Don't bother for these build bugs, they were innocuous and due to 2.6.0 being the first code drop of a major release. The system is stable with or without. PERVASIVE gives you real-time support in userland; if you disable it, you only have support for writing apps in kernel space directly on top RT drivers. PERVASIVE is by no mean directly related to hw setup, serial links, etc. This is only about switching on/off the userland request channel to the Xenomai kernel, nothing else. So any interaction with a serial driver could only be really remote, and I can't think of any right now. Disabling this option might simply change the kernel code layout significantly enough to trigger a completely unrelated bug, since the Xenomai footprints in kernel shrinks in that case, changing the code placement for sure. Starting investigations from the matrix driver seems the best way to find the issue. On 3/20/12 4:35 PM, Gilles Chanteperdrix gilles.chanteperd...@xenomai.org wrote: On 03/20/2012 09:19 PM, Glen Wernersbach wrote: I actually think in is in the settings because if run just the setup part of the code without reading and writing, on the kernel that works my activity LED turns off. On the xeno kernel the LED never changes. I actually think that CONFIG_XENO_OPT_PERVASIVE does not make any difference which could cause a difference of hardware behaviour. So, it must be another option triggered by this config change. So, if you want us to help you, please post the .configs. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Intermixing native and POSIX skins
On 03/15/2012 05:30 PM, Doug Brunner wrote: Thanks Philippe. I hadn't even known about the existence of the RTIPC driver, and I definitely like the idea. I've been experimenting with it a bit today, and found that it seems to be allowed for more than two sockets to connect to the same port. I modified iddp-sendrecv.c to have two client processes, both of which now connect to the same port as the server, then did the same thing with iddp-label.c (two clients both connect()ing to the same label). This would cause havoc with the communications that go on between my processes--they need a one-to-one channel. I could implement semaphores to enforce this, but it would be nice to avoid that complication. Is there a way to make it happen using just the socket interface? The RTIPC protocols are fundamentally datagram-based, so allowing N:1 data paths is wanted. If the issue is about picking a different port each time you bind a server socket in the AF_RTIPC domain, then I would suggest to set sipc_port to -1 when binding the server-side socket: a free port will be picked automatically. You could then use getsockname() to retrieve the actual port #, and pass it to the clients. Doug Brunner -Original Message- From: Philippe Gerumr...@xenomai.org Sent: Monday, March 12, 2012 12:43pm To: Doug Brunnerdbrun...@ebus.com Cc: xenomai-help@gna.org Subject: Re: [Xenomai-help] Intermixing native and POSIX skins On 03/12/2012 08:12 PM, Doug Brunner wrote: I'd like to be able to use native skin communications services (most importantly real time pipes) from a thread created with the POSIX skin. Is this safe? Yes, that's fine. You could also use the XDDP protocol (cross-domain datagram) implemented by the RTIPC Xenomai driver for exactly the same purpose, with a socket-based interface as a bonus. I'm doing this because I'm building a C++ library that can use either real-time communications services, when used with a real-time application, or regular Linux pipe I/O, when used with a Linux application; these services are called by tasks that need to exist in both cases. I'd like to make the tasks always POSIX threads to eliminate the need for a bunch of wrappers and preprocessor ugliness that I put there to support either skin, depending on which version of the library is being built. Thanks, Doug Brunner ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Intermixing native and POSIX skins
On 03/12/2012 08:12 PM, Doug Brunner wrote: I'd like to be able to use native skin communications services (most importantly real time pipes) from a thread created with the POSIX skin. Is this safe? Yes, that's fine. You could also use the XDDP protocol (cross-domain datagram) implemented by the RTIPC Xenomai driver for exactly the same purpose, with a socket-based interface as a bonus. I'm doing this because I'm building a C++ library that can use either real-time communications services, when used with a real-time application, or regular Linux pipe I/O, when used with a Linux application; these services are called by tasks that need to exist in both cases. I'd like to make the tasks always POSIX threads to eliminate the need for a bunch of wrappers and preprocessor ugliness that I put there to support either skin, depending on which version of the library is being built. Thanks, Doug Brunner ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Cast a double value fails
On 03/07/2012 12:46 PM, Bertram Stemer wrote:
Hi,
I'm using Xenomai 2.5.6 with Linux 2.6.36 on a PowerPC and
have written a real-time application that runs on an isolated
CPU (Kernel option isolcpus). When I start this application on
another core, where a plain Linux application runs I get
sporadically unexpected results in the non real-time application,
when casting a double to an integer?!
To reproduce this behavior I have a small non real-time test
application that runs in parallel to the RT application:
...
while (1) {
int z = 4.0;
if (z != 4)
printf(cast error detected!);
/* sleep some microseconds */
}
...
Does anyone know how this can happen? Is there a CPU utilization
bound for real-time applications that run on the same CPU with
plain Linux tasks?
isolcpus does not actually fully isolates CPU from non-rt activity. What
you see is likely a bug in the Xenomai core, leaking fpu context bits
spuriously between -rt and non-rt. Adding this to the todo list.
Thanks in advance,
Bertram
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Freeze while running examples
On 03/06/2012 05:45 PM, Gilles Chanteperdrix wrote: On 03/06/2012 04:14 AM, Oscar Dávila wrote: 2012/3/2 Gilles Chanteperdrixgilles.chanteperd...@xenomai.org On 03/03/2012 01:14 AM, Oscar Dávila wrote: 2012/3/2 Gilles Chanteperdrixgilles.chanteperd...@xenomai.org On 03/02/2012 11:04 AM, Gilles Chanteperdrix wrote: On 03/01/2012 05:23 AM, Oscar Dávila wrote: Finally i could get the dump post-prompt No breakpoints or watchpoints. breakpoints-table-end post-prompt Dump of assembler code for function __ipipe_sync_stage: 0xc106d376__ipipe_sync_stage+0: push %ebp (...) 0xc106d526__ipipe_sync_stage+432: ret End of assembler dump. The address where the EIP is when the NMI watchdog triggers is 0xc106d5e1, so, outside this code. And this dump does not seem to correspond to the kernel that was running when the bug happened, because in that case we had 0xc106d5e1 == __ipipe_sync_stage + 0x21b whereas in your dump, __ipipe_sync_stage + 0x21b == 0xc106d591 Sorry about that, i lost that image of the kernel. Here is a new complete test. Kernel Messages Kernel failure message 1: BUG: NMI Watchdog detected LOCKUP on CPU0, ip c10751d3, registers: local_irq_disable_hw(); c10751bf: fa cli c10751c0: 89 e0 mov%esp,%eax c10751c2: 25 00 e0 ff ff and$0xe000,%eax root_stall_after_handler(); while (__ipipe_check_root_resched()) c10751c7: 83 78 14 00 cmpl $0x0,0x14(%eax) c10751cb: 75 58 jnec1075225__xirq_end+0x2 c10751cd: f6 40 08 08 testb $0x8,0x8(%eax) c10751d1: 74 52 je c1075225__xirq_end+0x2 c10751d3: eb f8 jmpc10751cd __ipipe_sync_stage+0x12b __ipipe_preempt_schedule_irq(); Looks like an infinite loop when CONFIG_PREEMPT is off. Try putting an #ifdef CONFIG_PREEMPT around this code: #ifdef CONFIG_PREEMPT while (__ipipe_check_root_resched()) __ipipe_preempt_schedule_irq(); #endif To test that this is indeed the issue, you may try enabling CONFIG_PREEMPT in the code. I recompiled the kernel enabling CONFIG_PREEMPT and it worked, also i tried the other option, where i add the #ifdef CONFIG_PREEMPT to the source of core.c, and it also worked. So it seems that was the problem. Now i can run trivial_periodic. But after some time with the kernel after running trivial_periodic, the machines still freezes, i will try to see where the failure is happening now. Which type of preemption model its preferred? i mean, using the CONFIG_PREEMPT enabled or without the: while (__ipipe_check_root_resched()) __ipipe_preempt_schedule_irq(); We should not need either workaround. From reading the code, I do not understand why the compiler creates this infinite loop. It would be interesting to generate the pre-processed file to understand how this happens. Because CONFIG_PREEMPT is disabled, but __ipipe_check_root_resched() is instantiated. This can't fly. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Will ipipe-serial-debug work with a serial port on a PCI board ?
On 02/23/2012 12:09 PM, Thierry Bultel wrote: Hello, I am working on a board that does not have genuine UARTs on it (only soldered USBtoSerial converters) :-( But it has a free minPci slot, and I was wondering if it would be possible to perform serial debug with serial ports on a PCI board. In theory, the implementation of __ipipe_serial_debug() for the 8250 should tap at a high level enough in the TTY infrastructure, to emit characters via the PCI serial core properly. In practice, ... I never tried. Thanks for your advice Regards, Thierry Bultel ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Handler executed on behalf of rtdm_nrtsig_pend() appears to be running in Linux hardirq, rather than softirq, context
On 02/02/2012 01:53 AM, Mitchell Tasman wrote: Xenomai documents rtdm_nrtsig_pend() as follows: The signal handler will run in soft-IRQ context of the non-real-time subsystem. Note the implications of this context, e.g. no invocation of blocking operations. As a result, I would have anticipated that when invoked from within the signal handler, in_irq() would return 0, while in_softirq() would return non-zero. Actually, nrt_sig runs on behalf of a virtual interrupt, which is a hard IRQ context from Linux's standpoint. Instead, I've found that in_irq() returns the value 0x1, which (digging around in include/linux/hardirq.h) indicates that the hardirq count is 1. A partial Linux kernel stack backtrace, leading up to execution of the signal handler, is as follows: [ 217.844177] [bf031838] (my_signalClient+0x24/0x48 [my_rtdm_driver]) from [c00df42c] (__ipipe_sync_stage+0x164/0x198) [ 217.844207] [c00df42c] (__ipipe_sync_stage+0x164/0x198) from [c0058960] (ipipe_trigger_irq+0x14/0x20) [ 217.844238] [c0058960] (ipipe_trigger_irq+0x14/0x20) from [c011ca78] (gatekeeper_thread+0x1ac/0x398) It seems that there are at least several possibilities: 1. I've misunderstood the documentation, and the signal handler is intended to run in Linux hardirq context. If so, and I need softirq context, I'd need to schedule a tasklet from within the signal handler. 2. There's something broken about my specific environment. I am presently using a Beagleboard xM Rev C, running a TI 2.6.37-derived OMAP kernel from the staging tree on Arago, with a tailored (by me) version of the ARM I-pipe patchset for 2.6.37.6 that ships with Xenomai-2.6.0. The Xenomai version is also the as-released 2.6.0. 3. I've discovered a bug (or feature) in the rtdm_nrtsig_pend() implementation and/or in the underlying plumbing. Perhaps someone from the Xenomai community can comment. Thanks much. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai 3 documentation
On 02/02/2012 06:29 PM, Daniele Nicolodi wrote: Hello, I'm looking with curiosity to the development of Xenomai 3 skimming through the GIT commits. I'm a physicist writing data acquisition code, looking at how experienced programmers solve problems is very instructional. However, I have observed that most of the code that has been added do not have documentation in the form of comment blocks. There is some other place where I can learn about Xenomai 3 ? A general roadmap explaining high level issues: http://www.xenomai.org/index.php/Xenomai:Roadmap#Toward_Xenomai_3 For the rest, the Cobalt kernel is fully documented in the sources, since it directly derives from v2.x's nucleus, check kernel/cobalt. The really missing part is a documentation of the lib/copperplate API, providing the building blocks for the userland-based RTOS skins. That one is still wandering somewhere in my brain. But for sure, it will land in the sources at some point as well. Thank you. Cheers, -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Sharing of access to RT_MUTEX, RT_QUEUE, and RT_TASK
On 01/31/2012 07:40 AM, Doug Brunner wrote: I'm working on an application where it would be convenient for several tasks within the same process to share access to single descriptors for mutexes, queues, and tasks, rather than each task having to separately bind to each one and keep its own RT_MUTEX/RT_QUEUE/RT_TASK. The documentation doesn't seem to speak to this issue, and I haven't been able to find a definitive answer through searches. Can anyone clarify whether or not this will lead to problems, e.g. task A is in the midst of locking a mutex when task B starts trying to obtain a lock itself, and bad results occur? Descriptors in user-space only contain handles to kernel objects, they carry no object properties; on the contrary, their kernel space counterparts do carry object information. So, from user-space, you can share descriptors between threads which belong to the same process freely. The same way, cloning a descriptor in user-space using bitwise-copy does produce a valid descriptor to the original object. Binding is meant to be used in two cases: - when the original object descriptor is not in the same address space (i.e. created by a different process, or created in kernel space) - when the caller wants to wait for some object to be created, in which case the binding operation provides the required synchronization mechanism as a bonus. In the case you describe, there is no problem in considering object descriptors as globally shared variables. Thanks, Doug Brunner ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rtdm difficulties
On 01/20/2012 05:17 PM, Terry Fryar wrote: Using xenomai 2.6.0 with 2.6.38 kernel and rtdm. Been working on a rtdm driver for awhile and all of a sudden I've lost stability. So, I've backed off all code except for registering an empty realtime irq handler using rtdm_irq_request(). I'm getting kernel oops, and I don't know why? The irq handler simply returns RTDM_IRQ_HANDLED and that's it. I've rebuilt my kernel several times, and I'm wondering if I'm missing a .config entry for something related to xenomai?? If I take out the irq handler registration, all is fine. This driver's been working for about 2 weeks, but all of a sudden I'm getting kernel faults. Here's what I'm getting from my driver (vme_pd_drv): [ 795.986316] Unable to handle kernel paging request at virtual address 80b112d6 [ 795.993905] Unable to handle kernel paging request at virtual address e28cca55 [ 796.001475] Unable to handle kernel paging request at virtual address e5bcf074 [ 796.009045] Unable to handle kernel paging request at virtual address e5bcf074 [ 796.016615] Unable to handle kernel paging request at virtual address e5bcf074 [ 796.044130] Unable to handle kernel paging request at virtual address e5bcf074 [ 796.051696] Unable to handle kernel paging request at virtual address e5bcf074 [ 796.059262] Unable to handle kernel paging request at virtual address e5bcf074 [ 796.106868] Unable to handle kernel paging request at virtual address e5bcf074 [ 796.124353] Unable to handle kernel paging request at virtual address e5bcf074 [ 796.131920] Unable to handle kernel paging request at virtual address e5bcf074 [ 796.139484] Unable to handle kernel paging request at virtual address e5bcf074 [ 796.207081] Unable to handle kernel paging request at virtual address e5bcf074 [ 796.214711] pgd = c0004000 [ 796.217544] [e5bcf074] *pgd= [ 796.221294] Internal error: Oops: 5 [#1] PREEMPT [ 796.266149] last sysfs file: /sys/devices/virtual/irqdrv/irqdrv0/uevent [ 796.273082] Modules linked in: vme_pd_drv [last unloaded: vme_pd_drv] [ 796.279846] CPU: 0 Not tainted (2.6.38-ipipe-dirty #53) [ 796.315847] PC is at show_pte+0x18/0xb0 [ 796.319868] LR is at __do_kernel_fault+0x54/0x84 [ 796.384733] pc : [c0059170] lr : [c00592f8] psr: a113 [ 796.384740] sp : c058f1c8 ip : fb02 fp : 031b [ 796.396765] r10: 0005 r9 : 2113 r8 : [ 796.402237] r7 : c058f2a8 r6 : e5bcf050 r5 : e5bcf050 r4 : e5bcf074 [ 796.449104] r3 : c058f1cc r2 : c04fbb6f r1 : e5bcf074 r0 : c04fbac9 [ 796.455945] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 796.463604] Control: 10c5387d Table: 9e52c019 DAC: 0017 [ 796.519769] Process ü (pid: -598785, stack limit = 0xc058e2f0) UhOh... This very muck looks like stack overflow / corruption. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rtdm difficulties
On 01/20/2012 08:37 PM, Terry Fryar wrote:
Ok, I'll try the patch. A question though...on the beagle, there is a OMAP
register GPIO_IRQSTATUSx that I am not manually clearing out. This is the
only place to ack an irq I know of...I assumed that was being handled by the
kernel? Or is this what the patch is adding?? I'm very new to writing irq
handlers, as you can tell!
Honestly, all that's in my current handler is this:
int irqdrv_rtdm_isr(rtdm_irq_t* handle)
{
return(RTDM_IRQ_HANDLED);
}
And here's the register func:
if ((err = rtdm_irq_request(irqdrv_isr_handle, irqno, irqdrv_rtdm_isr,
RTDM_IRQTYPE_EDGE, IRQDRV_NAME, NULL)) == 0)
rtdm_irq_enable(irqdrv_isr_handle);
And I'm running against a square waveform and getting this:
[ 56.522948] WARNING: at kernel/softirq.c:137
__local_bh_enable+0x44/0xac()
[ 56.530153] Modules linked in: vme_pd_drv
[ 56.534399] [c00566fc] (unwind_backtrace+0x0/0xe0) from [c007db0c]
(warn_slowpath_common+0x4c/0x64)
[ 56.574419] [c007db0c] (warn_slowpath_common+0x4c/0x64) from
[c007db3c] (warn_slowpath_null+0x18/0x1c)
[ 56.584568] [c007db3c] (warn_slowpath_null+0x18/0x1c) from [c0083138]
(__local_bh_enable+0x44/0xac)
[ 56.594425] [c0083138] (__local_bh_enable+0x44/0xac) from [c008481c]
(irq_enter+0x44/0x60)
[ 56.623476] [c008481c] (irq_enter+0x44/0x60) from [c0046018]
(asm_do_IRQ+0x18/0x98)
[ 56.631880] [c0046018] (asm_do_IRQ+0x18/0x98) from [c00b9af0]
(__ipipe_sync_stage+0x154/0x188)
Make sure to have CONFIG_IPIPE_DEBUG_INTERNAL enabled in your kernel
config btw, this might help.
Gilles, I wonder whether this backtrace could not be the sign of a demux
ISR not going through ipipe_handle_chained_irq()?
-Original Message-
From: Gilles Chanteperdrix [mailto:gilles.chanteperd...@xenomai.org]
Sent: Friday, January 20, 2012 12:32 PM
To: Terry Fryar
Cc: xenomai-help@gna.org
Subject: Re: [Xenomai-help] rtdm difficulties
On 01/20/2012 07:24 PM, Terry Fryar wrote:
Yeh, omap and gpio.edge irq from a square wave pulse
Try this patch:
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c index
30cb7d4..114ccf0 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1272,7 +1272,7 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
u32 retrigger = 0;
int unmasked = 0;
- desc-irq_data.chip-irq_ack(desc-irq_data);
+ desc-irq_data.chip-irq_mask_ack(desc-irq_data);
bank = get_irq_data(irq);
#ifdef CONFIG_ARCH_OMAP1
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Issue with Auto relax and nested mutexes
On 01/18/2012 11:41 PM, Makarand Pradhan wrote:
Hi,
Another problem was encountered with rescnt related to nested mutexes.
This time the rescnt is not incrementing because the XNOTHER bit is not
set, causing a SIGDEBUG or SIGXCPU to be delivered to the thread causing
my application to crash.
The scenario is as follows:
1. Thread started with priority 0. (Relaxed)
2. This thread uses mutexes which causes Priority Inversions.
3. At some point, a rt_task_set_priority is done to change the priority.
(RT 85).
4. Some time later the priority is set back to 0.
If I understand it properly, your runtime scenario is badly broken I'm
afraid. By contrast to priority ceiling, priority inheritance is about
leaving the responsibility to the _kernel_ to pick the best dynamic
priority for your thread to solve a priority inversion.
Therefore, by changing your dynamic priority while holding a mutex, your
application is preventing the kernel to do the job you previously
assigned to it. Worst, you could be causing unexpected latencies to
other threads your application has no clue about, or just can't tell
whether they compete with your thread for accessing the resource at that
specific time.
After all, this is your application that defined the contented mutex,
and as such the fact that priority inheritance might be involved at some
point. If you don't trust the kernel and want to deal with priorities
manually during resource contention, then maybe you should use a
different mutual exclusion mechanism not implementing priority
inheritance, e.g. a plain binary semaphore.
The problem again revolves around setting XNOTHER. In the problem
scenario, the XNOTHER bit is not set in xnsynch_acquire. Hence the
rescnt is not incremented.
The reason for that is, while doing a rt_task_set_priority,
__xnsched_rt_setparam is invoked before the thread is reniced.
To resolve this issue, I had to set the XNOTHER bit in
__xnpod_set_thread_schedparam after the thread was reniced or in
rt_task_set_priority. Both the code changes are given below:
rt_task_set_priority(
+ if (0==prio)
+ {
+ xnthread_set_state(task-thread_base, XNOTHER);
+ }
xnpod_set_thread_schedparam(...
#ifdef CONFIG_XENO_OPT_PERVASIVE
if (propagate) {
if (xnthread_test_state(thread, XNRELAX))
xnshadow_renice(thread);
else if (xnthread_test_state(thread, XNSHADOW))
xnthread_set_info(thread, XNPRIOSET);
}
+ if (xnthread_test_state(thread, XNSHADOW)) {
+ // if (thread-bprio || !xnthread_test_state(thread, XNBOOST))
+ if (thread-bprio)
+ xnthread_clear_state(thread, XNOTHER);
+ else
+ xnthread_set_state(thread, XNOTHER);
+ }
Setting XNOTHER in rt_task_set_priority does not look appropriate. I
believe the right place is in the xnpod_set_thread_schedparam.
Would highly appreciate your views.
Rgds,
Mak
On 10/01/12 02:10 PM, Makarand Pradhan wrote:
The patch does work. Thanks.
Will it be available in the next release of xenomai?
Rgds,
Mak
root@ruggedcom:~# ./relax 0 1
Spawning: tasks
bP: 0, cp: 0, mode: 0
Acquire complete
Release complete
bP: 0, cp: 0, mode: 0
Acquire complete
Release complete
bP: 0, cp: 0, mode: 0
Acquire complete
Release complete
bP: 0, cp: 0, mode: 0
Acquire complete
Grabbing mux in HP
Mux held by Task2
Release complete
bP: 0, cp: 0, mode: 0
Acquire complete
Release complete
bP: 0, cp: 0, mode: 0
Acquire complete
^C
root@ruggedcom:~#
On 10/01/12 01:39 PM, Makarand Pradhan wrote:
Hi Phillipe,
A bit surprised to see a change in sched-rt.h. I had another problem
earlier where the XNOTHER was not getting set after a priority change. I
had to look at the code that you have modified. Although I had
temporarily worked around it by setting the XNOTHER in
rt_task_set_priority. I think this would fix that problem as well.
Will test the patch and get back with the results.
Thanks and Rgds,
Mak.
On 10/01/12 01:08 PM, Philippe Gerum wrote:
On 01/10/2012 04:51 PM, Makarand Pradhan wrote:
Based on my testing, it is noted that the rescnt is not released when
task1 gets a priority boost and starts running with priority 1. That's
when the rescnt is not decremented.
It would imply that we may be checking the current priority while
testing if we want to invoke rt_mutex_release in kernel. Will try to
check it out.
Does this help in your case?
diff --git a/include/nucleus/sched-rt.h b/include/nucleus/sched-rt.h
index cc1cefa..6ac8fd7 100644
--- a/include/nucleus/sched-rt.h
+++ b/include/nucleus/sched-rt.h
@@ -87,7 +87,7 @@ static inline void __xnsched_rt_setparam(struct
xnthread *thread,
{
thread-cprio = p-rt.prio;
if (xnthread_test_state(thread, XNSHADOW)) {
- if (thread-cprio)
+ if (thread-bprio || !xnthread_test_state(thread, XNBOOST))
xnthread_clear_state(thread, XNOTHER);
else
xnthread_set_state(thread, XNOTHER);
Rgds,
Mak.
On 10/01/12 10:42 AM, Philippe Gerum wrote:
On 01/10/2012 04:40 PM, Philippe Gerum wrote:
On 01/10/2012 04:40 PM, Makarand Pradhan wrote:
Another point:
These are fast mutexes, the thread does
Re: [Xenomai-help] Interrupt numbers
On 01/19/2012 08:41 PM, Michael Pustylnik wrote: Hi Philippe, I am really sorry for continuing this thread after such a long delay but I just couldn't get to it sooner. I understand all your points you mentioned describing the rationale behind your decision to eliminate the rt_intr_* API in Xenomai 3.x, and I definitely agree that they are very valid. However, in real life different Xenomai users could have all kinds of different considerations (other than the ones you mentioned) and there might be special reasons for insisting on using the user space interrupt services. We happen to be one of such users and we have strong reasons to tolerate the potential issues you mentioned in order to achieve our very specific goals by using the rt_intr_* API. (I don't want to waste your time describing those specific goals but believe me there are ones). Said that, we would face serious problems with upgrading to Xenomai 3.x, while we actually do want to take advantage of it. So, my question is simple - could you guys consider leaving the existing rt_intr* services in place as a bonus? (You could still say that this is not a recommended way interrupt handling but it's there for backwards compatibility). Please don't misunderstand this decision, it is 100% based on real life issues involving multiple customer projects, and was not taken lightly. The rationale behind it is that most newcomers should be allowed to expect all interfaces from the native/alchemy API to implement the recommended way of doing things. rt_intr* is completely at odds with this implicit rule: it is error-prone, limited to very specific use cases, and can lead to blatantly wrong app designs and roadblocks. The plan is to provide for a basic uio-like mechanism based on a RTDM driver for dealing with IRQs in userland. Users who insist on dealing with interrupts in userland could use the RTDM/ioctl() interface directly to that driver or wrap the deprecated rt_intr_* calls locally over it. Using a RTDM driver dedicated to such a peculiar task (and it shall be documented that way) could not be a naive decision. Thanks, Michael. -Original Message- From: xenomai-help-boun...@gna.org [mailto:xenomai-help-boun...@gna.org] On Behalf Of Philippe Gerum Sent: Friday, December 23, 2011 1:13 PM To: xenomai-help@gna.org Subject: Re: [Xenomai-help] Interrupt numbers On 12/23/2011 05:16 PM, Terry Fryar wrote: I would imagine it was nice, however, to have a userspace interrupt ISR so that flaky code could be debugged in userspace before making it into a driver? Most interrupts are level sensitive these days, which means that you cannot safely step into the code which is supposed to ack the source device using a debugger, your kernel would be stormed by IRQs before you reach the point where the device request is acked. Remember that userland always runs with hw interrupts enabled, regardless of the domain. Even edge triggered IRQs would not give you any guarantee with respect to device timing requirements. GDB aside, also think about a transition to secondary mode for whatever reason while running in userland prior to acking the device: this would be another source of unexpected delays in the acknowledge path. Debugging work is likely to introduce these issues, unless one refrains from using anything else than rt_printf() for logging/observing the runtime state, but that would not help with level sensitive IRQs anyway. You may want to handle the main application logic that responds to an interrupt in userland through, in which case you need some RTDM driver handling the bottom half of real-time interrupts, which would in turn unblock a task sleeping on some read() or ioctl(), to process the event in userland (i.e. UIO-like for real-time IRQs). The bottom line is that you want the IRQ to be acknowledged at device level from kernel space. Keeping it masked in the PIC while transitioning to user-space would be another option, assuming it is not shared with the regular kernel (sharing between rt and non-rt would be just wrong anyway), if the device permits (infinitely) delayed acknowledges, but I would not recommend this. Typically, a user-space code can be wiped off at any time, leaving the device in a weird state. These are the reasons why I have killed the rt_intr_* API in 3.x, it was way too easy to shoot oneself in the foot (and believe me, I saw quite a few damaged feet in the past years due to this issue). What was missing in this API is a clear hint that some user-provided code should live in kernel space to ack each particular device controlled from userland. Using RTDM to implement such code and synchronize with the application logic in userland is a safe, sane and simple solution. -Original Message- From: xenomai-help-boun...@gna.org [mailto:xenomai-help-boun...@gna.org] On Behalf Of Gilles Chanteperdrix Sent: Friday, December 23, 2011 9:53 AM To: Makarand Pradhan Cc: xenomai-help@gna.org
Re: [Xenomai-help] Issue with Auto relax and nested mutexes
On 01/09/2012 09:50 PM, Makarand Pradhan wrote: Hi, I am running kernel 3.0.0, xenomai: 2.6, powerpc 8360. I am noticing an issue while using the auto relax feature related to mutexes. I am using nested mutexes. The code is attached to this email. The problem is that I am not relaxing after a RT thread grabs and releases a mutex. On further investigation, it was noted that the rescnt is not going down to 0. From your code, task1 would auto-relax only if started with priority 0, which is what I get here: -bash-3.2# ./relax 0 1 Spawning: tasks bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete ... Conversely, I get the right behavior if setting a non-zero priority to task1: -bash-3.2# ./relax 1 0 Spawning: tasks bP: 1, cp: 1, mode: 1 Acquire complete Release complete bP: 1, cp: 1, mode: 1 Acquire complete Release complete bP: 1, cp: 1, mode: 1 Acquire complete ... In any case, the priority of task2 should have no impact on the result. I'm running current 2.6 HEAD commit (168da46de), kernel 3.1.5/powerpc32 (52xx), pipeline 2.13-06. Which priority arguments are you passing to your test program? Another observation is that I do not hit rt_mutex_release in the kernel in the problem scenario, I believe when the thread undergoes a priority inversion.This may be a problem as the rescnt would not get decremented. Not sure how the mutex is releasing wiithout hitting rt_mutex_relase or am I missing anything? These are fast mutexes, the thread does not have to jump to kernel space unless the released mutex was actually contented. If I have both the tasks running at priority 0, I stay in the secondary domain, rt_mutex_release is invoked as expected, the rescnt goes down to 0 when all the mutexes are released. Has anyone faced this problem? I'm unsure there is any yet. Auto-relax applies to non -rt Xenomai threads only (i.e. prio == 0). Rgds, Makarand ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Issue with Auto relax and nested mutexes
On 01/10/2012 04:26 PM, Makarand Pradhan wrote: Hi Phillippe, You are right. Task 1 requires to be started with prio 0. I start seeing the problem after task2 grabs the mutex and releases them. The first task never jumps back to seconodary. Here is my output. The mode never goes back to 0 after Grabbing mux in HP and the rescnt stays stuck at 1 in the kernel. Eeek. Ok, I definitely need to reproduce this. I'm slightly buried alive in Xenomai 3 stuff right now, but I'll have a look at this asap. root@ruggedcom:~# ./relax 0 1 Spawning: tasks bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Grabbing mux in HP Mux held by Task2 Release complete bP: 0, cp: 0, mode: 1 Acquire complete Release complete bP: 0, cp: 0, mode: 1 Acquire complete Rgds, Mak. On 10/01/12 10:11 AM, Philippe Gerum wrote: On 01/09/2012 09:50 PM, Makarand Pradhan wrote: Hi, I am running kernel 3.0.0, xenomai: 2.6, powerpc 8360. I am noticing an issue while using the auto relax feature related to mutexes. I am using nested mutexes. The code is attached to this email. The problem is that I am not relaxing after a RT thread grabs and releases a mutex. On further investigation, it was noted that the rescnt is not going down to 0. From your code, task1 would auto-relax only if started with priority 0, which is what I get here: -bash-3.2# ./relax 0 1 Spawning: tasks bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete ... Conversely, I get the right behavior if setting a non-zero priority to task1: -bash-3.2# ./relax 1 0 Spawning: tasks bP: 1, cp: 1, mode: 1 Acquire complete Release complete bP: 1, cp: 1, mode: 1 Acquire complete Release complete bP: 1, cp: 1, mode: 1 Acquire complete ... In any case, the priority of task2 should have no impact on the result. I'm running current 2.6 HEAD commit (168da46de), kernel 3.1.5/powerpc32 (52xx), pipeline 2.13-06. Which priority arguments are you passing to your test program? Another observation is that I do not hit rt_mutex_release in the kernel in the problem scenario, I believe when the thread undergoes a priority inversion.This may be a problem as the rescnt would not get decremented. Not sure how the mutex is releasing wiithout hitting rt_mutex_relase or am I missing anything? These are fast mutexes, the thread does not have to jump to kernel space unless the released mutex was actually contented. If I have both the tasks running at priority 0, I stay in the secondary domain, rt_mutex_release is invoked as expected, the rescnt goes down to 0 when all the mutexes are released. Has anyone faced this problem? I'm unsure there is any yet. Auto-relax applies to non -rt Xenomai threads only (i.e. prio == 0). Rgds, Makarand ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Issue with Auto relax and nested mutexes
On 01/10/2012 04:40 PM, Makarand Pradhan wrote: Another point: These are fast mutexes, the thread does not have to jump to kernel space unless the released mutex was actually contented. When the first task is started with prio 0, I always see that rt_mutex_release is invoked in the kernel. even when there is no contention. I should have added: unless there is no contention ... or the caller is a non-rt thread. This is because we have to jump to kernel space to track rescnt. I have an instrumented kernel. The kernel trace is given below. In this trace only task1 is running at prio 0. It should be easy to follow: Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 0, switched: 0 Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 0, switched: 0 Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 1, switched: 1 Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:01 ruggedcom kernel: RML Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:01 ruggedcom kernel: RML Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 1, switched: 0 Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:01 ruggedcom kernel: RML Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 0, switched: 0 Jan 10 10:37:01 ruggedcom kernel: lo: rescnt: 1, switched: 1 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:03 ruggedcom kernel: RML Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:03 ruggedcom kernel: RML Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 1, switched: 0 Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:03 ruggedcom kernel: RML Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 0, switched: 0 Jan 10 10:37:03 ruggedcom kernel: lo: rescnt: 1, switched: 1 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:04 ruggedcom kernel: hi: rescnt: 3, switched: 0 root@ruggedcom:~# ./a.out 0 1 Spawning: tasks bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete ^C Rgds, Mak. On 10/01/12 10:26 AM, Makarand Pradhan wrote: Hi Phillippe, You are right. Task 1 requires to be started with prio 0. I start seeing the problem after task2 grabs the mutex and releases them. The first task never jumps back to seconodary. Here is my output. The mode never goes back to 0 after Grabbing mux in HP and the rescnt stays stuck at 1 in the kernel. root@ruggedcom:~# ./relax 0 1 Spawning: tasks bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Grabbing mux in HP Mux held by Task2 Release complete bP: 0, cp: 0, mode: 1 Acquire complete Release complete bP: 0, cp: 0, mode: 1 Acquire complete Rgds, Mak. On 10/01/12 10:11 AM, Philippe Gerum wrote: On 01/09/2012 09:50 PM, Makarand Pradhan wrote: Hi, I am running kernel 3.0.0, xenomai: 2.6, powerpc 8360. I am noticing an issue while using the auto relax feature related to mutexes. I am using nested mutexes. The code is attached to this email. The problem is that I am not relaxing after a RT thread grabs and releases a mutex. On further investigation, it was noted that the rescnt is not going down to 0. From your code, task1 would auto-relax only if started with priority 0, which is what I get here: -bash-3.2# ./relax 0 1 Spawning: tasks bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete ... Conversely, I get the right behavior if setting a non-zero priority
Re: [Xenomai-help] Issue with Auto relax and nested mutexes
On 01/10/2012 04:40 PM, Philippe Gerum wrote: On 01/10/2012 04:40 PM, Makarand Pradhan wrote: Another point: These are fast mutexes, the thread does not have to jump to kernel space unless the released mutex was actually contented. When the first task is started with prio 0, I always see that rt_mutex_release is invoked in the kernel. even when there is no contention. I should have added: unless there is no contention ... or the caller is a non-rt thread. This is because we have to jump to kernel space to track rescnt. Ok, next try: unless the mutex was contented ... or the caller is a non-rt thread. I have an instrumented kernel. The kernel trace is given below. In this trace only task1 is running at prio 0. It should be easy to follow: Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 0, switched: 0 Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 0, switched: 0 Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 1, switched: 1 Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:01 ruggedcom kernel: RML Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:01 ruggedcom kernel: RML Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 1, switched: 0 Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:01 ruggedcom kernel: RML Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 0, switched: 0 Jan 10 10:37:01 ruggedcom kernel: lo: rescnt: 1, switched: 1 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:03 ruggedcom kernel: RML Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:03 ruggedcom kernel: RML Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 1, switched: 0 Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:03 ruggedcom kernel: RML Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 0, switched: 0 Jan 10 10:37:03 ruggedcom kernel: lo: rescnt: 1, switched: 1 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:04 ruggedcom kernel: hi: rescnt: 3, switched: 0 root@ruggedcom:~# ./a.out 0 1 Spawning: tasks bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete ^C Rgds, Mak. On 10/01/12 10:26 AM, Makarand Pradhan wrote: Hi Phillippe, You are right. Task 1 requires to be started with prio 0. I start seeing the problem after task2 grabs the mutex and releases them. The first task never jumps back to seconodary. Here is my output. The mode never goes back to 0 after Grabbing mux in HP and the rescnt stays stuck at 1 in the kernel. root@ruggedcom:~# ./relax 0 1 Spawning: tasks bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Grabbing mux in HP Mux held by Task2 Release complete bP: 0, cp: 0, mode: 1 Acquire complete Release complete bP: 0, cp: 0, mode: 1 Acquire complete Rgds, Mak. On 10/01/12 10:11 AM, Philippe Gerum wrote: On 01/09/2012 09:50 PM, Makarand Pradhan wrote: Hi, I am running kernel 3.0.0, xenomai: 2.6, powerpc 8360. I am noticing an issue while using the auto relax feature related to mutexes. I am using nested mutexes. The code is attached to this email. The problem is that I am not relaxing after a RT thread grabs and releases a mutex. On further investigation, it was noted that the rescnt is not going down to 0. From your code, task1 would auto-relax only if started with priority 0, which is what I get here: -bash-3.2# ./relax 0 1 Spawning: tasks bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete
Re: [Xenomai-help] Issue with Auto relax and nested mutexes
On 01/10/2012 04:51 PM, Makarand Pradhan wrote: Based on my testing, it is noted that the rescnt is not released when task1 gets a priority boost and starts running with priority 1. That's when the rescnt is not decremented. Ah, bad side effect of __xnsched_rt_setparam likely. Ok, I need to have a deeper look, but this would make sense. It would imply that we may be checking the current priority while testing if we want to invoke rt_mutex_release in kernel. Will try to check it out. Rgds, Mak. On 10/01/12 10:42 AM, Philippe Gerum wrote: On 01/10/2012 04:40 PM, Philippe Gerum wrote: On 01/10/2012 04:40 PM, Makarand Pradhan wrote: Another point: These are fast mutexes, the thread does not have to jump to kernel space unless the released mutex was actually contented. When the first task is started with prio 0, I always see that rt_mutex_release is invoked in the kernel. even when there is no contention. I should have added: unless there is no contention ... or the caller is a non-rt thread. This is because we have to jump to kernel space to track rescnt. Ok, next try: unless the mutex was contented ... or the caller is a non-rt thread. I have an instrumented kernel. The kernel trace is given below. In this trace only task1 is running at prio 0. It should be easy to follow: Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 0, switched: 0 Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 0, switched: 0 Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 1, switched: 1 Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:01 ruggedcom kernel: RML Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:01 ruggedcom kernel: RML Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 1, switched: 0 Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:01 ruggedcom kernel: RML Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 0, switched: 0 Jan 10 10:37:01 ruggedcom kernel: lo: rescnt: 1, switched: 1 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:03 ruggedcom kernel: RML Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:03 ruggedcom kernel: RML Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 1, switched: 0 Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release Jan 10 10:37:03 ruggedcom kernel: RML Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 0, switched: 0 Jan 10 10:37:03 ruggedcom kernel: lo: rescnt: 1, switched: 1 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0 Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0 Jan 10 10:37:04 ruggedcom kernel: hi: rescnt: 3, switched: 0 root@ruggedcom:~# ./a.out 0 1 Spawning: tasks bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete ^C Rgds, Mak. On 10/01/12 10:26 AM, Makarand Pradhan wrote: Hi Phillippe, You are right. Task 1 requires to be started with prio 0. I start seeing the problem after task2 grabs the mutex and releases them. The first task never jumps back to seconodary. Here is my output. The mode never goes back to 0 after Grabbing mux in HP and the rescnt stays stuck at 1 in the kernel. root@ruggedcom:~# ./relax 0 1 Spawning: tasks bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Release complete bP: 0, cp: 0, mode: 0 Acquire complete Grabbing mux in HP Mux held by Task2 Release complete bP: 0, cp: 0, mode: 1 Acquire complete Release complete bP: 0, cp: 0, mode: 1 Acquire complete Rgds, Mak. On 10/01/12 10:11 AM, Philippe Gerum wrote: On 01/09/2012 09:50 PM, Makarand Pradhan wrote: Hi, I am running kernel 3.0.0, xenomai: 2.6, powerpc 8360. I am
Re: [Xenomai-help] Issue with Auto relax and nested mutexes
On 01/10/2012 04:51 PM, Makarand Pradhan wrote:
Based on my testing, it is noted that the rescnt is not released when
task1 gets a priority boost and starts running with priority 1. That's
when the rescnt is not decremented.
It would imply that we may be checking the current priority while
testing if we want to invoke rt_mutex_release in kernel. Will try to
check it out.
Does this help in your case?
diff --git a/include/nucleus/sched-rt.h b/include/nucleus/sched-rt.h
index cc1cefa..6ac8fd7 100644
--- a/include/nucleus/sched-rt.h
+++ b/include/nucleus/sched-rt.h
@@ -87,7 +87,7 @@ static inline void __xnsched_rt_setparam(struct xnthread
*thread,
{
thread-cprio = p-rt.prio;
if (xnthread_test_state(thread, XNSHADOW)) {
- if (thread-cprio)
+ if (thread-bprio || !xnthread_test_state(thread, XNBOOST))
xnthread_clear_state(thread, XNOTHER);
else
xnthread_set_state(thread, XNOTHER);
Rgds,
Mak.
On 10/01/12 10:42 AM, Philippe Gerum wrote:
On 01/10/2012 04:40 PM, Philippe Gerum wrote:
On 01/10/2012 04:40 PM, Makarand Pradhan wrote:
Another point:
These are fast mutexes, the thread does not have to jump to kernel
space
unless the released mutex was actually contented.
When the first task is started with prio 0, I always see that
rt_mutex_release is invoked in the kernel. even when there is no
contention.
I should have added: unless there is no contention ... or the caller is
a non-rt thread. This is because we have to jump to kernel space to
track rescnt.
Ok, next try: unless the mutex was contented ... or the caller is
a non-rt thread.
I have an instrumented kernel. The kernel trace is given below. In this
trace only task1 is running at prio 0. It should be easy to follow:
Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 0, switched: 0
Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 0, switched: 0
Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 1, switched: 1
Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 2, switched: 0
Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 3, switched: 0
Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0
Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release
Jan 10 10:37:01 ruggedcom kernel: RML
Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1
Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0
Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0
Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release
Jan 10 10:37:01 ruggedcom kernel: RML
Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1
Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0
Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 1, switched: 0
Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release
Jan 10 10:37:01 ruggedcom kernel: RML
Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1
Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0
Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 0, switched: 0
Jan 10 10:37:01 ruggedcom kernel: lo: rescnt: 1, switched: 1
Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0
Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0
Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0
Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release
Jan 10 10:37:03 ruggedcom kernel: RML
Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1
Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0
Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0
Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release
Jan 10 10:37:03 ruggedcom kernel: RML
Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1
Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0
Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 1, switched: 0
Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release
Jan 10 10:37:03 ruggedcom kernel: RML
Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1
Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0
Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 0, switched: 0
Jan 10 10:37:03 ruggedcom kernel: lo: rescnt: 1, switched: 1
Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0
Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0
Jan 10 10:37:04 ruggedcom kernel: hi: rescnt: 3, switched: 0
root@ruggedcom:~# ./a.out 0 1
Spawning: tasks
bP: 0, cp: 0, mode: 0
Acquire complete
Release complete
bP: 0, cp: 0, mode: 0
Acquire complete
Release complete
bP: 0, cp: 0, mode: 0
Acquire complete
^C
Rgds,
Mak.
On 10/01/12 10:26 AM, Makarand Pradhan wrote:
Hi Phillippe,
You are right. Task 1 requires to be started with prio 0. I start
seeing
the problem after task2 grabs the mutex and releases them. The first
task never jumps back to seconodary. Here is my output. The mode never
goes back to 0 after Grabbing mux in HP and the rescnt stays
stuck
Re: [Xenomai-help] unresolved symbol - check the xenomai installation
On 01/08/2012 09:38 PM, Jakub Nowacki wrote: On 06/01/12 09:40, Gilles Chanteperdrix wrote: This is not the same issue as Gregory. Gregory missing symbols were from libnative, and we know that examples makefiles include -lnative, so, libnative is probably not installed in the place where the linker looks for it: that is an installation issue. On the other hands, the symbols from the errors you show us are defined in libxenomai.so. So, the RTXI build system is likely using hardcoded flags instead of the flags returned by xeno-config: that is a makefile issue. OK, maybe my problem is not similar but I still get unresolved reference. Below I show the full listing when compilation fails /bin/bash ../libtool --tag=CXX --mode=link g++ -pipe -Wall -I/usr/share/qt3/include -DQT_THREAD_SUPPORT -O2 -L/usr/share/qt3/lib -lqt-mt -lSM -lICE -lX11 -lXext -lXmu -lXt -lXi -lgsl -lgslcblas -lm -L/usr/xenomai/lib -lxenomai -lpthread -lrt -lnative -o rtxi cmdline.o daq.o default_gui_model.o event.o fifo.o io.o main.o main_window.o mutex.o plugin.o rt.o rtfile.o rwlock.o sem.o settings.o workspace.o rt_os-xenomai.o moc_default_gui_model.o moc_main_window.o moc_plugin.o -rdynamic libtool: link: g++ -pipe -Wall -I/usr/share/qt3/include -DQT_THREAD_SUPPORT -O2 -o rtxi cmdline.o daq.o default_gui_model.o event.o fifo.o io.o main.o main_window.o mutex.o plugin.o rt.o rtfile.o rwlock.o sem.o settings.o workspace.o rt_os-xenomai.o moc_default_gui_model.o moc_main_window.o moc_plugin.o -rdynamic -L/usr/share/qt3/lib /usr/lib/libqt-mt.so -lSM -lICE -lX11 -lXext -lXmu -lXt -lXi -lgsl -lgslcblas -lm -L/usr/xenomai/lib /usr/xenomai/lib/libxenomai.so -lpthread -lrt /usr/xenomai/lib/libnative.so -Wl,-rpath -Wl,/usr/xenomai/lib -Wl,-rpath -Wl,/usr/xenomai/lib References should precede definitions. Try swapping libxenomai.so and libnative.so in your link order. As Gilles already suggested, using the xeno-config script in your Makefile to get the proper link flags would have prevented this issue. /usr/xenomai/lib/libnative.so: undefined reference to `xeno_current' /usr/xenomai/lib/libnative.so: undefined reference to `xeno_sem_heap' /usr/xenomai/lib/libnative.so: undefined reference to `xeno_sigshadow_install_once' /usr/xenomai/lib/libnative.so: undefined reference to `xeno_set_current' /usr/xenomai/lib/libnative.so: undefined reference to `xeno_map_heap' /usr/xenomai/lib/libnative.so: undefined reference to `xnarch_tsc_to_ns' /usr/xenomai/lib/libnative.so: undefined reference to `xeno_handle_mlock_alert' /usr/xenomai/lib/libnative.so: undefined reference to `xeno_fault_stack' /usr/xenomai/lib/libnative.so: undefined reference to `xeno_set_current_mode' /usr/xenomai/lib/libnative.so: undefined reference to `xeno_bind_skin_opt' /usr/xenomai/lib/libnative.so: undefined reference to `xeno_current_mode' /usr/xenomai/lib/libnative.so: undefined reference to `xnarch_ns_to_tsc' collect2: ld returned 1 exit status make[1]: *** [rtxi] Error 1 make[1]: Leaving directory `/usr/src/rtxi-1.31/rtxi' make: *** [all-recursive] Error 1 I use xeno-config to get flags, as you can see in the above libtool command. I'm not the expert on autotools, but everything seems to look OK. I even tried to add xenomai LD_LIBRARY_PATH, but the result is still the same. I think I give it a go with 2.5.6 and see if the error is there; I installed xenomai 2.5.6 for RTXI a couple of times on different machines and I don't recall this problem. Just to be absolutely clear, I'm suing Ubuntu 11.04 with GCC 4.6 (I checked 4.5 and I get the same thing). Best wishes, Jakub ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] RTDM and spi
On 01/05/2012 11:53 PM, Terry Fryar wrote:
So, this would cover the rtdm_event_timedwait(), for example?? This would
*not* work in a non-realtime thread..correct??
Correct.
-Original Message-
From: Philippe Gerum [mailto:r...@xenomai.org]
Sent: Thursday, January 05, 2012 4:44 PM
To: Terry Fryar
Cc: xenomai-help@gna.org
Subject: Re: [Xenomai-help] RTDM and spi
On 01/05/2012 11:28 PM, Terry Fryar wrote:
Ah...simple enough! One question though...are the xenomai sync
services items and irq functions available for non-RT kernel threads??
IRQ related routines? like request, enable, disable: yes. It's even
recommended to use them in that context actually.
Xenomai blocking services can only be used over a Xenomai thread, that is a
golden rule. Reason: to wait for a sync, the thread has to be held by the
scheduler of the kernel in question while it sleeps. Only Xenomai threads
have the required internal data to allow the Xenomai scheduler to hold them.
-Original Message-
From: Philippe Gerum [mailto:r...@xenomai.org]
Sent: Thursday, January 05, 2012 4:25 PM
To: Terry Fryar
Cc: xenomai-help@gna.org
Subject: Re: [Xenomai-help] RTDM and spi
On 01/05/2012 11:12 PM, Terry Fryar wrote:
Using the RTDM api with Xen 2.6 to develop a linux driver.
Basically have an ISR registered using *rtdm_irq_request*()that is
triggered from a gpio pin. ISR works fine. Inside ISR, the only thing
done is a *rtdm_event_signal*() on an event.
Then, I have a task created using *rtdm_task_init*() that is waiting
on the event using *rtdm_event_timedwait*().
So far, so good...all works. But, in the task I am making an SPI call
after the event is signaled using spi_message_add_tail() and
spi_sync() and that's where I get this:
BUG: sleeping function called from invalid context at
kernel/mutex.c:278 [ 98.449178] in_atomic(): 1, irqs_disabled(): 0, pid:
-555875760, name:
vÿÿýÿ¿·½ÿ§ÿÿõÿÿýw¿@ÞÞPÞÞ
[ 98.458686] INFO: lockdep is turned off.
[ 98.462811] [c00572ac] (unwind_backtrace+0x0/0xe0) from
[c04639bc]
(mutex_lock_nested+0x24/0x384)
[ 98.472501] [c04639bc] (mutex_lock_nested+0x24/0x384) from
[c033ca48] (__spi_sync+0x88/0xd8) [ 98.481730] [c033ca48]
(__spi_sync+0x88/0xd8) from [bf007180]
(irqdrv_task+0x44/0xd4 [irqdrv])
[ 98.491149] [bf007180] (irqdrv_task+0x44/0xd4 [irqdrv]) from
[c00e93d0] (xnarch_thread_trampoline+0x20/0x2c)
[ 98.501845] [c00e93d0] (xnarch_thread_trampoline+0x20/0x2c) from
[c00e5adc] (__xnpod_schedule+0x5cc/0xa54) [ 98.512355] [c00e5adc]
(__xnpod_schedule+0x5cc/0xa54) from [fff7febf] (0xfff7febf) [
98.520674] Xenomai: suspending kernel thread bf008180 ('irqdrvTask')
at 0xc00a92f8 after exception #0x0 I have tried this inside a kthread
and it works fine. I can also try the spi stuff without being
triggered by an IRQ, and I get the same error. I know this is
something simple???
You may not call the regular Linux kernel routines from a real-time
context.
You have two kernels running side by side, Linux and Xenomai,
unsynchronized. Your RTDM driver is entering __spi_sync() over a
non-Linux context, this can't work since that context may have
preempted Linux anywhere, including in the middle of what Linux thinks is
an atomic section.
Any kernel code you want to call from the real-time co-kernel has to
be adapted to support this. Specifically, you cannot run the regular
SPI stack over a real-time RTDM context.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] RTDM and spi
On 01/05/2012 11:12 PM, Terry Fryar wrote:
Using the RTDM api with Xen 2.6 to develop a linux driver.
Basically have an ISR registered using *rtdm_irq_request*()that is
triggered from a gpio pin. ISR works fine. Inside ISR, the only thing
done is a *rtdm_event_signal*() on an event.
Then, I have a task created using *rtdm_task_init*() that is waiting on
the event using *rtdm_event_timedwait*().
So far, so good...all works. But, in the task I am making an SPI call
after the event is signaled using spi_message_add_tail() and spi_sync()
and that's where I get this:
BUG: sleeping function called from invalid context at kernel/mutex.c:278
[ 98.449178] in_atomic(): 1, irqs_disabled(): 0, pid: -555875760, name:
vÿÿýÿ¿·½ÿ§ÿÿõÿÿýw¿@ÞÞPÞÞ
[ 98.458686] INFO: lockdep is turned off.
[ 98.462811] [c00572ac] (unwind_backtrace+0x0/0xe0) from [c04639bc]
(mutex_lock_nested+0x24/0x384)
[ 98.472501] [c04639bc] (mutex_lock_nested+0x24/0x384) from
[c033ca48] (__spi_sync+0x88/0xd8)
[ 98.481730] [c033ca48] (__spi_sync+0x88/0xd8) from [bf007180]
(irqdrv_task+0x44/0xd4 [irqdrv])
[ 98.491149] [bf007180] (irqdrv_task+0x44/0xd4 [irqdrv]) from
[c00e93d0] (xnarch_thread_trampoline+0x20/0x2c)
[ 98.501845] [c00e93d0] (xnarch_thread_trampoline+0x20/0x2c) from
[c00e5adc] (__xnpod_schedule+0x5cc/0xa54)
[ 98.512355] [c00e5adc] (__xnpod_schedule+0x5cc/0xa54) from
[fff7febf] (0xfff7febf)
[ 98.520674] Xenomai: suspending kernel thread bf008180 ('irqdrvTask')
at 0xc00a92f8 after exception #0x0
I have tried this inside a kthread and it works fine. I can also try the
spi stuff without being triggered by an IRQ, and I get the same error. I
know this is something simple???
You may not call the regular Linux kernel routines from a real-time
context. You have two kernels running side by side, Linux and Xenomai,
unsynchronized. Your RTDM driver is entering __spi_sync() over a
non-Linux context, this can't work since that context may have preempted
Linux anywhere, including in the middle of what Linux thinks is an
atomic section.
Any kernel code you want to call from the real-time co-kernel has to be
adapted to support this. Specifically, you cannot run the regular SPI
stack over a real-time RTDM context.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] RTDM and spi
On 01/05/2012 11:28 PM, Terry Fryar wrote:
Ah...simple enough! One question though...are the xenomai sync services
items and irq functions available for non-RT kernel threads??
IRQ related routines? like request, enable, disable: yes. It's even
recommended to use them in that context actually.
Xenomai blocking services can only be used over a Xenomai thread, that
is a golden rule. Reason: to wait for a sync, the thread has to be held
by the scheduler of the kernel in question while it sleeps. Only Xenomai
threads have the required internal data to allow the Xenomai scheduler
to hold them.
-Original Message-
From: Philippe Gerum [mailto:r...@xenomai.org]
Sent: Thursday, January 05, 2012 4:25 PM
To: Terry Fryar
Cc: xenomai-help@gna.org
Subject: Re: [Xenomai-help] RTDM and spi
On 01/05/2012 11:12 PM, Terry Fryar wrote:
Using the RTDM api with Xen 2.6 to develop a linux driver.
Basically have an ISR registered using *rtdm_irq_request*()that is
triggered from a gpio pin. ISR works fine. Inside ISR, the only thing
done is a *rtdm_event_signal*() on an event.
Then, I have a task created using *rtdm_task_init*() that is waiting
on the event using *rtdm_event_timedwait*().
So far, so good...all works. But, in the task I am making an SPI call
after the event is signaled using spi_message_add_tail() and
spi_sync() and that's where I get this:
BUG: sleeping function called from invalid context at
kernel/mutex.c:278 [ 98.449178] in_atomic(): 1, irqs_disabled(): 0, pid:
-555875760, name:
vÿÿýÿ¿·½ÿ§ÿÿõÿÿýw¿@ÞÞPÞÞ
[ 98.458686] INFO: lockdep is turned off.
[ 98.462811] [c00572ac] (unwind_backtrace+0x0/0xe0) from
[c04639bc]
(mutex_lock_nested+0x24/0x384)
[ 98.472501] [c04639bc] (mutex_lock_nested+0x24/0x384) from
[c033ca48] (__spi_sync+0x88/0xd8) [ 98.481730] [c033ca48]
(__spi_sync+0x88/0xd8) from [bf007180]
(irqdrv_task+0x44/0xd4 [irqdrv])
[ 98.491149] [bf007180] (irqdrv_task+0x44/0xd4 [irqdrv]) from
[c00e93d0] (xnarch_thread_trampoline+0x20/0x2c)
[ 98.501845] [c00e93d0] (xnarch_thread_trampoline+0x20/0x2c) from
[c00e5adc] (__xnpod_schedule+0x5cc/0xa54) [ 98.512355] [c00e5adc]
(__xnpod_schedule+0x5cc/0xa54) from [fff7febf] (0xfff7febf) [
98.520674] Xenomai: suspending kernel thread bf008180 ('irqdrvTask')
at 0xc00a92f8 after exception #0x0 I have tried this inside a kthread
and it works fine. I can also try the spi stuff without being
triggered by an IRQ, and I get the same error. I know this is
something simple???
You may not call the regular Linux kernel routines from a real-time context.
You have two kernels running side by side, Linux and Xenomai,
unsynchronized. Your RTDM driver is entering __spi_sync() over a non-Linux
context, this can't work since that context may have preempted Linux
anywhere, including in the middle of what Linux thinks is an atomic section.
Any kernel code you want to call from the real-time co-kernel has to be
adapted to support this. Specifically, you cannot run the regular SPI stack
over a real-time RTDM context.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] problem following 'xenomai quick build guide'
On 12/28/2011 10:17 AM, Gregory Gosse wrote: Now i use more recent xenomai and kernel versions : - xenomai 2.6.0 2011-11-05 ( latest ) - kernel 2.6.39 ( latest in 2.6 serie ) With the same patch : - adeos-ipipe-2.6.23-x86_64-1.4-03.patch I launch the command scripts/prepare-kernel.sh --linux=/usr/src/linux-2.6.39 --adeos=/usr/src/xenomai-2.6.0/ksrc/arch/x86/patches/adeos-ipipe-2.6.23-x86_64-1.4-03.patch --arch=x86_64 - there is no support for 2.6.39/x86. Looking at ksrc/arch/x86/patches tells you so. Latest kernel release currently supported on this arch is 2.6.38.8. --arch=x86, not x86_64 which is for legacy patches when 32 and 64bit linux trees were not merged yet. You need to unpack a vanilla linux 2.6.38.8 kernel tree, then $ cd linux-tree $ xenomai-2.6.0/scripts/prepare-kernel.sh --arch=x86 Nothing more. And get Unable to patch kernel 2.6.39 with adeos-ipipe-2.6.23-x86_64-1.4-03.patch with many Hunk #xx FAILED at xx Gregory -Message d'origine- De : Gilles Chanteperdrix [mailto:gilles.chanteperd...@xenomai.org] Envoyé : mardi 27 décembre 2011 17:59 À : Gregory Gosse Cc : xenomai-help@gna.org Objet : Re: [Xenomai-help] problem following 'xenomai quick build guide' On 12/27/2011 05:56 PM, Gregory Gosse wrote: What can I do to go further ? There is no point in starting with such outdated versions. Please download the latest stable release of Xenomai (xenomai 2.6.0), and if the quick build guide does not work, follow the not quick build guide called README.INSTALL which ships with the sources. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt numbers
On 12/23/2011 05:16 PM, Terry Fryar wrote: I would imagine it was nice, however, to have a userspace interrupt ISR so that flaky code could be debugged in userspace before making it into a driver? Most interrupts are level sensitive these days, which means that you cannot safely step into the code which is supposed to ack the source device using a debugger, your kernel would be stormed by IRQs before you reach the point where the device request is acked. Remember that userland always runs with hw interrupts enabled, regardless of the domain. Even edge triggered IRQs would not give you any guarantee with respect to device timing requirements. GDB aside, also think about a transition to secondary mode for whatever reason while running in userland prior to acking the device: this would be another source of unexpected delays in the acknowledge path. Debugging work is likely to introduce these issues, unless one refrains from using anything else than rt_printf() for logging/observing the runtime state, but that would not help with level sensitive IRQs anyway. You may want to handle the main application logic that responds to an interrupt in userland through, in which case you need some RTDM driver handling the bottom half of real-time interrupts, which would in turn unblock a task sleeping on some read() or ioctl(), to process the event in userland (i.e. UIO-like for real-time IRQs). The bottom line is that you want the IRQ to be acknowledged at device level from kernel space. Keeping it masked in the PIC while transitioning to user-space would be another option, assuming it is not shared with the regular kernel (sharing between rt and non-rt would be just wrong anyway), if the device permits (infinitely) delayed acknowledges, but I would not recommend this. Typically, a user-space code can be wiped off at any time, leaving the device in a weird state. These are the reasons why I have killed the rt_intr_* API in 3.x, it was way too easy to shoot oneself in the foot (and believe me, I saw quite a few damaged feet in the past years due to this issue). What was missing in this API is a clear hint that some user-provided code should live in kernel space to ack each particular device controlled from userland. Using RTDM to implement such code and synchronize with the application logic in userland is a safe, sane and simple solution. -Original Message- From: xenomai-help-boun...@gna.org [mailto:xenomai-help-boun...@gna.org] On Behalf Of Gilles Chanteperdrix Sent: Friday, December 23, 2011 9:53 AM To: Makarand Pradhan Cc: xenomai-help@gna.org Subject: Re: [Xenomai-help] Interrupt numbers On 12/23/2011 04:26 PM, Makarand Pradhan wrote: On 23/12/11 04:45 AM, Gilles Chanteperdrix wrote: Xenomai uses the same interrupt numbers as linux. But rt_intr_create is deprecated in user-space, you should instead write a driver using the rtdm skin. The enable bit is handled by xenomai when you request the irq at xenomai level. Hi Gilles, We use rt_intr_create in our code. So I am trying to understand the reasons for it being deprecated. So far, I have not been able to see any comments in the code regarding the deprecation or anything in the git log. Splitting your code between driver and application enforces a clean separation between the two, which helps maintenance, so is good on the long run. Can you pl comment on the reasons for deprecating rt_intr_create? Will it be removed in the next release? We never change ABI in a branch, so, all releases in the 2.6 branch are guaranteed to support the same services as xenomai 2.6.0. But in xenomai 3.0, rt_intr_create will certainly no longer be available. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Is there Xenomai support for the Freescale P1020 processor?
On 12/03/2011 10:52 AM, Richard Cochran wrote: On Tue, Nov 08, 2011 at 05:22:07PM +0100, Philippe Gerum wrote: So, the answer is maybe, maybe. Maybe it already works, given that P2020 is supported and I don't see much changes in P1020 wrt what the interrupt pipeline needs to know. I won't know before I put my hands on such a beast. BTW, Philippe, about six weeks ago I tried to run the 3.0 powerpc ipipe kernel on the P2020, but it won't compile. The various irq_ functions have changed names and signatures, and so the ipipe interrupt #ifdef code is out of date. Ok, thanks for the heads up. That should be better now, http://download.gna.org/adeos/patches/v3.x/powerpc/ Richard -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] IDDP send-receive example emits SIGXCPU signal
On 11/23/2011 09:31 AM, Guvenc Gulce wrote: Yes.. I have enabled the support for iddp sockets in the kernel configuration. It looks like that it works with xenomai 2.6.0 when I enable the pthread_set_mode_np(0, PTHREAD_WARNSW); after the socket() and bind() calls. (tested again with the example code from xenomai) My question is: Is it designed that way that the calls socket() and bind() for IDDP cause a switch to secondary mode and the calls recvfrom() and sendto() do not ? In other words does the real-timeliness guarantee exist only for recvfrom() and sendto() ? No. socket() or bind() have no reason to switch to secondary mode, unless socket() fails for the AF_RTIPC domain, in which case the call is routed to the regular kernel to handle the address family. You not only need to enable IDDP in the kernel, but you also have to wrap POSIX calls to libpthread_rt services. If socket(AF_RTIPC, ...) failed reaching Xenomai/RTDM, then it will also fail with the regular kernel, and this call will return an error. Thanks Regards Guvenc - Original Message - From: Gilles Chanteperdrixgilles.chanteperd...@xenomai.org To: Guvenc Gulcegul...@yahoo.com Cc: xenomai-help@gna.orgxenomai-help@gna.org Sent: Friday, November 11, 2011 12:43 PM Subject: Re: [Xenomai-help] IDDP send-receive example emits SIGXCPU signal On 11/11/2011 08:04 AM, Guvenc Gulce wrote: looks like XENOMAI_SKINCALL3 macro is failing for some reason but I can't explain this behavior as I am using the example code linked with the correct xenomai libraries. Any help would be highly appreciated. Do you have support for iddp sockets enabled in kernel configuration? If yes, do you have the same issue with xenomai 2.6.0? -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] How many cores Xenomai can support? how to extend to more cores, thanks!
On 11/17/2011 01:57 AM, Lou, Yuanzhi wrote: InXenomai’s native/task.h define as： #define T_CPU(cpu) (1 (24 + (cpu 7))) /* Up to 8 cpus [0-7] */ #define T_CPUMASK 0xff00 Which means Xenomai only can support 8 cores at most? The Xenomai core has no internal limit on the number of cores beyond the one Linux defines by CONFIG_NR_CPUS. However, the locking model we use has a low overhead (code and complexity) with few CPUs used in real-time mode, at the expense of being sub-optimal with a large number of CPUs. The API you mention simply reflects that fact. Again: this design affects the number of CPUs used in real-time mode (i.e. primary Xenomai mode), not necessarily the overall number of CPUs present in the system and only available to regular Linux processing. BRs Lou Yuanzhi ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Is there Xenomai support for the Freescale P1020 processor?
On 11/08/2011 04:08 PM, makarand pradhan wrote: Dear Gilles, I think I, now understand my mistake. I had sent the query to the Xenomai-core group earlier. Then thought that I had not sent the question to the right mailing list and resent it to the Xenomai-help mailing list. Please rest assured that I did not have any intentions of pressuring anyone. I'm new to the list and hence was a bit unsure. My sincere apologies. Relax, this is all fine. It's my bad, I'm the one who should have answered, but I tend to give no priority to requests originating from companies hiding behind @yahoo.com, unless I do know who's behind actually. Gilles probably grumbles for the same reason. So, the answer is maybe, maybe. Maybe it already works, given that P2020 is supported and I don't see much changes in P1020 wrt what the interrupt pipeline needs to know. I won't know before I put my hands on such a beast. Maybe it will be ported, I see no technical barrier, but I can't tell when. Rgds, Makarand. *From:* Gilles Chanteperdrix gilles.chanteperd...@xenomai.org *To:* Michael Pustylnik michaelpustyl...@ruggedcom.com *Cc:* makarand pradhan makarand_u_prad...@yahoo.com; xenomai-help@gna.org xenomai-help@gna.org *Sent:* Tuesday, November 8, 2011 9:50 AM *Subject:* Re: [Xenomai-help] Is there Xenomai support for the Freescale P1020 processor? On 11/08/2011 03:22 PM, Michael Pustylnik wrote: Hi Gilles, It is not a pressure and it is sad it looked that way to you. We don't have any intentions but figuring out whether or not the P1020 is supported. We have been using Xenomai for a few years already and we are looking at P1020 as a potential platform for our new project, so knowing if we can use Xenomai with it is very important. That accounts for the first post. I was answering the second. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge git woes
On 11/07/2011 02:38 PM, Thomas De Schampheleire wrote: Hi, It seems something was up with the Xenomai-forge git repository. On the web interface, I see many old commits being recommitted today. Can you give some background information as to why this happened? And more importantly, not being an experienced git user, how to recover from it? 'git status' shows: # On branch master # Your branch and 'origin/master' have diverged, # and have 177 and 360 different commit(s) each, respectively. and a 'git pull' shows tons of conflicts on files I did not touch. This is a rebase, which breaks the commit history. I have to rebase the -forge over the 2.6.x branch until the latter leaves the development phase at least. Cherry picking lots of changes manually from 2.6.x while it is under active development would be too error prone. Now that 2.6.0 is out, the number of rebases should decrease significantly, until 2.6.1 is released, at which point they should stop. You should force-pull your master branch, assuming you did not add any of your changes there, then rebase your own -forge update branch if any, onto the new master. Thanks, Thomas ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] 0 CPU time problem
On 11/04/2011 10:36 PM, Gilles Chanteperdrix wrote: On 11/04/2011 10:03 PM, Tom Z wrote: We do not know what skin you use, we will assume that you use Xenomai posix skin, so, compile with the right flags. Here is how I build my program, say, fooTest: gcc -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -D__XENO__ -lnative -L/usr/xenomai/lib -lxenomai -lpthread -lnative -lrtdk fooTest.c -o fooTest You are using the native skin then. CLOCK_PROCESS_CPUTIME_ID is not implemented for xenomai posix skin, so, clock_gettime probably returns an error, and the struct timespec is unchanged. If somehow the glibc clock_gettime is used, and this call does not cause a system call, then all bets are off, and even a lockup could happen. Thanks for explaining this. So can I trust the CPU time I obtained with my method when the function is running in the primary mode? It seems you explanation implies that the results I obtained are not reliable, if so, are there other reliable ways to obtain the CPU time? No, CLOCK_PROCESS_CPUTIME is a clock implemented by the Linux kernel, so, it does not see the time spent in primary mode. If the foo function does not suspend, you can use rt_timer_tsc(), but the answer is no, there is currently no way to get the cpu time used when in primary mode. There is one, but deeply buried in the API basement, via rt_task_inquire(): RT_TASK_INFO info; RTIME start; ret = rt_task_inquire(NULL, info); /* NULL means current task */ if (ret) goto Houston_handles_the_problem; start = info.exectime; ... do work ret = rt_task_inquire(NULL, info); delta = info.exectime - start; /* elapsed CPU time in ns */ rt_task_inquire() will beget a syscall each time invoked though, so it does have some overhead. You need CONFIG_XENO_OPT_STATS enabled in your Kconfig for this feature (defaults to on). -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] patching a kernel
On 11/01/2011 10:55 AM, Łukasz Sacha wrote: Hi, I'having problems with patching the 2.6.38.8 kernel. I prepare my kernel first to work on my device (mini2440). I configure it to use arm processor, etc. Then I patch from xenomai: scripts/prepare-kernel.sh --arch=arm --adeos=ksrc/arch/arm/patches/adeos-ipipe-2.6.38.8-arm-1.18-03.patch --linux=../linux-2.6.38.8 Now when I enter the ../linux-2.6.38.8 and run make xconfig (or menuconfig) I don't even see my processor there - it's set to Pentium PRO. What should I do now? Check the README.INSTALL file, section 2.4, Building for ARM. $ make ARCH=arm xconfig Your .config file for your 2440 board is probably broken by now if you saved your previous configuration attempt (i.e. switched to x86 settings). You may want to check this as well. regards, -- Łukasz Dragilla Sacha ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
On 09/26/2011 11:11 PM, Philippe Gerum wrote:
On Mon, 2011-09-26 at 22:01 +0200, Ronny Meeus wrote:
On Mon, Sep 26, 2011 at 12:46 PM, Philippe Gerumr...@xenomai.org wrote:
On Fri, 2011-09-23 at 22:23 +0200, Philippe Gerum wrote:
On Fri, 2011-09-23 at 22:21 +0200, Ronny Meeus wrote:
On Fri, Sep 23, 2011 at 3:00 PM, Philippe Gerumr...@xenomai.org wrote:
On Thu, 2011-09-22 at 22:15 +0200, Ronny Meeus wrote:
Hello
I have created some time ago a test application for the PSOS interface
of Xenomai.
This is a extensive test that stresses most of the PSOS services we
use in our application. You can find it as an attachment.
It is running fine on Xenomai 2-5-6.
Note that in the test application there is also a benchmarking part.
This is currently disabled, I will fix that later.
Now I'm investigating a switch to xenomai-forge so I tried to run the
same test on this platform.
This is a double cleanup call, due to the incorrect propagation of an
internal error detected in the task trampoline within the psos emulator.
In fact, this reveals a more general shortcoming with handling this
situation for tasks, and this may also reveal an issue with t_delete()
over the Mercury core.
I can't reproduce the issue here with your test program, but I'm sure
something is wrong in the emulator anyway, I'm just lucky with the
timings. Since you are running over the vanilla kernel and maybe x86,
you could run valgrind to check whether some memory corruption is
detected.
I'm working on this bug which will bite any emulator based on the
copperplate interface the same way. I don't see any show stopper to fix
it, but this needs some thoughts to do this properly.
Btw,
- what is your architecture?
- what is your glibc version?
Running on a PC (virtual BOX).
This is the information about the lib I use:
meeusr@meeusr-laptop:/lib$ ./libc.so.6
GNU C Library (Ubuntu EGLIBC 2.11.1-0ubuntu7.6) stable release version
2.11.1, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.3.
Compiled on a Linux2.6.24-27-server system on 2010-11-17.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
http://www.debian.org/Bugs/.
The valgrind stuff I will do later.
I can reproduce now. This is highly timing dependent.
git://git.xenomai.org/xenomai-forge.git has a general fix for this
issue. Your test code will need the following patch to work. The basic
fix is that you can't create multiple objects with the same name with
Xenomai, because we need unique names for the registry to be meaningful.
Thanks for looking into this issue.
The problem that we have is that we have a huge application and we
cannot guarantee that all tasknames are unique.
That is why I have implemented a mechanism to make a taskname unique
(I already had this in the Xenomai-2.5.6). In the force version this
could be something like:
if (name == NULL || *name == '\0')
sprintf(task-name, t%lu, ++anon_tids);
else {
struct clusterobj *cobj =
cluster_findobj(psos_task_table, name);
if (cobj != NULL) {
snprintf(task-name,sizeof(task-name),
%s@%lu, name, ++anon_tids);
}
else
strncpy(task-name, name, sizeof(task-name));
task-name[sizeof(task-name) - 1] = '\0';
}
This is an example for tasks. The same could be done for
regions,semaphores and message queues. I tried it on my repo and the
task application (rtprint) runs unmodified.
The only issue I see with this approach is that when 2 tasks with an
identical name, for example TEST, are created, the second one will be
mapped to TEST@1. If a t_ident call is executed, the TID of the first
instance will be returned, which is fine. If now the first task is
deleted, the t_ident call will fail.
I have committed a general fix for this issue in the -forge repo.
Specifically, the psos emulator now accepts duplicates the way the
original API does. *_ident() will return duplicate matches by order of
registration.
If this code works as expected, then you should not have to prevent
duplicates anymore.
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Multiple RT applications
On 10/28/2011 06:09 PM, Marek Knoth wrote: Hi All, is it possible to execute multiple application with rt_task in one machine? For example I tried to execute trivial-periodic application twice but only the first one instance is working. Is there any way how to do it? Check testsuite/latency. Thanks for help, Marek ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [PATCH 1 of 4] psos.h: add definition of ERR_OBJTFULL
On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote: Signed-off-by: Thomas De Schampheleirethomas.de.schamphele...@gmail.com Signed-off-by: Ronny Meeusronny.me...@gmail.com --- include/psos/psos.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/psos/psos.h b/include/psos/psos.h --- a/include/psos/psos.h +++ b/include/psos/psos.h @@ -97,6 +97,7 @@ #define ERR_OBJDEL 0x05 #define ERR_OBJID0x06 #define ERR_OBJTYPE 0x07 +#define ERR_OBJTFULL 0x08 #define ERR_OBJNF0x09 #define ERR_NOTCB0x0E Where is this error code used in the Xenomai tree? Can't find it right now. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [PATCH 2 of 4] psos: port long_names feature to xenomai-forge
On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote: While psos interface accepts 4 character ids, non null terminated, xenomai uses longer ids which must be null terminated. Revert to the behaviour of psos interface, while allowing long id strings if the global variable psos_long_names is set to non-zero. This patch ports the original fix from xenomai to xenomai-forge, fixing following problems: * a bug in __psos_maybe_short_name so that only 3 characters are retained * the call to __psos_maybe_short_name also needs to be done in the ident functions * the pt_create and pt_ident functions also need to be adapted Please merge long_names.h into psos.h, having a separate header for this is way overkill and brings nothing. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [PATCH 3 of 4] psos: add tm_getm function
On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote:
Signed-off-by: Thomas De Schampheleirethomas.de.schamphele...@gmail.com
Signed-off-by: Ronny Meeusronny.me...@gmail.com
---
include/psos/psos.h | 2 ++
lib/psos/tm.c | 7 +++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/psos/psos.h b/include/psos/psos.h
--- a/include/psos/psos.h
+++ b/include/psos/psos.h
@@ -363,6 +363,8 @@ u_long tm_set(u_long date,
u_long time,
u_long ticks);
+u_long tm_getm(unsigned long long *ns);
+
u_long tm_wkafter(u_long ticks);
u_long tm_wkwhen(u_long date,
diff --git a/lib/psos/tm.c b/lib/psos/tm.c
--- a/lib/psos/tm.c
+++ b/lib/psos/tm.c
@@ -309,3 +309,10 @@ u_long tm_get(u_long *date_r, u_long *ti
return SUCCESS;
}
+
+u_long tm_getm(unsigned long long *ns_r)
+{
+ *ns_r = clockobj_get_tsc();
+ return SUCCESS;
+}
- *ns_r = clockobj_get_tsc();
+ *ns_r = clockobj_tsc_to_ns(clockobj_get_tsc());
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [PATCH 4 of 4] psos: fix compiler warning: cprio could be used uninitialized
On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote:
Assign default 1 to satisfy compiler (tested with gcc 4.4.3)
Signed-off-by: Thomas De Schampheleirethomas.de.schamphele...@gmail.com
Signed-off-by: Ronny Meeusronny.me...@gmail.com
---
lib/psos/task.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/psos/task.c b/lib/psos/task.c
--- a/lib/psos/task.c
+++ b/lib/psos/task.c
@@ -247,7 +247,7 @@ u_long t_create(const char *name, u_long
pthread_attr_t thattr;
struct syncstate syns;
struct service svc;
- int ret, cprio;
+ int ret, cprio = 1;
char short_name[5];
ret = check_task_priority(prio,cprio);
@@ -414,7 +414,7 @@ u_long t_resume(u_long tid)
u_long t_setpri(u_long tid, u_long newprio, u_long *oldprio_r)
{
struct psos_task *task;
- int ret, cprio;
+ int ret, cprio = 1;
task = get_psos_task_or_self(tid,ret);
if (task == NULL)
Looks like 4.4.3 is wrong, 4.4.4+ does it better and does not choke.
Just to make sure the optimizer is given a chance to see the truth,
could you try without this patch, but with tagging check_task_priority()
as inline instead, with --disable-debug, then with --enable-debug=full
switches?
TIA,
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [PATCH 1 of 4] psos.h: add definition of ERR_OBJTFULL
On 10/26/2011 12:26 PM, Thomas De Schampheleire wrote: Hi, On Wed, Oct 26, 2011 at 12:19 PM, Philippe Gerumr...@xenomai.org wrote: On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote: Signed-off-by: Thomas De Schampheleirethomas.de.schamphele...@gmail.com Signed-off-by: Ronny Meeusronny.me...@gmail.com --- include/psos/psos.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/psos/psos.h b/include/psos/psos.h --- a/include/psos/psos.h +++ b/include/psos/psos.h @@ -97,6 +97,7 @@ #define ERR_OBJDEL 0x05 #define ERR_OBJID0x06 #define ERR_OBJTYPE 0x07 +#define ERR_OBJTFULL 0x08 #define ERR_OBJNF0x09 #define ERR_NOTCB0x0E Where is this error code used in the Xenomai tree? Can't find it right now. It's not used in the Xenomai code itself, but it may be used by applications. The definition is absent both in Xenomai as Xenomai-forge. ~Thomas Yes, the point is that so far, only the errors the Xenomai emulation does return are mentioned in this file. But we should merge this anyhow, since the original *_create() calls could throw this, so the app has to check despite Xenomai won't fail this way, right? -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [PATCH 2 of 4] psos: port long_names feature to xenomai-forge
On 10/26/2011 12:41 PM, Thomas De Schampheleire wrote: On Wed, Oct 26, 2011 at 12:21 PM, Philippe Gerumr...@xenomai.org wrote: On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote: While psos interface accepts 4 character ids, non null terminated, xenomai uses longer ids which must be null terminated. Revert to the behaviour of psos interface, while allowing long id strings if the global variable psos_long_names is set to non-zero. This patch ports the original fix from xenomai to xenomai-forge, fixing following problems: * a bug in __psos_maybe_short_name so that only 3 characters are retained * the call to __psos_maybe_short_name also needs to be done in the ident functions * the pt_create and pt_ident functions also need to be adapted Please merge long_names.h into psos.h, having a separate header for this is way overkill and brings nothing. It avoids exposing an internal interface to applications through psos.h. If anything, I think we should make a psos_internal.h or whatever, that can host __psos_maybe_short_name among others. Yes, that would be better. include/psos is really for external stuff anyway. lib/psos/internal.h would make sense. ~Thomas -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [PATCH 4 of 4] psos: fix compiler warning: cprio could be used uninitialized
On 10/26/2011 01:04 PM, Thomas De Schampheleire wrote:
On Wed, Oct 26, 2011 at 12:25 PM, Philippe Gerumr...@xenomai.org wrote:
On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote:
Assign default 1 to satisfy compiler (tested with gcc 4.4.3)
Signed-off-by: Thomas De Schampheleirethomas.de.schamphele...@gmail.com
Signed-off-by: Ronny Meeusronny.me...@gmail.com
---
lib/psos/task.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/psos/task.c b/lib/psos/task.c
--- a/lib/psos/task.c
+++ b/lib/psos/task.c
@@ -247,7 +247,7 @@ u_long t_create(const char *name, u_long
pthread_attr_t thattr;
struct syncstate syns;
struct service svc;
- int ret, cprio;
+ int ret, cprio = 1;
char short_name[5];
ret = check_task_priority(prio,cprio);
@@ -414,7 +414,7 @@ u_long t_resume(u_long tid)
u_long t_setpri(u_long tid, u_long newprio, u_long *oldprio_r)
{
struct psos_task *task;
- int ret, cprio;
+ int ret, cprio = 1;
task = get_psos_task_or_self(tid,ret);
if (task == NULL)
Looks like 4.4.3 is wrong, 4.4.4+ does it better and does not choke. Just to
make sure the optimizer is given a chance to see the truth, could you try
without this patch, but with tagging check_task_priority() as inline
instead, with --disable-debug, then with --enable-debug=full switches?
Without this patch, inlined check_task_prio, --disable-debug:
/bin/sh ../../libtool --tag=CC --mode=compile
/repo/tdescham/reborn/buildroot-forge/output/host/usr/bin/powerpc-linux-gcc
-DHAVE_CONFIG_H -I. -I../../lib/include -O2 -D_GNU_SOURCE
-D_REENTRANT -Wall -pipe -Wstrict-prototypes -Wmissing-prototypes
-Wno-long-long -Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
-Wstrict-prototypes -I../../include -pipe -Os -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT libpsos_la-task.lo
-MD -MP -MF .deps/libpsos_la-task.Tpo -c -o libpsos_la-task.lo `test
-f 'task.c' || echo './'`task.c
libtool: compile:
/repo/tdescham/reborn/buildroot-forge/output/host/usr/bin/powerpc-linux-gcc
-DHAVE_CONFIG_H -I. -I../../lib/include -O2 -D_GNU_SOURCE -D_REENTRANT
-Wall -pipe -Wstrict-prototypes -Wmissing-prototypes -Wno-long-long
-Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
-Wstrict-prototypes -I../../include -pipe -Os -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT libpsos_la-task.lo
-MD -MP -MF .deps/libpsos_la-task.Tpo -c task.c -fPIC -DPIC -o
.libs/libpsos_la-task.o
cc1: warnings being treated as errors
task.c: In function 't_setpri':
task.c:417: error: 'cprio' may be used uninitialized in this function
make[3]: *** [libpsos_la-task.lo] Error 1
Without this patch, inlined check_task_prio, --enable-debug=full
/bin/sh ../../libtool --tag=CC --mode=compile
/repo/tdescham/reborn/buildroot-forge/output/host/usr/bin/powerpc-linux-gcc
-DHAVE_CONFIG_H -I. -I../../lib/include -g -D__XENO_DEBUG__
-D__XENO_DEBUG_FULL__ -D_GNU_SOURCE -D_REENTRANT -Wall -pipe
-Wstrict-prototypes -Wmissing-prototypes -Wno-long-long
-Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
-Wstrict-prototypes -I../../include -pipe -Os -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT libpsos_la-task.lo
-MD -MP -MF .deps/libpsos_la-task.Tpo -c -o libpsos_la-task.lo `test
-f 'task.c' || echo './'`task.c
libtool: compile:
/repo/tdescham/reborn/buildroot-forge/output/host/usr/bin/powerpc-linux-gcc
-DHAVE_CONFIG_H -I. -I../../lib/include -g -D__XENO_DEBUG__
-D__XENO_DEBUG_FULL__ -D_GNU_SOURCE -D_REENTRANT -Wall -pipe
-Wstrict-prototypes -Wmissing-prototypes -Wno-long-long
-Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
-Wstrict-prototypes -I../../include -pipe -Os -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT libpsos_la-task.lo
-MD -MP -MF .deps/libpsos_la-task.Tpo -c task.c -fPIC -DPIC -o
.libs/libpsos_la-task.o
cc1: warnings being treated as errors
task.c: In function 't_setpri':
task.c:417: error: 'cprio' may be used uninitialized in this function
make[3]: *** [libpsos_la-task.lo] Error 1
So, debug or not, compiler keeps complaining.
For your reference, this is the change I did instead of the patch:
diff --git a/lib/psos/task.c b/lib/psos/task.c
--- a/lib/psos/task.c
+++ b/lib/psos/task.c
@@ -228,7 +228,7 @@ int psos_task_normalize_priority(unsigne
return psos_prio;
}
-static int check_task_priority(u_long psos_prio, int *core_prio)
+static inline int check_task_priority(u_long psos_prio, int *core_prio)
{
if (psos_prio 1 || psos_prio 255) /* In theory. */
return ERR_PRIOR;
powerpc-linux-gcc (crosstool-NG 1.12.1 - buildroot 2011.08-hgc55c56f04355) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
~Thomas
Ok, so I'll merge this.
--
Philippe.
Re: [Xenomai-help] [PATCH 1 of 4] psos.h: add definition of ERR_OBJTFULL
On 10/26/2011 01:11 PM, Thomas De Schampheleire wrote: Hi, On Wed, Oct 26, 2011 at 12:33 PM, Philippe Gerumr...@xenomai.org wrote: On 10/26/2011 12:26 PM, Thomas De Schampheleire wrote: Hi, On Wed, Oct 26, 2011 at 12:19 PM, Philippe Gerumr...@xenomai.orgwrote: On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote: Signed-off-by: Thomas De Schampheleirethomas.de.schamphele...@gmail.com Signed-off-by: Ronny Meeusronny.me...@gmail.com --- include/psos/psos.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/psos/psos.h b/include/psos/psos.h --- a/include/psos/psos.h +++ b/include/psos/psos.h @@ -97,6 +97,7 @@ #define ERR_OBJDEL 0x05 #define ERR_OBJID0x06 #define ERR_OBJTYPE 0x07 +#define ERR_OBJTFULL 0x08 #define ERR_OBJNF0x09 #define ERR_NOTCB0x0E Where is this error code used in the Xenomai tree? Can't find it right now. It's not used in the Xenomai code itself, but it may be used by applications. The definition is absent both in Xenomai as Xenomai-forge. ~Thomas Yes, the point is that so far, only the errors the Xenomai emulation does return are mentioned in this file. But we should merge this anyhow, since the original *_create() calls could throw this, so the app has to check despite Xenomai won't fail this way, right? Ok, I understand the origin now. But indeed, as you say, legacy apps may still check for ERR_OBJTFULL or any other definition that was in the original psos.h, so Xenomai / Xenomai-forge has to supply these values as well. Ok, I'll merge this since this is explicitly defined by the original interface Xenomai does emulate. So, ok. ~Thomas -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [PATCH 0 of 4] xenomai-forge PSOS: miscellaneous fixes
On 10/26/2011 11:44 AM, Thomas De Schampheleire wrote: Hi, On Wed, Oct 19, 2011 at 5:02 PM, Thomas De Schampheleire patrickdepinguin+xeno...@gmail.com wrote: This patch series includes some misc. fixes to xenomai-forge: * definition of ERR_OBJTFULL (should also be added to Xenomai proper) * port long_names feature to xenomai-forge and fix it * add tm_getm() function (not present in pSOS but present in Xenomai proper) * fix compiler warning in task.c Signed-off-by: Thomas De Schampheleirethomas.de.schamphele...@gmail.com Signed-off-by: Ronny Meeusronny.me...@gmail.com --- include/psos/Makefile.am | 2 +- include/psos/Makefile.in | 2 +- include/psos/long_names.h | 14 ++ include/psos/psos.h | 5 + lib/psos/init.c | 15 +++ lib/psos/pt.c | 6 ++ lib/psos/queue.c | 6 ++ lib/psos/rn.c | 5 + lib/psos/sem.c| 6 ++ lib/psos/task.c | 9 +++-- lib/psos/tm.c | 7 +++ 11 files changed, 73 insertions(+), 4 deletions(-) Do you have any comments on this patch series? Merged as discussed, thanks. Thanks, Thomas ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] forge: license files
On Fri, 2011-10-21 at 12:37 +0200, Thomas De Schampheleire wrote: Hi, With respect to the source code license of xenomai-forge: there is no COPYING file in lib/psos, while there is one in most other subdirectories. I didn't check all other directories, but I guess you know better than me where there should be such a file. Thanks for the heads up. I'll add it in due time, since this is a definite hint about the license being used. However, the LGPL header is present in the psos files anyway, so this information is already available and pretty clear. Best regards, Thomas ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PSOS skin: mismatch in function signatures cause buffer overflow
On Wed, 2011-10-12 at 16:22 +0200, Gilles Chanteperdrix wrote: On 10/12/2011 04:03 PM, Thomas De Schampheleire wrote: Hi, On Mon, Sep 26, 2011 at 11:46 PM, Gilles Chanteperdrix gilles.chanteperd...@xenomai.org wrote: On 09/19/2011 10:45 AM, Thomas De Schampheleire wrote: Hi, On Mon, Sep 19, 2011 at 9:42 AM, Ronny Meeus ronny.me...@gmail.com wrote: On Mon, Sep 19, 2011 at 9:25 AM, dietmar.schind...@manroland.com wrote: From: xenomai-help-boun...@gna.org [mailto:xenomai-help-boun...@gna.org] On Behalf Of Philippe Gerum Sent: Sunday, September 18, 2011 5:37 PM ... Actually, we used to follow strictly the pSOS convention for this until 2.4.x, at which point we moved to name strings precisely because non-null terminated char[4] arrays would break the registry, the way you described. This is one of the rare situations where mimicking a useless limitation of the original API may be challenged by usability concerns in the new environment, and usability won in that case. The problem mostly comes from the fact that char[4] is automatically convertible to const char *, so we have no warning/error leading us to check the potentially problematic call sites. The concern about moving back to char[4] arrays - null-terminated if shorter - is for people who currently assign strings longer than 4 characters to name their objects. What could be done, is providing a build switch to select the accepted input, like --disable-psos-long-names to turn on char[4] interpretation. While I would prefer the switch --enable-psos-long-names, this sounds okay to me, the more so as it is more than people who use the pSOS skin without obeying pSOS rules deserve. -- [..] Another option would be to introduce a run-time switch. The default behavior could be that long names are supported and if the enable_short_names() function is called, all names will the cut at 4 characters. The advantage of this dynamic switch is that different applications using the same library can use the mode they prefer. I would also be in favor of a runtime setting, rather than a compile-time one. One cannot assume that all PSOS applications on a system follow the same rules, or that there cannot be a mix of 'legacy' PSOS applications and 'xenomai-style' ones. According to me, a library should support all these uses. Hi, here is a patch which truncates identifiers to four characters and terminates them by a '\0' character, in order to avoid the issues at the origin of this thread. The patch also adds a variable psos_long_names, 0 by default, which may be set to a non-zero value to enable the old behaviour (assume the identifier strings may be longer than 4 characters and are already null terminated). Could someone with the issue test it? It seems this slipped through the cracks, my apologies. We already implemented this ourselves similarly, we didn't actually test your patch so far. Now that we're trying out xenomai-forge, I ported this patch and tested it. There are a few problems with it (also relevant to cobalt xenomai) * a bug in __psos_maybe_short_name so that only 3 characters are retained (see below) * the call to __psos_maybe_short_name also needs to be done in the _ident functions * although we don't use it, I think the pt_create and pt_ident functions also need to be adapted Moreover, I wonder why you have made psos_long_names an exported global variable. Sharing variables between two different pieces of software is not very clean. I think it would be nicer with a get/set function. Thanks for the review. The exported global variable is the simplest possible and sufficient implementation of this feature. You risk having a hard time convincing us otherwise. Ack. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PSOS skin: mismatch in function signatures cause buffer overflow
On Wed, 2011-10-12 at 19:24 +0200, Ronny Meeus wrote: On Wed, Oct 12, 2011 at 5:56 PM, Philippe Gerum r...@xenomai.org wrote: On Wed, 2011-10-12 at 16:22 +0200, Gilles Chanteperdrix wrote: On 10/12/2011 04:03 PM, Thomas De Schampheleire wrote: Hi, On Mon, Sep 26, 2011 at 11:46 PM, Gilles Chanteperdrix gilles.chanteperd...@xenomai.org wrote: On 09/19/2011 10:45 AM, Thomas De Schampheleire wrote: Hi, On Mon, Sep 19, 2011 at 9:42 AM, Ronny Meeus ronny.me...@gmail.com wrote: On Mon, Sep 19, 2011 at 9:25 AM, dietmar.schind...@manroland.com wrote: From: xenomai-help-boun...@gna.org [mailto:xenomai-help-boun...@gna.org] On Behalf Of Philippe Gerum Sent: Sunday, September 18, 2011 5:37 PM ... Actually, we used to follow strictly the pSOS convention for this until 2.4.x, at which point we moved to name strings precisely because non-null terminated char[4] arrays would break the registry, the way you described. This is one of the rare situations where mimicking a useless limitation of the original API may be challenged by usability concerns in the new environment, and usability won in that case. The problem mostly comes from the fact that char[4] is automatically convertible to const char *, so we have no warning/error leading us to check the potentially problematic call sites. The concern about moving back to char[4] arrays - null-terminated if shorter - is for people who currently assign strings longer than 4 characters to name their objects. What could be done, is providing a build switch to select the accepted input, like --disable-psos-long-names to turn on char[4] interpretation. While I would prefer the switch --enable-psos-long-names, this sounds okay to me, the more so as it is more than people who use the pSOS skin without obeying pSOS rules deserve. -- [..] Another option would be to introduce a run-time switch. The default behavior could be that long names are supported and if the enable_short_names() function is called, all names will the cut at 4 characters. The advantage of this dynamic switch is that different applications using the same library can use the mode they prefer. I would also be in favor of a runtime setting, rather than a compile-time one. One cannot assume that all PSOS applications on a system follow the same rules, or that there cannot be a mix of 'legacy' PSOS applications and 'xenomai-style' ones. According to me, a library should support all these uses. Hi, here is a patch which truncates identifiers to four characters and terminates them by a '\0' character, in order to avoid the issues at the origin of this thread. The patch also adds a variable psos_long_names, 0 by default, which may be set to a non-zero value to enable the old behaviour (assume the identifier strings may be longer than 4 characters and are already null terminated). Could someone with the issue test it? It seems this slipped through the cracks, my apologies. We already implemented this ourselves similarly, we didn't actually test your patch so far. Now that we're trying out xenomai-forge, I ported this patch and tested it. There are a few problems with it (also relevant to cobalt xenomai) * a bug in __psos_maybe_short_name so that only 3 characters are retained (see below) * the call to __psos_maybe_short_name also needs to be done in the _ident functions * although we don't use it, I think the pt_create and pt_ident functions also need to be adapted Moreover, I wonder why you have made psos_long_names an exported global variable. Sharing variables between two different pieces of software is not very clean. I think it would be nicer with a get/set function. Thanks for the review. The exported global variable is the simplest possible and sufficient implementation of this feature. You risk having a hard time convincing us otherwise. Ack. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help Another simple solution would be to have a function available to set this mode. In that way the internal implementation can be changed without impact on the applications. I think it is always good to use a setter since this is more future safe. That function would do nothing else than setting an internal variable with a global scope, be it a function pointer. In that case, a setter brings no value, but would clutter the public interface. The problem with the cleanliness argument raised earlier is that it vastly
Re: [Xenomai-help] xenomai-forge: ELF symbol interposition problems
On Tue, 2011-10-04 at 09:40 +0200, Thomas De Schampheleire wrote: Hi, We're experiencing problems with ELF symbol interposition with xenomai forge. The symbol mem_alloc, declared in include/copperplate/heapobj.h and defined in lib/copperplate/heapobj-malloc.c, is also present in our own executable. When linking our objects with the xenomai-forge libraries, the symbols from our objects take precedence. As a result, when heapobj_alloc() calls mem_alloc(), it calls the mem_alloc from our application code, which of course is totally incompatible. There isn't really a good solution to this problem. I think it will be necessary to make sure that all exported functions from the xenomai-forge libraries have a unique name. The name 'mem_alloc' (and many of the functions in lib/copperplate/heapobj-malloc.c) is too common. Another solution may be to mark certain symbols as hidden, provided they do not need to be exported to applications. Some references to it appear here: http://www.airs.com/blog/archives/307 What is your view on this? Restricted visibility won't work the way we want, since we have references to these symbols from static inlines callable from application code. We need a rename. Thanks, Thomas ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge: ELF symbol interposition problems
On Tue, 2011-10-04 at 10:28 +0200, Thomas De Schampheleire wrote: Hi, On Tue, Oct 4, 2011 at 9:48 AM, Philippe Gerum r...@xenomai.org wrote: On Tue, 2011-10-04 at 09:40 +0200, Thomas De Schampheleire wrote: Hi, We're experiencing problems with ELF symbol interposition with xenomai forge. The symbol mem_alloc, declared in include/copperplate/heapobj.h and defined in lib/copperplate/heapobj-malloc.c, is also present in our own executable. When linking our objects with the xenomai-forge libraries, the symbols from our objects take precedence. As a result, when heapobj_alloc() calls mem_alloc(), it calls the mem_alloc from our application code, which of course is totally incompatible. There isn't really a good solution to this problem. I think it will be necessary to make sure that all exported functions from the xenomai-forge libraries have a unique name. The name 'mem_alloc' (and many of the functions in lib/copperplate/heapobj-malloc.c) is too common. Another solution may be to mark certain symbols as hidden, provided they do not need to be exported to applications. Some references to it appear here: http://www.airs.com/blog/archives/307 What is your view on this? Restricted visibility won't work the way we want, since we have references to these symbols from static inlines callable from application code. We need a rename. In the specific case I encountered, renaming the five mem_ functions worked for me. I added 'heapobj_' as prefix for: mem_destroy, mem_extend, mem_alloc, mem_free and mem_inquire. I changed them in include/copperplate/heapobj.h lib/copperplate/heapobj-malloc.c but I assume the same should be done in the other heapobj-* files. Yes, this is what I'll commit I think, only adding double underscores prefix to clearly state the fact that these are internals and should not be called directly. Best regards, Thomas -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Using the analogy layer in kernel tasks
On Tue, 2011-10-04 at 04:48 -0400, Julien Delange wrote: Dear all, I would like to know if somebody already tried to migrate code of user-space tasks that use the analogy layer to the kernel. As kernel tasks may run faster than user-space, No, it won't run that faster, it might switch contexts faster between threads, but that assumption is a fairly red herring now on most architectures, especially on modern x86. The bottom line is that you won't gain an order in magnitude in performance figures by moving to kernel land. i.e. saving 200 ns to 40 us depending on your arch on typical context switch time and maybe some more in avoiding user/supervisor transitions won't fix your 1 ms jitter. However, for sure you will lose the regular programming model, debugging facilities, memory protection and so on. Moving your application code to user space would also kill your upgrade path to Xenomai 3. The upcoming architecture clearly pushes application code to userland, keeping kernel land for RTDM drivers only. Running applications in kernel space is _always_ a really bad idea, for multiple reasons. To sum up, I would rather try to find out the cause of the ms-range jittery, which is clearly pathological over a dual kernel system. However, if your application can't cope with a few microseconds bounded jitter introduced by userland, then maybe it's time reconsidering the current option of running two kernels (linux and xenomai), which permanently conflict on accessing physical resources (e.g. cache, CPU, interrupt controller, buses), all on the same hardware. In that case, maybe what one needs is a dedicated real-time hardware running a single image RTOS, not a dual kernel system including a resource-hungry GPOS. it might help to speed application execution. However, when trying to load the application, I encounter the following errors (see below). So, is the analogy layer designed to be used in kernel tasks ? If yes, which functions are allowed, which are forbidden (and in that case, it would be useful to disable functions in /lib/modules/KERNEL_VERSION/build/include/xenomai/analogy/ headers) ? Thanks you for any comment/help regarding that topic, Best regards, [ 1560.700937] test_pcimio: Unknown symbol a4l_open (err 0) [ 1560.701100] test_pcimio: Unknown symbol __floatsidf (err 0) [ 1560.701634] test_pcimio: Unknown symbol __ltdf2 (err 0) [ 1560.701863] test_pcimio: Unknown symbol a4l_get_chinfo (err 0) [ 1560.702501] test_pcimio: Unknown symbol __fixdfsi (err 0) [ 1560.702625] test_pcimio: Unknown symbol a4l_fill_desc (err 0) [ 1560.702855] test_pcimio: Unknown symbol a4l_snd_insnlist (err 0) [ 1560.702977] test_pcimio: Unknown symbol a4l_rawtod (err 0) [ 1560.703099] test_pcimio: Unknown symbol a4l_get_rnginfo (err 0) [ 1560.703682] test_pcimio: Unknown symbol a4l_find_range (err 0) [ 1615.399804] test_pcimio: Unknown symbol a4l_open (err 0) [ 1615.399944] test_pcimio: Unknown symbol __floatsidf (err 0) [ 1615.400073] test_pcimio: Unknown symbol __ltdf2 (err 0) [ 1615.400288] test_pcimio: Unknown symbol a4l_get_chinfo (err 0) [ 1615.400288] test_pcimio: Unknown symbol __fixdfsi (err 0) [ 1615.400288] test_pcimio: Unknown symbol a4l_fill_desc (err 0) [ 1615.400786] test_pcimio: Unknown symbol a4l_snd_insnlist (err 0) [ 1615.400910] test_pcimio: Unknown symbol a4l_rawtod (err 0) [ 1615.401032] test_pcimio: Unknown symbol a4l_get_rnginfo (err 0) [ 1615.401173] test_pcimio: Unknown symbol a4l_find_range (err 0) ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge [psos] t_start segmentation fault when args == NULL
On Tue, 2011-10-04 at 11:42 +0200, Thomas De Schampheleire wrote:
Hi,
In the xenomai-forge psos library, t_start() does not allow a NULL
args pointer, while I think this is allowed in PSOS.
Yes, I think so as well. Good catch.
The below code changes fix the problem.
(Note that I realize this mail is not formatted as a proper patch; if
you prefer patches for these small changes, let me know).
I can deal with the patch below. However, git-generated patches are
preferred.
Best regards,
Thomas
diff --git a/lib/psos/task.c b/lib/psos/task.c
--- a/lib/psos/task.c
+++ b/lib/psos/task.c
@@ -335,10 +335,17 @@ u_long t_start(u_long tid,
return ret;
task-args.entry = entry;
- task-args.arg0 = args[0];
- task-args.arg1 = args[1];
- task-args.arg2 = args[2];
- task-args.arg3 = args[3];
+ if (args) {
+ task-args.arg0 = args[0];
+ task-args.arg1 = args[1];
+ task-args.arg2 = args[2];
+ task-args.arg3 = args[3];
+ } else {
+ task-args.arg0 = 0;
+ task-args.arg1 = 0;
+ task-args.arg2 = 0;
+ task-args.arg3 = 0;
+ }
task-mode = mode;
threadobj_start(task-thobj);
put_psos_task(task);
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge: enable-smp useful?
On Tue, 2011-10-04 at 11:49 +0200, Thomas De Schampheleire wrote: Hi, The original Xenomai userland had to be configured explicitly with --enable-smp if the kernel was SMP capable. The xenomai-forge configure script still accepts this parameter. Are we correctly assuming that this flag is no longer needed for xenomai-forge? This has been inherited from Xenomai 2.x. This flag is accepted whenever you want to compile for the Cobalt core (i.e. the dual kernel mode), in which case it is used as a hint for internal tuning. But since you run over the Mercury core in single image mode, it is useless so far. Thanks, Thomas ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge [psos] t_start segmentation fault when args == NULL
On Tue, 2011-10-04 at 10:42 +, dietmar.schind...@manroland.com wrote: -Original Message- On Behalf Of Thomas De Schampheleire Sent: Tuesday, October 04, 2011 11:42 AM ... In the xenomai-forge psos library, t_start() does not allow a NULL args pointer, while I think this is allowed in PSOS. The pSOSystem System Calls manual doesn't state the permissibility of a NULL args pointer, as far as I can see: unsigned long t_start( unsigned long tid, /* task identifier */ unsigned long mode, /* initial task attributes */ void (*start_addr)(), /* task address */ unsigned long targs[4] /* startup task arguments */ ) ... targs Specifies four startup values passed to the task (see Startup Values under Target). Target Startup Values ... A new task can receive up to four long words of input arguments. To facilitate retrieval of these arguments, they are passed to the task as if it is invoked as a highlevel language procedure or function. For example, if a C task nice has three input arguments, it can be declared as follows: nice (unsigned long a, unsigned long b, unsigned long c); where targs[0] is passed to a, targs[1] to b, and targs[2] to c. In this case, targs[3] is irrelevant and does not need the calling task to load it. Accepting NULL was a Xenomai-specific convenience introduced in Xenomai 2.x IIRC, then I changed my mind for 3.x. Granted NULL args would not work when back on real pSOS, but that does not look like a hot issue. So we should probably just accept it anew, and be happy. -- Regards, Dietmar manroland AG Vorsitzender des Aufsichtsrates: Hanno C. Fiedler Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592 USt-Ident-Nr. DE 250200933 ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
On Mon, 2011-09-26 at 22:01 +0200, Ronny Meeus wrote:
snip
Next to this I also adapted the task priority automatically using
following algorithm:
static int check_task_priority(u_long *psos_prio)
{
if (*psos_prio 1 || *psos_prio 255) /* In theory. */
return ERR_PRIOR;
/* Do not change priorities =10 and = 240.
* Priorities in between are divided by 4 */
if (*psos_prio 240)
*psos_prio = 70 + *psos_prio - 240;
else if (*psos_prio 10)
*psos_prio = 11 + ((*psos_prio-10)/4);
if ((int)(*psos_prio) = threadobj_max_prio - 1) /* In practice. */
panic(current implementation restricts pSOS
priority levels to range [1..%d],
threadobj_max_prio - 2);
return SUCCESS;
}
It also works well for our application.
Please share your thoughts.
Since we cannot generalize the priority mapping rules, a better way may
be to allow your own code to be called by the pSOS emulator when such
mapping is required. So I have committed a tentative solution, defining
psos_task_normalize_priority() as a weak function, which receives the
pSOS priority, and should return the POSIX one.
A default implementation is provided by the emulator which does a
trivial 1:1 mapping.
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge [psos] t_start segmentation fault when args == NULL
On Tue, 2011-10-04 at 23:11 +0200, Ronny Meeus wrote: On Tue, Oct 4, 2011 at 2:00 PM, Philippe Gerum r...@xenomai.org wrote: On Tue, 2011-10-04 at 10:42 +, dietmar.schind...@manroland.com wrote: -Original Message- On Behalf Of Thomas De Schampheleire Sent: Tuesday, October 04, 2011 11:42 AM ... In the xenomai-forge psos library, t_start() does not allow a NULL args pointer, while I think this is allowed in PSOS. The pSOSystem System Calls manual doesn't state the permissibility of a NULL args pointer, as far as I can see: unsigned long t_start( unsigned long tid, /* task identifier */ unsigned long mode, /* initial task attributes */ void (*start_addr)(), /* task address */ unsigned long targs[4] /* startup task arguments */ ) ... targs Specifies four startup values passed to the task (see Startup Values under Target). Target Startup Values ... A new task can receive up to four long words of input arguments. To facilitate retrieval of these arguments, they are passed to the task as if it is invoked as a highlevel language procedure or function. For example, if a C task nice has three input arguments, it can be declared as follows: nice (unsigned long a, unsigned long b, unsigned long c); where targs[0] is passed to a, targs[1] to b, and targs[2] to c. In this case, targs[3] is irrelevant and does not need the calling task to load it. Accepting NULL was a Xenomai-specific convenience introduced in Xenomai 2.x IIRC, then I changed my mind for 3.x. Granted NULL args would not work when back on real pSOS, but that does not look like a hot issue. So we should probably just accept it anew, and be happy. -- Regards, Dietmar manroland AG Vorsitzender des Aufsichtsrates: Hanno C. Fiedler Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592 USt-Ident-Nr. DE 250200933 ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help Hello I think that it is supported since our application does pass a NULL pointer as args argument. The application is originally created in a real pSOS environment 12 years ago. Ok. Was this running on MMU-enabled hw? Anyhow thanks for changing it. Ronny -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] xenomai-forge: cast to pointer from integer of different size
On Fri, 2011-09-30 at 21:53 +0200, Thomas De Schampheleire wrote:
Hi,
I'm trying to compile xenomai-forge on powerpc, but am facing
compilation problems:
libtool: compile:
/repo/tdescham/reborn/buildroot-08-eglibc-test-toolchain/output/host/usr/bin/powerpc-linux-gcc
-DHAVE_CONFIG_H -I. -I../../lib/include -O2 -D_GNU_SOURCE -D_REENTRANT
-Wall -pipe -Wstrict-prototypes -Wmissing-prototypes -Wno-long-long
-Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
-Wstrict-prototypes -I../../include -pipe -Os -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT
libcopperplate_la-cluster.lo -MD -MP -MF
.deps/libcopperplate_la-cluster.Tpo -c cluster.c -fPIC -DPIC -o
.libs/libcopperplate_la-cluster.o
cc1: warnings being treated as errors
In file included from cluster.c:89:
../../include/copperplate/heapobj.h: In function 'mainheap_ptr':
../../include/copperplate/heapobj.h:82: error: cast to pointer from
integer of different size
../../include/copperplate/heapobj.h: In function 'mainheap_off':
../../include/copperplate/heapobj.h:87: error: cast from pointer to
integer of different size
cc1: warnings being treated as errors
The C library we are using for this build is eglibc.
The offending code is:
static inline void *mainheap_ptr(off_t off)
{
return off ? (void *)__memptr(__pshared_heap, off) : NULL;
}
static inline off_t mainheap_off(void *addr)
{
return addr ? (off_t)__memoff(__pshared_heap, addr) : 0;
}
Since glibc/eglibc has large file support, the size of off_t is 8
bytes (I confirmed this from the preprocessor output).
However, on this 32-bit powerpc platform, a void pointer is only 4
bytes, hence the compiler error.
Is my assumption correct that you are developing xenomai-forge on a
64-bit platform?
Both on ppc 32bit and x86_64, but my ppc toolchain does not enable large
file support.
What is the proper solution here?
Use a specific memory offset type would be the best approach. I have
committed something along these lines to the repo.
Thanks,
Thomas
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai 2.6.0-rc4
On Wed, 2011-09-28 at 20:34 +0200, Gilles Chanteperdrix wrote: Hi, here is the 4th release candidate for Xenomai 2.6.0: http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc4.tar.bz2 Novelties since -rc3 include: - a fix for the long names issue on psos+ - a fix for the build issue of mscan on mpc52xx (please Wolfgang, have a look at the patch, to see if you like it:) http://git.xenomai.org/?p=xenomai-head.git;a=commitdiff;h=d22fd231db7eb0af8e77ec570efb89e578e13781;hp=4a2188f049e96fc59aa7c4a7a9d058075f3d79e8 - a new version of the I-pipe patch for linux 3.0 on ppc. People running 2.13-02/powerpc over linux 3.0.4 should definitely upgrade to 2.13-03, or apply this: http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=7c28eb2dea86366bf721663bb8d28ce89cf2806c This should be the last release candidate. Regards. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai-forge: tm_evafter without tm_cancel causes memory leaks.
On Mon, 2011-09-26 at 23:28 +0200, Ronny Meeus wrote: Hello As for as I know it is not mandatory call tm_cancel on a one-shot timer to cleanup the resources in the OS. This means that if the timer expires, the event is sent and all resources are released by pSOS at that time. Since I did not see a test for this in the testsuite, I created one myself (in fact 2, see attachments). This time it is a small piece of code :-). In this test I create a task that starts 100 events timers (tm_evafter) but does not stop them (no tm_cancel is called). In the first test (tm-10.c) I create a task that starts 100 timers, sleeps some time and deletes itself. This sleeping allows the timers to expire. This is the result if I run valgrind: [snip] So it looks like the contexts allocated in start_evtimer are at least lost, but valgrind mentions another 100 blocks that are still reachable but I think these are in fact also lost since these are referenced by the timer contexs. [snip] Ack, it would not make sense to leave elapsed oneshot timers alive. The code is now fixed. I also have created a similar test application (tm-11), but in this code the sleep is not there. This means the timers are still running while killing the task. When running this test, I see an invalid read: Confirmed. Albeit the deletion code was there, it was badly broken. At this chance, the invalid timer error code returned by all timer routines has been fixed as well. I merged a slightly adapted version of these tests as tm-6 and tm-7 in the psos testsuite. Thanks. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
On Fri, 2011-09-23 at 22:23 +0200, Philippe Gerum wrote:
On Fri, 2011-09-23 at 22:21 +0200, Ronny Meeus wrote:
On Fri, Sep 23, 2011 at 3:00 PM, Philippe Gerum r...@xenomai.org wrote:
On Thu, 2011-09-22 at 22:15 +0200, Ronny Meeus wrote:
Hello
I have created some time ago a test application for the PSOS interface
of Xenomai.
This is a extensive test that stresses most of the PSOS services we
use in our application. You can find it as an attachment.
It is running fine on Xenomai 2-5-6.
Note that in the test application there is also a benchmarking part.
This is currently disabled, I will fix that later.
Now I'm investigating a switch to xenomai-forge so I tried to run the
same test on this platform.
This is a double cleanup call, due to the incorrect propagation of an
internal error detected in the task trampoline within the psos emulator.
In fact, this reveals a more general shortcoming with handling this
situation for tasks, and this may also reveal an issue with t_delete()
over the Mercury core.
I can't reproduce the issue here with your test program, but I'm sure
something is wrong in the emulator anyway, I'm just lucky with the
timings. Since you are running over the vanilla kernel and maybe x86,
you could run valgrind to check whether some memory corruption is
detected.
I'm working on this bug which will bite any emulator based on the
copperplate interface the same way. I don't see any show stopper to fix
it, but this needs some thoughts to do this properly.
Btw,
- what is your architecture?
- what is your glibc version?
Running on a PC (virtual BOX).
This is the information about the lib I use:
meeusr@meeusr-laptop:/lib$ ./libc.so.6
GNU C Library (Ubuntu EGLIBC 2.11.1-0ubuntu7.6) stable release version
2.11.1, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.3.
Compiled on a Linux 2.6.24-27-server system on 2010-11-17.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
http://www.debian.org/Bugs/.
The valgrind stuff I will do later.
I can reproduce now. This is highly timing dependent.
git://git.xenomai.org/xenomai-forge.git has a general fix for this
issue. Your test code will need the following patch to work. The basic
fix is that you can't create multiple objects with the same name with
Xenomai, because we need unique names for the registry to be meaningful.
I reduced the number of test loops as well, since 100 or 1000 loops do
not make any difference. Actually, two consecutive iterations of
t_create/t_delete were enough to trigger the issue.
--- rtprint.c.orig 2011-09-26 12:38:47.711339003 +0200
+++ rtprint.c 2011-09-26 12:37:49.871339005 +0200
@@ -115,7 +115,7 @@
my_printf(%s\n,__FUNCTION__);
- check(t_create,t_create(TEST,250,16000,16000,0,tid),0);
+ check(t_create,t_create(NULL,96,16000,16000,0,tid),0);
check(t_setreg,t_setreg(tid,0UL,100UL),0);
check(t_getreg,t_getreg(tid,0UL,reg_value),0);
check(reg_value,reg_value,100);
@@ -150,7 +150,7 @@
suspendmyself = 0;
- check(t_create,t_create(TEST,250,16000,16000,0,tid),0);
+ check(t_create,t_create(NULL,96,16000,16000,0,tid),0);
check(t_start,t_start(tid,0,test_tasksuspend_body,args),0);
counter = 0;
@@ -201,7 +201,7 @@
static void create_and_start_task(unsigned long *tid)
{
unsigned long local_args[4] = {0,200,300,400};
- check(t_create low prio,t_create (TEST,2,4000,0,T_LOCAL,tid),0);
+ check(t_create low prio,t_create (NULL,2,4000,0,T_LOCAL,tid),0);
check(t_start low
prio,t_start(*tid,T_PREEMPT|T_TSLICE,test_taskcreation_body,local_args),0);
}
@@ -219,7 +219,7 @@
for (i=1;i2;i++)
{
- check(t_create,t_create(TEST,(unsigned
long)i,16000,16000,0,tid),0);
+ check(t_create,t_create(NULL,(unsigned
long)i,16000,16000,0,tid),0);
check(t_start,t_start(tid,T_PREEMPT| T_TSLICE |
T_NOASR,test_taskcreation_body2,args),0);
}
@@ -260,7 +260,7 @@
args[0] = 0;
for (i=0;i500;i++)
{
- check(t_create loop3,t_create
(TEST,(i%250)+1,10,0,0,tid),0);
+ check(t_create loop3,t_create
(TEST,(i%96)+1,10,0,0,tid),0);
check(t_start
loop3,t_start(tid,T_PREEMPT,test_taskcreation_body,args),0);
check(t_delete loop3,t_delete(tid),0);
my_printf(t_create + t_start
Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
On Thu, 2011-09-22 at 22:15 +0200, Ronny Meeus wrote:
Hello
I have created some time ago a test application for the PSOS interface
of Xenomai.
This is a extensive test that stresses most of the PSOS services we
use in our application. You can find it as an attachment.
It is running fine on Xenomai 2-5-6.
Nope, actually it does not, at all. It can't work in any 2.x series by
design actually, and we have the very same synchronization issue which
has just been fixed in -forge. We just happen to be lucky with timings,
likely due to the additional interactions we have with the dual kernel.
Note that in the test application there is also a benchmarking part.
This is currently disabled, I will fix that later.
Now I'm investigating a switch to xenomai-forge so I tried to run the
same test on this platform.
This is the version I'm using (downloaded today):
meeusr@meeusr-laptop:~/repo/xenomai-forge$ git log | head
commit 04b776ed9ff18e197ae43ee552b8e77f42c5e5cb
Author: Philippe Gerum r...@xenomai.org
Date: Wed Sep 21 21:08:42 2011 +0200
psos: fix t_ident() with NULL name
The configuration I did:
./configure --prefix=/home/meeusr/repo/xenomai-forge-install
--enable-debug --with-core=mercury
After adding the test to the makefile of the lib/psos/testsuite and
compiling it, I start it by giving the command:
sudo LD_LIBRARY_PATH=/home/meeusr/repo/xenomai-forge-install/lib/ gdb
./rtprint
After some time I observe a crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa7b5d870 (LWP 14707)]
0x00140749 in dtpvh (holder=0x80cfc7c) at
../../include/copperplate/private-list.h:59
59holder-prev-next = holder-next;
(gdb) bt
#0 0x00140749 in dtpvh (holder=0x80cfc7c) at
../../include/copperplate/private-list.h:59
#1 0x0014079c in pvlist_remove_init (holder=0x80cfc7c) at
../../include/copperplate/private-list.h:120
#2 0x00140e89 in notifier_destroy (nf=0x80cfc48) at notifier.c:195
#3 0x0013fb68 in threadobj_finalize (p=0x80cfbb0) at threadobj-mercury.c:161
#4 0x0014a3ef in __nptl_deallocate_tsd () at pthread_create.c:155
#5 0x0014a97c in start_thread (arg=0xa7b5d870) at pthread_create.c:307
#6 0x00234a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) print *holder
$1 = {next = 0x2, prev = 0x200}
It looks like the holder structure is getting corrupted and this
results in a crash while destroying a task. Please note that this is
not the case all the time, e.g. there are already tasks destroyed
before.
Does anybody has a clue about the problem or how I have to proceed
with the investigation?
Thanks.
Ronny
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
On Mon, 2011-09-26 at 22:02 +0200, Ronny Meeus wrote:
On Mon, Sep 26, 2011 at 12:49 PM, Philippe Gerum r...@xenomai.org wrote:
On Thu, 2011-09-22 at 22:15 +0200, Ronny Meeus wrote:
Hello
I have created some time ago a test application for the PSOS interface
of Xenomai.
This is a extensive test that stresses most of the PSOS services we
use in our application. You can find it as an attachment.
It is running fine on Xenomai 2-5-6.
Nope, actually it does not, at all. It can't work in any 2.x series by
design actually, and we have the very same synchronization issue which
has just been fixed in -forge. We just happen to be lucky with timings,
likely due to the additional interactions we have with the dual kernel.
See my previous reply.
We had a mechanism to make tasknames unique.
The task name issue is not related to the current synchronization bug in
all 2.x series for creating pSOS tasks. Regardless of their names, pSOS
tasks in 2.x are potentially at risk if t_delete() is issued for them
while emerging in the task trampoline code.
Note that in the test application there is also a benchmarking part.
This is currently disabled, I will fix that later.
Now I'm investigating a switch to xenomai-forge so I tried to run the
same test on this platform.
This is the version I'm using (downloaded today):
meeusr@meeusr-laptop:~/repo/xenomai-forge$ git log | head
commit 04b776ed9ff18e197ae43ee552b8e77f42c5e5cb
Author: Philippe Gerum r...@xenomai.org
Date: Wed Sep 21 21:08:42 2011 +0200
psos: fix t_ident() with NULL name
The configuration I did:
./configure --prefix=/home/meeusr/repo/xenomai-forge-install
--enable-debug --with-core=mercury
After adding the test to the makefile of the lib/psos/testsuite and
compiling it, I start it by giving the command:
sudo LD_LIBRARY_PATH=/home/meeusr/repo/xenomai-forge-install/lib/ gdb
./rtprint
After some time I observe a crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa7b5d870 (LWP 14707)]
0x00140749 in dtpvh (holder=0x80cfc7c) at
../../include/copperplate/private-list.h:59
59holder-prev-next = holder-next;
(gdb) bt
#0 0x00140749 in dtpvh (holder=0x80cfc7c) at
../../include/copperplate/private-list.h:59
#1 0x0014079c in pvlist_remove_init (holder=0x80cfc7c) at
../../include/copperplate/private-list.h:120
#2 0x00140e89 in notifier_destroy (nf=0x80cfc48) at notifier.c:195
#3 0x0013fb68 in threadobj_finalize (p=0x80cfbb0) at
threadobj-mercury.c:161
#4 0x0014a3ef in __nptl_deallocate_tsd () at pthread_create.c:155
#5 0x0014a97c in start_thread (arg=0xa7b5d870) at pthread_create.c:307
#6 0x00234a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) print *holder
$1 = {next = 0x2, prev = 0x200}
It looks like the holder structure is getting corrupted and this
results in a crash while destroying a task. Please note that this is
not the case all the time, e.g. there are already tasks destroyed
before.
Does anybody has a clue about the problem or how I have to proceed
with the investigation?
Thanks.
Ronny
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
On Mon, 2011-09-26 at 22:01 +0200, Ronny Meeus wrote:
On Mon, Sep 26, 2011 at 12:46 PM, Philippe Gerum r...@xenomai.org wrote:
On Fri, 2011-09-23 at 22:23 +0200, Philippe Gerum wrote:
On Fri, 2011-09-23 at 22:21 +0200, Ronny Meeus wrote:
On Fri, Sep 23, 2011 at 3:00 PM, Philippe Gerum r...@xenomai.org wrote:
On Thu, 2011-09-22 at 22:15 +0200, Ronny Meeus wrote:
Hello
I have created some time ago a test application for the PSOS interface
of Xenomai.
This is a extensive test that stresses most of the PSOS services we
use in our application. You can find it as an attachment.
It is running fine on Xenomai 2-5-6.
Note that in the test application there is also a benchmarking part.
This is currently disabled, I will fix that later.
Now I'm investigating a switch to xenomai-forge so I tried to run the
same test on this platform.
This is a double cleanup call, due to the incorrect propagation of an
internal error detected in the task trampoline within the psos
emulator.
In fact, this reveals a more general shortcoming with handling this
situation for tasks, and this may also reveal an issue with t_delete()
over the Mercury core.
I can't reproduce the issue here with your test program, but I'm sure
something is wrong in the emulator anyway, I'm just lucky with the
timings. Since you are running over the vanilla kernel and maybe x86,
you could run valgrind to check whether some memory corruption is
detected.
I'm working on this bug which will bite any emulator based on the
copperplate interface the same way. I don't see any show stopper to fix
it, but this needs some thoughts to do this properly.
Btw,
- what is your architecture?
- what is your glibc version?
Running on a PC (virtual BOX).
This is the information about the lib I use:
meeusr@meeusr-laptop:/lib$ ./libc.so.6
GNU C Library (Ubuntu EGLIBC 2.11.1-0ubuntu7.6) stable release version
2.11.1, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.3.
Compiled on a Linux 2.6.24-27-server system on 2010-11-17.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
http://www.debian.org/Bugs/.
The valgrind stuff I will do later.
I can reproduce now. This is highly timing dependent.
git://git.xenomai.org/xenomai-forge.git has a general fix for this
issue. Your test code will need the following patch to work. The basic
fix is that you can't create multiple objects with the same name with
Xenomai, because we need unique names for the registry to be meaningful.
Thanks for looking into this issue.
The problem that we have is that we have a huge application and we
cannot guarantee that all tasknames are unique.
That is why I have implemented a mechanism to make a taskname unique
(I already had this in the Xenomai-2.5.6). In the force version this
could be something like:
if (name == NULL || *name == '\0')
sprintf(task-name, t%lu, ++anon_tids);
else {
struct clusterobj *cobj =
cluster_findobj(psos_task_table, name);
if (cobj != NULL) {
snprintf(task-name,sizeof(task-name),
%s@%lu, name, ++anon_tids);
}
else
strncpy(task-name, name, sizeof(task-name));
task-name[sizeof(task-name) - 1] = '\0';
}
This is an example for tasks. The same could be done for
regions,semaphores and message queues. I tried it on my repo and the
task application (rtprint) runs unmodified.
The only issue I see with this approach is that when 2 tasks with an
identical name, for example TEST, are created, the second one will be
mapped to TEST@1. If a t_ident call is executed, the TID of the first
instance will be returned, which is fine. If now the first task is
deleted, the t_ident call will fail.
Which demonstrates that t_ident() is broken by design since pSOS does
not enforce name uniqueness, anyway.
Next to this I also adapted the task priority automatically using
following algorithm:
static int check_task_priority(u_long *psos_prio)
{
if (*psos_prio 1 || *psos_prio 255) /* In theory. */
return ERR_PRIOR;
/* Do not change priorities =10 and = 240.
* Priorities in between are divided by 4 */
if (*psos_prio 240)
*psos_prio = 70 + *psos_prio - 240;
else if (*psos_prio 10)
*psos_prio = 11
Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
On Thu, 2011-09-22 at 22:15 +0200, Ronny Meeus wrote:
Hello
I have created some time ago a test application for the PSOS interface
of Xenomai.
This is a extensive test that stresses most of the PSOS services we
use in our application. You can find it as an attachment.
It is running fine on Xenomai 2-5-6.
Note that in the test application there is also a benchmarking part.
This is currently disabled, I will fix that later.
Now I'm investigating a switch to xenomai-forge so I tried to run the
same test on this platform.
This is a double cleanup call, due to the incorrect propagation of an
internal error detected in the task trampoline within the psos emulator.
In fact, this reveals a more general shortcoming with handling this
situation for tasks, and this may also reveal an issue with t_delete()
over the Mercury core.
I can't reproduce the issue here with your test program, but I'm sure
something is wrong in the emulator anyway, I'm just lucky with the
timings. Since you are running over the vanilla kernel and maybe x86,
you could run valgrind to check whether some memory corruption is
detected.
I'm working on this bug which will bite any emulator based on the
copperplate interface the same way. I don't see any show stopper to fix
it, but this needs some thoughts to do this properly.
Btw,
- what is your architecture?
- what is your glibc version?
This is the version I'm using (downloaded today):
meeusr@meeusr-laptop:~/repo/xenomai-forge$ git log | head
commit 04b776ed9ff18e197ae43ee552b8e77f42c5e5cb
Author: Philippe Gerum r...@xenomai.org
Date: Wed Sep 21 21:08:42 2011 +0200
psos: fix t_ident() with NULL name
The configuration I did:
./configure --prefix=/home/meeusr/repo/xenomai-forge-install
--enable-debug --with-core=mercury
After adding the test to the makefile of the lib/psos/testsuite and
compiling it, I start it by giving the command:
sudo LD_LIBRARY_PATH=/home/meeusr/repo/xenomai-forge-install/lib/ gdb
./rtprint
After some time I observe a crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa7b5d870 (LWP 14707)]
0x00140749 in dtpvh (holder=0x80cfc7c) at
../../include/copperplate/private-list.h:59
59holder-prev-next = holder-next;
(gdb) bt
#0 0x00140749 in dtpvh (holder=0x80cfc7c) at
../../include/copperplate/private-list.h:59
#1 0x0014079c in pvlist_remove_init (holder=0x80cfc7c) at
../../include/copperplate/private-list.h:120
#2 0x00140e89 in notifier_destroy (nf=0x80cfc48) at notifier.c:195
#3 0x0013fb68 in threadobj_finalize (p=0x80cfbb0) at threadobj-mercury.c:161
#4 0x0014a3ef in __nptl_deallocate_tsd () at pthread_create.c:155
#5 0x0014a97c in start_thread (arg=0xa7b5d870) at pthread_create.c:307
#6 0x00234a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) print *holder
$1 = {next = 0x2, prev = 0x200}
It looks like the holder structure is getting corrupted and this
results in a crash while destroying a task. Please note that this is
not the case all the time, e.g. there are already tasks destroyed
before.
Does anybody has a clue about the problem or how I have to proceed
with the investigation?
Thanks.
Ronny
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
On Fri, 2011-09-23 at 22:21 +0200, Ronny Meeus wrote:
On Fri, Sep 23, 2011 at 3:00 PM, Philippe Gerum r...@xenomai.org wrote:
On Thu, 2011-09-22 at 22:15 +0200, Ronny Meeus wrote:
Hello
I have created some time ago a test application for the PSOS interface
of Xenomai.
This is a extensive test that stresses most of the PSOS services we
use in our application. You can find it as an attachment.
It is running fine on Xenomai 2-5-6.
Note that in the test application there is also a benchmarking part.
This is currently disabled, I will fix that later.
Now I'm investigating a switch to xenomai-forge so I tried to run the
same test on this platform.
This is a double cleanup call, due to the incorrect propagation of an
internal error detected in the task trampoline within the psos emulator.
In fact, this reveals a more general shortcoming with handling this
situation for tasks, and this may also reveal an issue with t_delete()
over the Mercury core.
I can't reproduce the issue here with your test program, but I'm sure
something is wrong in the emulator anyway, I'm just lucky with the
timings. Since you are running over the vanilla kernel and maybe x86,
you could run valgrind to check whether some memory corruption is
detected.
I'm working on this bug which will bite any emulator based on the
copperplate interface the same way. I don't see any show stopper to fix
it, but this needs some thoughts to do this properly.
Btw,
- what is your architecture?
- what is your glibc version?
Running on a PC (virtual BOX).
This is the information about the lib I use:
meeusr@meeusr-laptop:/lib$ ./libc.so.6
GNU C Library (Ubuntu EGLIBC 2.11.1-0ubuntu7.6) stable release version
2.11.1, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.3.
Compiled on a Linux 2.6.24-27-server system on 2010-11-17.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
http://www.debian.org/Bugs/.
The valgrind stuff I will do later.
I can reproduce now. This is highly timing dependent.
This is the version I'm using (downloaded today):
meeusr@meeusr-laptop:~/repo/xenomai-forge$ git log | head
commit 04b776ed9ff18e197ae43ee552b8e77f42c5e5cb
Author: Philippe Gerum r...@xenomai.org
Date: Wed Sep 21 21:08:42 2011 +0200
psos: fix t_ident() with NULL name
The configuration I did:
./configure --prefix=/home/meeusr/repo/xenomai-forge-install
--enable-debug --with-core=mercury
After adding the test to the makefile of the lib/psos/testsuite and
compiling it, I start it by giving the command:
sudo LD_LIBRARY_PATH=/home/meeusr/repo/xenomai-forge-install/lib/ gdb
./rtprint
After some time I observe a crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa7b5d870 (LWP 14707)]
0x00140749 in dtpvh (holder=0x80cfc7c) at
../../include/copperplate/private-list.h:59
59holder-prev-next = holder-next;
(gdb) bt
#0 0x00140749 in dtpvh (holder=0x80cfc7c) at
../../include/copperplate/private-list.h:59
#1 0x0014079c in pvlist_remove_init (holder=0x80cfc7c) at
../../include/copperplate/private-list.h:120
#2 0x00140e89 in notifier_destroy (nf=0x80cfc48) at notifier.c:195
#3 0x0013fb68 in threadobj_finalize (p=0x80cfbb0) at
threadobj-mercury.c:161
#4 0x0014a3ef in __nptl_deallocate_tsd () at pthread_create.c:155
#5 0x0014a97c in start_thread (arg=0xa7b5d870) at pthread_create.c:307
#6 0x00234a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) print *holder
$1 = {next = 0x2, prev = 0x200}
It looks like the holder structure is getting corrupted and this
results in a crash while destroying a task. Please note that this is
not the case all the time, e.g. there are already tasks destroyed
before.
Does anybody has a clue about the problem or how I have to proceed
with the investigation?
Thanks.
Ronny
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
Ronny
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] pSOS skin in xenomai-solo
On Tue, 2011-09-20 at 13:10 +0200, Ronny Meeus wrote: Hello We have ported a large pSOS based application to an Embedded Linux environment using Xenomai. A more or less stable version is running at this moment. The application is not a real-time application at all, we basically selected Xenomai for its pSOS interface. Since our application uses also native Linux calls (for example socket communication), we start to see some strange behavior. Example: lower priority tasks are running in the xenomai domain while higher priority tasks, sending data on a socket for example, have to wait until all processing in the Xenomai domain is completed. My feeling is that the Solo project would be better for us. As far as I understand, this is just a thin layer on top of Linux, purely running in user space that also offers the pSOS interface. Is my understanding correct? If it is, I would think that the socket issue described above will be automatically solved since there will only be 1 scheduler (the Linux one) and it will respect the thread/task priorities. What is the status of this project? https://mail.gna.org/public/xenomai-help/2011-06/msg00229.html Since this mail was posted, there has been a significant work on the -forge tree, you may want to have a look at the README git://git.xenomai.org/xenomai-forge.git This is NOT production grade yet, current lack of documentation is blatant as well, but AFAICT, this meets my expectations design-wise, and runtime-wise. Lot of work ahead though. You may want to try running the psos testsuite from lib/psos/testsuite, over the so-called Mercury core. You could do this as follows: $ .../xenomai-forge/configure --with-core=mercury --prefix=/ $ make install DESTDIR=/foo $ cd .../xenomai-forge/lib/psos/testsuite $ make DESTDIR=/foo test (*) (*) will require the current account to be sudoer Regards, Ronny ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] pSOS skin in xenomai-solo
On Tue, 2011-09-20 at 13:10 +0200, Ronny Meeus wrote: Hello We have ported a large pSOS based application to an Embedded Linux environment using Xenomai. A more or less stable version is running at this moment. The application is not a real-time application at all, we basically selected Xenomai for its pSOS interface. Since our application uses also native Linux calls (for example socket communication), we start to see some strange behavior. Example: lower priority tasks are running in the xenomai domain while higher priority tasks, sending data on a socket for example, have to wait until all processing in the Xenomai domain is completed. My feeling is that the Solo project would be better for us. As far as I understand, this is just a thin layer on top of Linux, purely running in user space that also offers the pSOS interface. Is my understanding correct? Yes. If it is, I would think that the socket issue described above will be automatically solved since there will only be 1 scheduler (the Linux one) and it will respect the thread/task priorities. True, but in purely Linux native mode, note that your app would be restricted to use VxWorks priorities between 0 and 98 inclusive. What is the status of this project? Regards, Ronny ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] pSOS skin in xenomai-solo
On Wed, 2011-09-21 at 14:35 +0200, Philippe Gerum wrote: On Tue, 2011-09-20 at 13:10 +0200, Ronny Meeus wrote: Hello We have ported a large pSOS based application to an Embedded Linux environment using Xenomai. A more or less stable version is running at this moment. The application is not a real-time application at all, we basically selected Xenomai for its pSOS interface. Since our application uses also native Linux calls (for example socket communication), we start to see some strange behavior. Example: lower priority tasks are running in the xenomai domain while higher priority tasks, sending data on a socket for example, have to wait until all processing in the Xenomai domain is completed. My feeling is that the Solo project would be better for us. As far as I understand, this is just a thin layer on top of Linux, purely running in user space that also offers the pSOS interface. Is my understanding correct? Yes. If it is, I would think that the socket issue described above will be automatically solved since there will only be 1 scheduler (the Linux one) and it will respect the thread/task priorities. True, but in purely Linux native mode, note that your app would be restricted to use VxWorks priorities between 0 and 98 inclusive. 0 and 97 inclusive, the two highest priority levels are reserved for internal use. What is the status of this project? Regards, Ronny ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] pSOS skin in xenomai-solo
On Wed, 2011-09-21 at 18:27 +0200, Ronny Meeus wrote: On Wed, Sep 21, 2011 at 2:41 PM, Philippe Gerum r...@xenomai.org wrote: On Wed, 2011-09-21 at 14:35 +0200, Philippe Gerum wrote: On Tue, 2011-09-20 at 13:10 +0200, Ronny Meeus wrote: Hello We have ported a large pSOS based application to an Embedded Linux environment using Xenomai. A more or less stable version is running at this moment. The application is not a real-time application at all, we basically selected Xenomai for its pSOS interface. Since our application uses also native Linux calls (for example socket communication), we start to see some strange behavior. Example: lower priority tasks are running in the xenomai domain while higher priority tasks, sending data on a socket for example, have to wait until all processing in the Xenomai domain is completed. My feeling is that the Solo project would be better for us. As far as I understand, this is just a thin layer on top of Linux, purely running in user space that also offers the pSOS interface. Is my understanding correct? Yes. If it is, I would think that the socket issue described above will be automatically solved since there will only be 1 scheduler (the Linux one) and it will respect the thread/task priorities. True, but in purely Linux native mode, note that your app would be restricted to use VxWorks priorities between 0 and 98 inclusive. pSOS you mean ... Yes, same issue. I can live with that since we convert the priority. 0 and 97 inclusive, the two highest priority levels are reserved for internal use. What is the status of this project? Regards, Ronny ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe. I was playing with the xenomai solo in today and I found some issue. It is also present in the -force repository. If you pass in pSOS a 0 as name to the t_ident (lib/psos/task.c) service call, it will return the taskId of the current running task. In the current implementation this call crashes with a segmentation fault. This should be fixed in the repo now. Ronny -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PSOS skin: mismatch in function signatures cause buffer overflow
On Fri, 2011-09-16 at 14:59 +0200, Thomas De Schampheleire wrote:
Hi,
The original PSOS interfaces that take a name (like t_create,
sm_create etc), expect a character array with length 4:
unsigned long t_create(char name[4], unsigned long prio, unsigned long
sstack, unsigned long ustack, unsigned long flags, unsigned long
*tid);
unsigned long sm_create(char name[4], unsigned long count, unsigned
long flags, unsigned long *smid);
while the corresponding PSOS skin in Xenomai expects a null-terminated
character array (a real string):
u_long t_create(const char *name, u_long prio, u_long sstack, u_long
ustack, u_long flags, u_long *tid_r);
u_long sm_create(const char *name, u_long icount, u_long flags, u_long
*smid_r);
In certain situations, this difference gives rise to a buffer overflow
on the name variable.
For example:
unsigned long smid, err;
{
char id[4] = {'S','E','M','0'};
err = sm_create(id,0,SM_PRIOR,smid);
}
{
char id[4] = SEM;
id[3] = '1';
err = sm_create(id,0,SM_PRIOR,smid);
}
{
char id[4] = SEM2;
err = sm_create(id,0,SM_PRIOR,smid);
}
{
char id[4] = MySemaphore;
err = sm_create(id,0,SM_PRIOR,smid);
}
The first two examples are perfectly valid code. The third one (SEM2)
is dubious because the end-of-string character will overflow the
array, although the compiler does not complain. The fourth example
(MySemaphore) obviously is an array-overflow and is indeed warned upon
by the compiler.
On target, this creates the following semaphores (taken from the registry):
# ls /proc/xenomai/registry/psos/semaphores/SEM*
/proc/xenomai/registry/psos/semaphores/My*
/proc/xenomai/registry/psos/semaphores/MySeAB4abca
/proc/xenomai/registry/psos/semaphores/SEM0p_S22753
/proc/xenomai/registry/psos/semaphores/SEM1p_S22753
/proc/xenomai/registry/psos/semaphores/SEM2?_S22753
As you can see, in all cases there was an array overflow (the question
marks correspond to non-ASCII characters), caused by the missing
null-termination (in itself caused by a mismatch between the original
PSOS interface and the Xenomai PSOS skin implementation of it).
If you do not explicitly create a character array of length 4, e.g.
(char id[] = SEM1) then the Xenomai code obviously works fine: it
receives a null-terminated string, as it expects.
To fix this problem, the PSOS skin should treat incoming names as
non-null-terminated character arrays of length 4, and explicitly add
null-termination before passing it to the nucleus.
What is your view on this?
Actually, we used to follow strictly the pSOS convention for this until
2.4.x, at which point we moved to name strings precisely because
non-null terminated char[4] arrays would break the registry, the way you
described. This is one of the rare situations where mimicking a useless
limitation of the original API may be challenged by usability concerns
in the new environment, and usability won in that case. The problem
mostly comes from the fact that char[4] is automatically convertible to
const char *, so we have no warning/error leading us to check the
potentially problematic call sites.
The concern about moving back to char[4] arrays - null-terminated if
shorter - is for people who currently assign strings longer than 4
characters to name their objects. What could be done, is providing a
build switch to select the accepted input, like
--disable-psos-long-names to turn on char[4] interpretation.
Thanks,
Thomas
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] PWM generation with GPIO
On Thu, 2011-09-08 at 12:06 +0200, Gilles Chanteperdrix wrote: On 09/08/2011 11:30 AM, Andrey Nechypurenko wrote: If I understand correctly, the difference is that Bob proposes you to dedicate a hardware timer to the PWM, whereas I propose you to use the software timers, which ultimately, also depend on a dmtimer. I would not expect big differences between the two approaches, neither in terms of jitter, nor in terms of code. I see. Thanks for the explanations. As suggested in the previous mail I sent you, compare the differences in latencies with latency -t 2 between user-space task and kernel-space timer. You will see that a timer handler has much less jitter. It is clear for me that there is a difference. I am trying to understand what is the reason for the difference. I thought that as soon as Xenomai task is created (does not matter from user or kernel space) it is managed by Xenomai in the similar way and correspondingly the results should be also similar (which is obviously no the case). xenomai provides user-space threads and kernel-space threads, which work much like linux user-space and kernel-space threads. Switch to user-space, and context switch time explain the difference. So is it the only reason for the differences or there are some other factors influencing the results? It is the only reason. With latency -t 2. As soon as the timer interrupt happens, the timer handler, which runs in irq context, measures the jitter. With latency -t 0. When the timer interrupt happens, we need to switch to the kernel-space task associated with the user-space sampling task, ^^^ You meant stack, I guess. in the worst case, the currently running task was not in the same memory space, so, a switch of the mmu context is needed. Then we need to return to user-space, as a return to the rt_task_wait_period syscall at which point the jitter is measured. Add to this the opportunity for a real-time IRQ to preempt the task on its way back to userland, delaying the measurement from the time spent to run the ISR (at the very least). All this involves longer code paths and greater opportunities for cache effects. This difference between kernel-space and user-space explains why we advise people to split their application between application and driver, the really critical part using the RTDM skin, in kernel-space, much like you would do with linux. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
