Re: [Xenomai-core] MSI support in Xenomai
On 2011-03-21 13:48, krishna m wrote: Date: Thu, 17 Mar 2011 09:30:37 +0100 From: jan.kis...@siemens.com To: gilles.chanteperd...@xenomai.org; krishnamurth...@hotmail.com CC: xenomai-core@gna.org Subject: Re: MSI support in Xenomai On 2011-03-16 14:26, Gilles Chanteperdrix wrote: krishna m wrote: Hi All, I wanted to know if the latest Xenomai [Version xenomai-2.5.6] supports MSI interrupts. I am using the adeos Patch [version adeos-ipipe-2.6.37-x86-2.9-00] and corresponding Linux kernel [version: linux-2.6.37]. I have read in the Xenomai FAQ that MSI is not supported by the ipipe patch just wanted to know if the latest Xenomai and Ipipe supports MSI. No. Strictly spoken, but it works in practice. See http://thread.gmane.org/gmane.linux.real-time.xenomai.users/12135 Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux Hi Jan, Thanks for the reply. I got the following info from you post and i had few questions related to this post: - MSI[-X] usage for RTDM (ie. RT) drivers is basically fine as long as you avoid enabling/disabling from RT context (also used for quite a while here, no known issues under this restriction) my question is are you mentioninig here that i must not be doing pci_enable_msi() and pci_disable_msi() inside the RTDM driver ? if not then where should these calls be done ? pci_enable/disable_msi are initialization services that only need to be executed over Linux context - also in RTDM drivers. Right now i have ported my standerd linux driver for the PCIe card to RTDM drvier. This driver uses MSI. I am not enabeling or disabling MSI or IRQ any where in the driver while processing [i.e. in ISR or read/write]. I am enabeling MSI in the PCI Probe and disabeling it in the PCI remove functions. The problem i am facing is as soon as i get the First MSI interrupt the kernel oops and i get the following dump: |Mar 21 21:08:34 barch kernel: BUG: unable to handle kernel paging request at 7f45402d Mar 21 21:08:34 barch kernel: Oops: [#1] PREEMPT SMP | We would need the full backtrace to have at least a chance to help. [note: The normal linux driver works with out any problem]. Please let me know your thoughts. Also is there an example PCIe RTDM driver using MSI that i can refer to understand more about this topic ? Check RTnet's IGB driver. It works with MSI-X interrupts on x86. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] MSI support in Xenomai
Date: Tue, 22 Mar 2011 13:13:16 +0100 From: jan.kis...@siemens.com To: krishnamurth...@hotmail.com CC: gilles.chanteperd...@xenomai.org; xenomai-core@gna.org Subject: Re: MSI support in Xenomai On 2011-03-21 13:48, krishna m wrote: Date: Thu, 17 Mar 2011 09:30:37 +0100 From: jan.kis...@siemens.com To: gilles.chanteperd...@xenomai.org; krishnamurth...@hotmail.com CC: xenomai-core@gna.org Subject: Re: MSI support in Xenomai On 2011-03-16 14:26, Gilles Chanteperdrix wrote: krishna m wrote: Hi All, I wanted to know if the latest Xenomai [Version xenomai-2.5.6] supports MSI interrupts. I am using the adeos Patch [version adeos-ipipe-2.6.37-x86-2.9-00] and corresponding Linux kernel [version: linux-2.6.37]. I have read in the Xenomai FAQ that MSI is not supported by the ipipe patch just wanted to know if the latest Xenomai and Ipipe supports MSI. No. Strictly spoken, but it works in practice. See http://thread.gmane.org/gmane.linux.real-time.xenomai.users/12135 Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux Hi Jan, Thanks for the reply. I got the following info from you post and i had few questions related to this post: - MSI[-X] usage for RTDM (ie. RT) drivers is basically fine as long as you avoid enabling/disabling from RT context (also used for quite a while here, no known issues under this restriction) my question is are you mentioninig here that i must not be doing pci_enable_msi() and pci_disable_msi() inside the RTDM driver ? if not then where should these calls be done ? pci_enable/disable_msi are initialization services that only need to be executed over Linux context - also in RTDM drivers. Right now i have ported my standerd linux driver for the PCIe card to RTDM drvier. This driver uses MSI. I am not enabeling or disabling MSI or IRQ any where in the driver while processing [i.e. in ISR or read/write]. I am enabeling MSI in the PCI Probe and disabeling it in the PCI remove functions. The problem i am facing is as soon as i get the First MSI interrupt the kernel oops and i get the following dump: |Mar 21 21:08:34 barch kernel: BUG: unable to handle kernel paging request at 7f45402d Mar 21 21:08:34 barch kernel: Oops: [#1] PREEMPT SMP | We would need the full backtrace to have at least a chance to help. [note: The normal linux driver works with out any problem]. Please let me know your thoughts. Also is there an example PCIe RTDM driver using MSI that i can refer to understand more about this topic ? Check RTnet's IGB driver. It works with MSI-X interrupts on x86. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux Hi Jan, Thanks again for the reply. Here is the full backtrace: Mar 22 21:12:47 localhost kernel: test_dev: Probe for device function=0 Mar 22 21:12:47 localhost kernel: test_dev :15:00.0: found PCI INT A - IRQ 10 Mar 22 21:12:47 localhost kernel: pci_bar = 0xfe00 Mar 22 21:12:47 localhost kernel: Xenomai: RTDM: RT open handler is deprecated, driver requires update. Mar 22 21:12:47 localhost kernel: Xenomai: RTDM: RT close handler is deprecated, driver requires update. Mar 22 21:12:47 localhost kernel: test_dev: IRQ 16 successfully assigned to the device. Mar 22 21:12:47 localhost kernel: test_dev: Probe for device function=1 Mar 22 21:12:47 localhost kernel: test_dev: Successfully added test_dev Device Driver. Mar 22 21:13:58 localhost kernel: BUG: unable to handle kernel paging request at d84050c0 Mar 22 21:13:58 localhost kernel: IP: [c0468f84] __ipipe_set_irq_pending+0x36/0x49 Mar 22 21:13:58 localhost kernel: *pde = Mar 22 21:13:58 localhost kernel: Oops: 0002 [#1] PREEMPT SMP Mar 22 21:13:58 localhost kernel: last sysfs file: /sys/devices/pci:00/:00:1a.0/:1f:00.0/:20:05.0/:2d:00.0/class Mar 22 21:13:58 localhost kernel: Modules linked in: test_dev autofs4 hidp l2cap crc16 bluetooth sunrpc ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 snd soundcore sata_sil24 libata sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd [last unloaded: snd_page_alloc] Mar 22 21:13:58 localhost kernel: Mar 22 21:13:58 localhost kernel: Pid: 2414, comm: ptg Not tainted 2.6.37_xenomai-2.5.6 #2 To be filled by O.E.M./To be filled by O.E.M. Mar 22 21:13:58 localhost kernel: EIP: 0060:[c0468f84] EFLAGS: 00010207 CPU: 0 Mar 22 21:13:58 localhost kernel: EIP is at __ipipe_set_irq_pending+0x36/0x49 Mar 22 21:13:58 localhost kernel: EAX: 07ff EBX: ECX: d74050c0 EDX: c08bc6c0 Mar 22 21:13:58 localhost kernel: ESI: c08bc640 EDI: ffc0 EBP: c08bc644 ESP: d69a9f8c Mar 22 21:13:58 localhost kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Mar 22 21:13:58 localhost kernel: Process ptg (pid: 2414,
Re: [Xenomai-core] MSI support in Xenomai
On 2011-03-22 16:55, krishna m wrote: Date: Tue, 22 Mar 2011 13:13:16 +0100 From: jan.kis...@siemens.com To: krishnamurth...@hotmail.com CC: gilles.chanteperd...@xenomai.org; xenomai-core@gna.org Subject: Re: MSI support in Xenomai On 2011-03-21 13:48, krishna m wrote: Date: Thu, 17 Mar 2011 09:30:37 +0100 From: jan.kis...@siemens.com To: gilles.chanteperd...@xenomai.org; krishnamurth...@hotmail.com CC: xenomai-core@gna.org Subject: Re: MSI support in Xenomai On 2011-03-16 14:26, Gilles Chanteperdrix wrote: krishna m wrote: Hi All, I wanted to know if the latest Xenomai [Version xenomai-2.5.6] supports MSI interrupts. I am using the adeos Patch [version adeos-ipipe-2.6.37-x86-2.9-00] and corresponding Linux kernel [version: linux-2.6.37]. I have read in the Xenomai FAQ that MSI is not supported by the ipipe patch just wanted to know if the latest Xenomai and Ipipe supports MSI. No. Strictly spoken, but it works in practice. See http://thread.gmane.org/gmane.linux.real-time.xenomai.users/12135 Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux Hi Jan, Thanks for the reply. I got the following info from you post and i had few questions related to this post: - MSI[-X] usage for RTDM (ie. RT) drivers is basically fine as long as you avoid enabling/disabling from RT context (also used for quite a while here, no known issues under this restriction) my question is are you mentioninig here that i must not be doing pci_enable_msi() and pci_disable_msi() inside the RTDM driver ? if not then where should these calls be done ? pci_enable/disable_msi are initialization services that only need to be executed over Linux context - also in RTDM drivers. Right now i have ported my standerd linux driver for the PCIe card to RTDM drvier. This driver uses MSI. I am not enabeling or disabling MSI or IRQ any where in the driver while processing [i.e. in ISR or read/write]. I am enabeling MSI in the PCI Probe and disabeling it in the PCI remove functions. The problem i am facing is as soon as i get the First MSI interrupt the kernel oops and i get the following dump: |Mar 21 21:08:34 barch kernel: BUG: unable to handle kernel paging request at 7f45402d Mar 21 21:08:34 barch kernel: Oops: [#1] PREEMPT SMP | We would need the full backtrace to have at least a chance to help. [note: The normal linux driver works with out any problem]. Please let me know your thoughts. Also is there an example PCIe RTDM driver using MSI that i can refer to understand more about this topic ? Check RTnet's IGB driver. It works with MSI-X interrupts on x86. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux Hi Jan, Thanks again for the reply. Here is the full backtrace: Mar 22 21:12:47 localhost kernel: test_dev: Probe for device function=0 Mar 22 21:12:47 localhost kernel: test_dev :15:00.0: found PCI INT A - IRQ 10 Here you get IRQ 10... Mar 22 21:12:47 localhost kernel: pci_bar = 0xfe00 Mar 22 21:12:47 localhost kernel: Xenomai: RTDM: RT open handler is deprecated, driver requires update. Mar 22 21:12:47 localhost kernel: Xenomai: RTDM: RT close handler is deprecated, driver requires update. [ These messages also have a meaning, though unrelated to the crash. ] Mar 22 21:12:47 localhost kernel: test_dev: IRQ 16 successfully assigned to the device. ...but here IRQ 16 is assigned. Broken output or a real inconsistency? Also, where is the MSI? You should see log messages about MSI/MSI-X IRQ number assignment when properly enabling the support at PCI level. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] MSI support in Xenomai
Jan Kiszka wrote: On 2011-03-22 16:55, krishna m wrote: Mar 22 21:12:47 localhost kernel: test_dev: Probe for device function=0 Mar 22 21:12:47 localhost kernel: test_dev :15:00.0: found PCI INT A - IRQ 10 Here you get IRQ 10... Mar 22 21:12:47 localhost kernel: pci_bar = 0xfe00 Mar 22 21:12:47 localhost kernel: Xenomai: RTDM: RT open handler is deprecated, driver requires update. Mar 22 21:12:47 localhost kernel: Xenomai: RTDM: RT close handler is deprecated, driver requires update. [ These messages also have a meaning, though unrelated to the crash. ] Mar 22 21:12:47 localhost kernel: test_dev: IRQ 16 successfully assigned to the device. ...but here IRQ 16 is assigned. Broken output or a real inconsistency? Also, where is the MSI? You should see log messages about MSI/MSI-X IRQ number assignment when properly enabling the support at PCI level. Maybe pci_enable_msi was called after request_irq ? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] MSI support in Xenomai
Date: Tue, 22 Mar 2011 18:03:43 +0100
From: gilles.chanteperd...@xenomai.org
To: jan.kis...@siemens.com
CC: krishnamurth...@hotmail.com; xenomai-core@gna.org
Subject: Re: MSI support in Xenomai
Jan Kiszka wrote:
On 2011-03-22 16:55, krishna m wrote:
Mar 22 21:12:47 localhost kernel: test_dev: Probe for device function=0
Mar 22 21:12:47 localhost kernel: test_dev :15:00.0: found PCI INT A
- IRQ 10
Here you get IRQ 10...
Mar 22 21:12:47 localhost kernel: pci_bar = 0xfe00
Mar 22 21:12:47 localhost kernel: Xenomai: RTDM: RT open handler is
deprecated,
driver requires update.
Mar 22 21:12:47 localhost kernel: Xenomai: RTDM: RT close handler is
deprecated,
driver requires update.
[ These messages also have a meaning, though unrelated to the crash. ]
Mar 22 21:12:47 localhost kernel: test_dev: IRQ 16 successfully assigned
to the
device.
...but here IRQ 16 is assigned. Broken output or a real inconsistency?
Also, where is the MSI? You should see log messages about MSI/MSI-X IRQ
number assignment when properly enabling the support at PCI level.
Maybe pci_enable_msi was called after request_irq ?
--
Gilles.
Just check my code:
i do enable MSI (pci_enable_msi) before rtdm_irq_request pasted the code below
part of my PCI probe function in the device driver:
..
rtdm_dev = kmalloc(sizeof(struct rtdm_device), GFP_KERNEL);
if(!rtdm_dev) {
printk(KERN_WARNING RUBICON: kmalloc failed\n);
ret = -ENOMEM; //Insufficient storage space is available.
goto fail_pci;
}
//copy the structure to the new memory
memcpy(rtdm_dev, rubicon_rtdm_driver, sizeof(struct rtdm_device));
//create filename
snprintf(rtdm_dev-device_name,
RTDM_MAX_DEVNAME_LEN, rtser%d, 0 /*i*/);
rtdm_dev-device_id = 0; //i;
//define two other members of the rtdm_device structure
rtdm_dev-proc_name = rtdm_dev-device_name;
ret = rtdm_dev_register(rtdm_dev);
if(ret 0) {
printk(KERN_WARNINGRUBICON: cannot register device\n);
goto fail_pci;
}
g_rubicon_context.xen_device = rtdm_dev;
ret = pci_enable_msi(dev);
if(ret) {
printk(RUBICON: Enabling MSI failed wuth error code: 0x%x\n, ret);
goto fail_pci;
}
g_rubicon_context.irq = dev-irq; /* save the allocated IRQ */
g_rubicon_context.dev = dev; /* Save the PCI queue h/w device ctx */
dev_set_drvdata(dev,(void *) (g_rubicon_context));
/* request the irq for the device */
ret = rtdm_irq_request(g_rubicon_context.irq_handle,
g_rubicon_context.irq,
rubicon_irq_handler,
RTDM_IRQTYPE_SHARED,
rubicon,
(void *)g_rubicon_context);
From IRQ number perspective:
Mar 22 21:12:47 localhost kernel: test_dev :15:00.0: found PCI INT A - IRQ
10 is the print from the Kernel PCI Probe and
Mar 22 21:12:47 localhost kernel: test_dev: IRQ 16 successfully assigned
is my Print after enabling MSI and registering for irq.
I get the similar print with the Plain Linux kernel with the IRQ being assigned
MSI enabled is irq 20. [Below i have pasted the kernel log of plain linux
kernel]. I have tested the MSI interrupts and they work fine.
Mar 22 23:47:49 localhost kernel: test_dev: Probe for device function=0
Mar 22 23:47:49 localhost kernel: test_dev :15:00.0: found PCI INT A - IRQ
10
Mar 22 23:47:49 localhost kernel: pci_bar = 0xfe00
Mar 22 23:47:49 localhost kernel: test_dev: IRQ 20 successfully assigned to the
device.
Mar 22 23:47:49 localhost kernel: test_dev: Probe for device function=1
Mar 22 23:47:49 localhost kernel: test_dev: Successfully added test_dev Device
Driver.
thanks
-krishna
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Help:Is the latency test right?
Hi , I am using the xenomai to build the paltform and getting a latency test results. RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99) RTH|lat min|lat avg|lat max|-overrun|---msw|---lat best|--lat worst RTD| -2.407| -2.185| 0.033| 0| 0| -2.407| 0.033 RTD| -2.356| -2.179| 0.601| 0| 0| -2.407| 0.601 RTD| -2.355| -2.185| -0.165| 0| 0| -2.407| 0.601 RTD| -2.360| -2.183| 0.041| 0| 0| -2.407| 0.601 RTD| -2.379| -2.182| 0.080| 0| 0| -2.407| 0.601 RTD| -2.359| -1.665| 2.635| 0| 0| -2.407| 2.635 RTD| -2.428| -2.159| 1.516| 0| 0| -2.428| 2.635 RTD| -2.355| -2.181| 0.139| 0| 0| -2.428| 2.635 RTD| -2.363| -2.183| -0.172| 0| 0| -2.428| 2.635 RTD| -2.361| -2.180| -0.060| 0| 0| -2.428| 2.635 RTD| -2.349| -2.175| 0.108| 0| 0| -2.428| 2.635 RTD| -2.356| -2.179| -0.054| 0| 0| -2.428| 2.635 RTD| -2.353| -2.163| 0.012| 0| 0| -2.428| 2.635 RTD| -2.354| -2.164| 1.320| 0| 0| -2.428| 2.635 RTD| -2.386| -1.491| 3.189| 0| 0| -2.428| 3.189 RTD| -2.351| -2.003| 3.149| 0| 0| -2.428| 3.189 RTD| -2.407| -2.166| 1.455| 0| 0| -2.428| 3.189 RTD| -2.360| -2.146| 1.593| 0| 0| -2.428| 3.189 RTD| -2.426| -2.169| 0.992| 0| 0| -2.428| 3.189 RTD| -2.362| -2.179| 0.017| 0| 0| -2.428| 3.189 How can I read the meaning of those results ? and Are those results are correct??? what is the max size of a xenomai task stack size? Thansk for your information and help. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Help: What is this in xenomai? rtheap crash?
Hello , I am a new bird using the xemomai! I use my classmate program to run on the xenomai and I got the below information .It seems that the rtheap crash ?? How can I solve this problem the xenomai is 2.5.4 and the kernel is 2.6.34.5. thanks for your help. linux-xkps1:~/Desktop/linux # Bin/APP_LTE_DEMO config.txt Noise Generated *** glibc detected *** Bin/APP_LTE_DEMO: malloc(): memory corruption: 0x176fbba0 *** === Backtrace: = /lib64/libc.so.6(+0x75018)[0x7f6ae8eb6018] /lib64/libc.so.6(+0x77f7f)[0x7f6ae8eb8f7f] /lib64/libc.so.6(__libc_malloc+0x77)[0x7f6ae8ebb057] Bin/APP_LTE_DEMO[0x41f284] /usr/xenomai/lib/libnative.so.3(+0x728c)[0x7f6ae961328c] /lib64/libpthread.so.0(+0x75f0)[0x7f6ae981e5f0] /lib64/libc.so.6(clone+0x6d)[0x7f6ae8f1584d] === Memory map: 0040-0052f000 r-xp 08:05 8986626 /root/linux/Bin/APP_LTE_DEMO 0072e000-0072f000 r--p 0012e000 08:05 8986626 /root/linux/Bin/APP_LTE_DEMO 0072f000-00761000 rw-p 0012f000 08:05 8986626 /root/linux/Bin/APP_LTE_DEMO 00761000-15833000 rw-p 00:00 0 176d2000-1771c000 rw-p 00:00 0 [heap] 7f6ab400-7f6ab4021000 rw-p 00:00 0 7f6ab4021000-7f6ab800 ---p 00:00 0 7f6abb491000-7f6abb492000 ---p 00:00 0 7f6abb492000-7f6abf492000 rw-p 00:00 0 7f6abf492000-7f6abf854000 rw-s 00:0e 2199 /dev/rtheap 7f6abf854000-7f6abf855000 ---p 00:00 0 7f6abf855000-7f6ac3855000 rw-p 00:00 0 7f6ac3855000-7f6ac444c000 rw-s 00:0e 2199 /dev/rtheap 7f6ac444c000-7f6ac5043000 rw-s 00:0e 2199 /dev/rtheap 7f6ac5043000-7f6ac5c3a000 rw-s 00:0e 2199 /dev/rtheap 7f6ac5c3a000-7f6ac6831000 rw-s 00:0e 2199 /dev/rtheap 7f6ac6831000-7f6ac6bf3000 rw-s 00:0e 2199 /dev/rtheap 7f6ac6bf3000-7f6ac6fb5000 rw-s 00:0e 2199 /dev/rtheap 7f6ac6fb5000-7f6ac7377000 rw-s 00:0e 2199 /dev/rtheap 7f6ac7377000-7f6ac7378000 ---p 00:00 0 7f6ac7378000-7f6acb378000 rw-p 00:00 0 7f6acb378000-7f6acb379000 ---p 00:00 0 7f6acb379000-7f6acb479000 rw-p 00:00 0 7f6acb479000-7f6acb47a000 ---p 00:00 0 7f6acb47a000-7f6acb57a000 rw-p 00:00 0 7f6acb57a000-7f6acb57b000 ---p 00:00 0 7f6acb57b000-7f6acb67b000 rw-p 00:00 0 7f6acb67b000-7f6acb67c000 ---p 00:00 0 7f6acb67c000-7f6ae8c3d000 rw-p 00:00 0 7f6ae8c3d000-7f6ae8c3f000 r-xp 08:05 11599887 /lib64/libdl-2.11.1.so 7f6ae8c3f000-7f6ae8e3f000 ---p 2000 08:05 11599887 /lib64/libdl-2.11.1.so 7f6ae8e3f000-7f6ae8e4 r--p 2000 08:05 11599887 /lib64/libdl-2.11.1.so 7f6ae8e4-7f6ae8e41000 rw-p 3000 08:05 11599887 /lib64/libdl-2.11.1.so 7f6ae8e41000-7f6ae8f95000 r-xp 08:05 11599881 /lib64/libc-2.11.1.so 7f6ae8f95000-7f6ae9195000 ---p 00154000 08:05 11599881 /lib64/libc-2.11.1.so 7f6ae9195000-7f6ae9199000 r--p 00154000 08:05 11599881 /lib64/libc-2.11.1.so 7f6ae9199000-7f6ae919a000 rw-p 00158000 08:05 11599881 /lib64/libc-2.11.1.so 7f6ae919a000-7f6ae919f000 rw-p 00:00 0 7f6ae919f000-7f6ae91b5000 r-xp 08:05 11599986 /lib64/libgcc_s.so.1 7f6ae91b5000-7f6ae93b4000 ---p 00016000 08:05 11599986 /lib64/libgcc_s.so.1 7f6ae93b4000-7f6ae93b5000 r--p 00015000 08:05 11599986 /lib64/libgcc_s.so.1 7f6ae93b5000-7f6ae93b6000 rw-p 00016000 08:05 11599986 /lib64/libgcc_s.so.1 7f6ae93b6000-7f6ae940b000 r-xp 08:05 11599889 /lib64/libm-2.11.1.so 7f6ae940b000-7f6ae960a000 ---p 00055000 08:05 11599889 /lib64/libm-2.11.1.so 7f6ae960a000-7f6ae960b000 r--p 00054000 08:05 11599889 /lib64/libm-2.11.1.so 7f6ae960b000-7f6ae960c000 rw-p 00055000 08:05 11599889 /lib64/libm-2.11.1.so 7f6ae960c000-7f6ae9616000 r-xp 08:05 7799014 /usr/xenomai/lib/libnative.so.3.0.0 7f6ae9616000-7f6ae9815000 ---p a000 08:05 7799014 /usr/xenomai/lib/libnative.so.3.0.0 7f6ae9815000-7f6ae9816000 r--p 9000 08:05 7799014 /usr/xenomai/lib/libnative.so.3.0.0 7f6ae9816000-7f6ae9817000 rw-p a000 08:05 7799014 /usr/xenomai/lib/libnative.so.3.0.0 7f6ae9817000-7f6ae982e000 r-xp 08:05 11599907 /lib64/libpthread-2.11.1.so 7f6ae982e000-7f6ae9a2e000 ---p 00017000 08:05 11599907 /lib64/libpthread-2.11.1.so 7f6ae9a2e000-7f6ae9a2f000 r--p 00017000 08:05 11599907 /lib64/libpthread-2.11.1.so 7f6ae9a2f000-7f6ae9a3 rw-p 00018000 08:05 11599907 /lib64/libpthread-2.11.1.so 7f6ae9a3-7f6ae9a34000 rw-p 00:00 0 7f6ae9a34000-7f6ae9a37000 r-xp 08:05 7799009 /usr/xenomai/lib/libxenomai.so.0.0.0 7f6ae9a37000-7f6ae9c37000 ---p 3000 08:05 7799009 /usr/xenomai/lib/libxenomai.so.0.0.0 7f6ae9c37000-7f6ae9c38000 r--p 3000 08:05 7799009 /usr/xenomai/lib/libxenomai.so.0.0.0 7f6ae9c38000-7f6ae9c39000 rw-p 4000 08:05 7799009 /usr/xenomai/lib/libxenomai.so.0.0.0 7f6ae9c39000-7f6ae9d29000 r-xp 08:05 7854798 /usr/lib64/libstdc++.so.6.0.10 7f6ae9d29000-7f6ae9f28000 ---p 000f 08:05 7854798 /usr/lib64/libstdc++.so.6.0.10 7f6ae9f28000-7f6ae9f2f000 r--p 000ef000 08:05
