[Xenomai] There is XDDP Sockets support in kernel?

[Xenomai] There is XDDP Sockets support in kernel?

[Helder Daniel]

Hi,

When trying to compile a kernel module that sets up a XDDP socket (code
snippet below) with Xenomai 3.x-rc3 on Cobalt setup,
rtdm_bind() returns ENOSYS.
This means that XDDP sockets can not be used in kernel?

================================================
s = rtdm_socket(AF_RTIPC, SOCK_DGRAM, IPCPROTO_XDDP);
memset(&saddr, 0, sizeof(saddr));
saddr.sipc_family = AF_RTIPC;
saddr.sipc_port = XDDP_PORT;
ret = rtdm_bind(s, (struct sockaddr *)&saddr, sizeof(saddr));
if (ret) rtdm_printk("senderK: bind error: %d\n", ret);

================================================

Re: [Xenomai] There is XDDP Sockets support in kernel?

[Philippe Gerum]

On 03/30/2015 04:55 PM, Helder Daniel wrote:
> Hi,
> 
> When trying to compile a kernel module that sets up a XDDP socket (code
> snippet below) with Xenomai 3.x-rc3 on Cobalt setup,
> rtdm_bind() returns ENOSYS.
> This means that XDDP sockets can not be used in kernel?
> 

No, in this case it likely means that you are calling it from a
real-time context (i.e. a real-time kthread started with
rtdm_task_create()). The binding op can only run from a non-rt context,
e.g. module init code, regular kthread context, _nrt handler.

-- 
Philippe.

Re: [Xenomai] There is XDDP Sockets support in kernel?

[Philippe Gerum]

On 03/30/2015 05:13 PM, Philippe Gerum wrote:
> On 03/30/2015 04:55 PM, Helder Daniel wrote:
>> Hi,
>>
>> When trying to compile a kernel module that sets up a XDDP socket (code
>> snippet below) with Xenomai 3.x-rc3 on Cobalt setup,
>> rtdm_bind() returns ENOSYS.
>> This means that XDDP sockets can not be used in kernel?
>>
> 
> No, in this case it likely means that you are calling it from a
> real-time context (i.e. a real-time kthread started with
> rtdm_task_create()). The binding op can only run from a non-rt context,
> e.g. module init code, regular kthread context, _nrt handler.
> 

Please note that such restriction only applies to kernel-based callers.
When called from user-space via the bind() routine, Cobalt automatically
switches the caller to non-rt mode.

-- 
Philippe.

Re: [Xenomai] There is XDDP Sockets support in kernel?

[Gilles Chanteperdrix]

On Mon, Mar 30, 2015 at 05:13:44PM +0200, Philippe Gerum wrote:
> On 03/30/2015 04:55 PM, Helder Daniel wrote:
> > Hi,
> > 
> > When trying to compile a kernel module that sets up a XDDP socket (code
> > snippet below) with Xenomai 3.x-rc3 on Cobalt setup,
> > rtdm_bind() returns ENOSYS.
> > This means that XDDP sockets can not be used in kernel?
> > 
> 
> No, in this case it likely means that you are calling it from a
> real-time context (i.e. a real-time kthread started with
> rtdm_task_create()). The binding op can only run from a non-rt context,
> e.g. module init code, regular kthread context, _nrt handler.

Or that XDDP is not enabled in the kernel configuration, maybe?

-- 
					    Gilles.

Re: [Xenomai] There is XDDP Sockets support in kernel?

[Philippe Gerum]

On 03/30/2015 05:20 PM, Gilles Chanteperdrix wrote:
> On Mon, Mar 30, 2015 at 05:13:44PM +0200, Philippe Gerum wrote:
>> On 03/30/2015 04:55 PM, Helder Daniel wrote:
>>> Hi,
>>>
>>> When trying to compile a kernel module that sets up a XDDP socket (code
>>> snippet below) with Xenomai 3.x-rc3 on Cobalt setup,
>>> rtdm_bind() returns ENOSYS.
>>> This means that XDDP sockets can not be used in kernel?
>>>
>>
>> No, in this case it likely means that you are calling it from a
>> real-time context (i.e. a real-time kthread started with
>> rtdm_task_create()). The binding op can only run from a non-rt context,
>> e.g. module init code, regular kthread context, _nrt handler.
> 
> Or that XDDP is not enabled in the kernel configuration, maybe?
> 

It's an intra-kernel call, so it must be there.

-- 
Philippe.

Re: [Xenomai] There is XDDP Sockets support in kernel?

[Gilles Chanteperdrix]

On Mon, Mar 30, 2015 at 05:27:32PM +0200, Philippe Gerum wrote:
> On 03/30/2015 05:20 PM, Gilles Chanteperdrix wrote:
> > On Mon, Mar 30, 2015 at 05:13:44PM +0200, Philippe Gerum wrote:
> >> On 03/30/2015 04:55 PM, Helder Daniel wrote:
> >>> Hi,
> >>>
> >>> When trying to compile a kernel module that sets up a XDDP socket (code
> >>> snippet below) with Xenomai 3.x-rc3 on Cobalt setup,
> >>> rtdm_bind() returns ENOSYS.
> >>> This means that XDDP sockets can not be used in kernel?
> >>>
> >>
> >> No, in this case it likely means that you are calling it from a
> >> real-time context (i.e. a real-time kthread started with
> >> rtdm_task_create()). The binding op can only run from a non-rt context,
> >> e.g. module init code, regular kthread context, _nrt handler.
> > 
> > Or that XDDP is not enabled in the kernel configuration, maybe?
> > 
> 
> It's an intra-kernel call, so it must be there.

Not sure I follow. If RTDM is enabled in the kernel configuration,
and XDDP is not, then rtdm_bind will return -ENOSYS.

-- 
					    Gilles.

Re: [Xenomai] There is XDDP Sockets support in kernel?

[Helder Daniel]

Yes, it was called from a real-time kthread started with
rtdm_task_create()).
I am moving the socket initialization to the module initialization

PS: I am playing around with the xddp-echo example. I put the real time
thread in a module and the non real time Linux thread in user space.

On 30 March 2015 at 16:29, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On Mon, Mar 30, 2015 at 05:27:32PM +0200, Philippe Gerum wrote:
> > On 03/30/2015 05:20 PM, Gilles Chanteperdrix wrote:
> > > On Mon, Mar 30, 2015 at 05:13:44PM +0200, Philippe Gerum wrote:
> > >> On 03/30/2015 04:55 PM, Helder Daniel wrote:
> > >>> Hi,
> > >>>
> > >>> When trying to compile a kernel module that sets up a XDDP socket
> (code
> > >>> snippet below) with Xenomai 3.x-rc3 on Cobalt setup,
> > >>> rtdm_bind() returns ENOSYS.
> > >>> This means that XDDP sockets can not be used in kernel?
> > >>>
> > >>
> > >> No, in this case it likely means that you are calling it from a
> > >> real-time context (i.e. a real-time kthread started with
> > >> rtdm_task_create()). The binding op can only run from a non-rt
> context,
> > >> e.g. module init code, regular kthread context, _nrt handler.
> > >
> > > Or that XDDP is not enabled in the kernel configuration, maybe?
> > >
> >
> > It's an intra-kernel call, so it must be there.
>
> Not sure I follow. If RTDM is enabled in the kernel configuration,
> and XDDP is not, then rtdm_bind will return -ENOSYS.
>
> --
>                                             Gilles.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] There is XDDP Sockets support in kernel?

[Philippe Gerum]

On 03/30/2015 05:29 PM, Gilles Chanteperdrix wrote:
> On Mon, Mar 30, 2015 at 05:27:32PM +0200, Philippe Gerum wrote:
>> On 03/30/2015 05:20 PM, Gilles Chanteperdrix wrote:
>>> On Mon, Mar 30, 2015 at 05:13:44PM +0200, Philippe Gerum wrote:
>>>> On 03/30/2015 04:55 PM, Helder Daniel wrote:
>>>>> Hi,
>>>>>
>>>>> When trying to compile a kernel module that sets up a XDDP socket (code
>>>>> snippet below) with Xenomai 3.x-rc3 on Cobalt setup,
>>>>> rtdm_bind() returns ENOSYS.
>>>>> This means that XDDP sockets can not be used in kernel?
>>>>>
>>>>
>>>> No, in this case it likely means that you are calling it from a
>>>> real-time context (i.e. a real-time kthread started with
>>>> rtdm_task_create()). The binding op can only run from a non-rt context,
>>>> e.g. module init code, regular kthread context, _nrt handler.
>>>
>>> Or that XDDP is not enabled in the kernel configuration, maybe?
>>>
>>
>> It's an intra-kernel call, so it must be there.
> 
> Not sure I follow. If RTDM is enabled in the kernel configuration,
> and XDDP is not, then rtdm_bind will return -ENOSYS.
> 

It's a binding operation, so if the code did receive a valid XDDP
socket, the XDDP support must be there.

-- 
Philippe.

Re: [Xenomai] There is XDDP Sockets support in kernel?

[Helder Daniel]

I think it is.
xeno_rtipc was successfully loaded before inserting my module.



On 30 March 2015 at 16:37, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/30/2015 05:29 PM, Gilles Chanteperdrix wrote:
> > On Mon, Mar 30, 2015 at 05:27:32PM +0200, Philippe Gerum wrote:
> >> On 03/30/2015 05:20 PM, Gilles Chanteperdrix wrote:
> >>> On Mon, Mar 30, 2015 at 05:13:44PM +0200, Philippe Gerum wrote:
> >>>> On 03/30/2015 04:55 PM, Helder Daniel wrote:
> >>>>> Hi,
> >>>>>
> >>>>> When trying to compile a kernel module that sets up a XDDP socket
> (code
> >>>>> snippet below) with Xenomai 3.x-rc3 on Cobalt setup,
> >>>>> rtdm_bind() returns ENOSYS.
> >>>>> This means that XDDP sockets can not be used in kernel?
> >>>>>
> >>>>
> >>>> No, in this case it likely means that you are calling it from a
> >>>> real-time context (i.e. a real-time kthread started with
> >>>> rtdm_task_create()). The binding op can only run from a non-rt
> context,
> >>>> e.g. module init code, regular kthread context, _nrt handler.
> >>>
> >>> Or that XDDP is not enabled in the kernel configuration, maybe?
> >>>
> >>
> >> It's an intra-kernel call, so it must be there.
> >
> > Not sure I follow. If RTDM is enabled in the kernel configuration,
> > and XDDP is not, then rtdm_bind will return -ENOSYS.
> >
>
> It's a binding operation, so if the code did receive a valid XDDP
> socket, the XDDP support must be there.
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] There is XDDP Sockets support in kernel?

[Helder Daniel]

After moving rtdm_bind() to the module initialization the module loads, but
now something wrong happened to the kernel :). Probably I left the program
buggy when moving the xddp-echo example to kernel space. I will take a
deeper look.

Thanks

[  450.392941] senderK successfully loaded
[  450.643664] BUG: unable to handle kernel paging request at
000000004fcf4200
[  450.644714] IP: [<ffffffffa03950c8>] sender+0x26/0xc9 [senderK]
[  450.645497] PGD 0
[  450.645930] Oops: 0000 [#1] SMP
[  450.646600] Modules linked in: senderK(O) xeno_rtipc cfg80211 bnep nfsd
auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc fuse vmhgfs(O)
loop snd_ens1371 snd_ac97_codec coretemp snd_rawmidi snd_seq_device
microcode ac97_bus gameport ecb snd_pcm snd_timer snd psmouse soundcore
evdev serio_raw pcspkr btusb bluetooth rfkill vmwgfx ttm drm_kms_helper
ehci_pci drm shpchp rt_e1000 i2c_piix4 i2c_core rtnet vmci(O) ext4 crc16
jbd2 mbcache vmw_pvscsi vmxnet3 hid_generic usbhid hid sd_mod sg crc_t10dif
crct10dif_common sr_mod cdrom ata_generic uhci_hcd ehci_hcd usbcore e1000
usb_common mptspi scsi_transport_spi mptscsih mptbase ata_piix libata
scsi_mod
[  450.660900] CPU: 0 PID: 3840 Comm: XDDPsender Tainted: G           O
 3.16.0-ipipe #1
[  450.662123] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 05/20/2014
[  450.663030] task: ffff8800149cd2b0 ti: ffff88001f98c000 task.ti:
ffff88001f98c000
[  450.663743] RIP: 0010:[<ffffffffa03950c8>]  [<ffffffffa03950c8>]
sender+0x26/0xc9 [senderK]
[  450.664627] RSP: 0018:ffff88001f98fdf8  EFLAGS: 00010286
[  450.669222] RAX: 0000000015f2bbe8 RBX: ffffffffa03972c0 RCX:
ffffffffffffffff
[  450.669835] RDX: ffff880016000000 RSI: 0000000000000000 RDI:
0000000000000000
[  450.670409] RBP: ffff880015f2bbe8 R08: 0000000080000000 R09:
ffff8800160948f8
[  450.671019] R10: 00000000000004b9 R11: ffffffffa03972c0 R12:
0000000000000000
[  450.671630] R13: ffffffff810d2e44 R14: 0000000000000000 R15:
0000000000000000
[  450.672529] FS:  0000000000000000(0000) GS:ffff880016000000(0000)
knlGS:0000000000000000
[  450.673360] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  450.673897] CR2: 000000004fcf4200 CR3: 000000001ed28000 CR4:
00000000000407f0
[  450.674624] I-pipe domain Linux
[  450.675519] Stack:
[  450.675837]  0000000000000000 0000000000000003 0000000000000082
ffffffffa03972c0
[  450.677144]  0000000000000000 0000000000000000 ffff8800149cd2b0
ffffffff810d1fba
[  450.678336]  ffff8800160506a8 ffffffff810d2e17 0000000000000000
0000000000000018
[  450.680082] Call Trace:
[  450.680514]  [<ffffffff810d1fba>] ? xnthread_test_cancel+0x6/0x1f
[  450.681074]  [<ffffffff810d2e17>] ? xnthread_map+0x164/0x191
[  450.681691]  [<ffffffff810d0c90>] ? ipipe_set_ti_thread_flag+0xa/0xa
[  450.682308]  [<ffffffff810d2eec>] ? kthread_trampoline+0xa8/0xcc
[  450.682903]  [<ffffffff81053bea>] ? kthread+0x99/0xa1
[  450.683378]  [<ffffffff81053b51>] ? __kthread_parkme+0x59/0x59
[  450.683969]  [<ffffffff813663ed>] ? ret_from_fork+0x7d/0xb0
[  450.684518]  [<ffffffff81053b51>] ? __kthread_parkme+0x59/0x59
[  450.685061] Code: 48 83 c4 48 c3 55 53 48 81 ec 88 00 00 00 31 ff e8 12
cb d3 e0 85 c0 79 0b 89 c6 48 c7 c7 24 60 39 a0 eb 7c 48 63 c5 48 83 c9 ff
<4c> 8b 04 c5 c0 62 39 a0 31 c0 4c 89 c7 4c 89 c6 f2 ae 8b 3d a0
[  450.695959] RIP  [<ffffffffa03950c8>] sender+0x26/0xc9 [senderK]
[  450.696681]  RSP <ffff88001f98fdf8>
[  450.697063] CR2: 000000004fcf4200
[  450.697573] ---[ end trace 573e93c96f32000b ]---


On 30 March 2015 at 16:40, Helder Daniel <hdaniel@ualg.pt> wrote:

> I think it is.
> xeno_rtipc was successfully loaded before inserting my module.
>
>
>
> On 30 March 2015 at 16:37, Philippe Gerum <rpm@xenomai.org> wrote:
>
>> On 03/30/2015 05:29 PM, Gilles Chanteperdrix wrote:
>> > On Mon, Mar 30, 2015 at 05:27:32PM +0200, Philippe Gerum wrote:
>> >> On 03/30/2015 05:20 PM, Gilles Chanteperdrix wrote:
>> >>> On Mon, Mar 30, 2015 at 05:13:44PM +0200, Philippe Gerum wrote:
>> >>>> On 03/30/2015 04:55 PM, Helder Daniel wrote:
>> >>>>> Hi,
>> >>>>>
>> >>>>> When trying to compile a kernel module that sets up a XDDP socket
>> (code
>> >>>>> snippet below) with Xenomai 3.x-rc3 on Cobalt setup,
>> >>>>> rtdm_bind() returns ENOSYS.
>> >>>>> This means that XDDP sockets can not be used in kernel?
>> >>>>>
>> >>>>
>> >>>> No, in this case it likely means that you are calling it from a
>> >>>> real-time context (i.e. a real-time kthread started with
>> >>>> rtdm_task_create()). The binding op can only run from a non-rt
>> context,
>> >>>> e.g. module init code, regular kthread context, _nrt handler.
>> >>>
>> >>> Or that XDDP is not enabled in the kernel configuration, maybe?
>> >>>
>> >>
>> >> It's an intra-kernel call, so it must be there.
>> >
>> > Not sure I follow. If RTDM is enabled in the kernel configuration,
>> > and XDDP is not, then rtdm_bind will return -ENOSYS.
>> >
>>
>> It's a binding operation, so if the code did receive a valid XDDP
>> socket, the XDDP support must be there.
>>
>> --
>> Philippe.
>>
>
>
>
> --
> Helder Daniel
> UALG - FCT
> DEEI
>
> http://w3.ualg.pt/~hdaniel
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel

Re: [Xenomai] There is XDDP Sockets support in kernel?

[Philippe Gerum]

On 03/30/2015 05:55 PM, Helder Daniel wrote:
> After moving rtdm_bind() to the module initialization the module loads,
> but now something wrong happened to the kernel :). Probably I left the
> program buggy when moving the xddp-echo example to kernel space. I will
> take a deeper look. 
> 

You probably need to turn on CONFIG_FRAME_POINTER in order to get
meaningful backtraces.

-- 
Philippe.

Re: [Xenomai] There is XDDP Sockets support in kernel?

[Helder Daniel]

The problem was that when module unloads the periodic rtdm_task was killed
with: rtdm_task_destroy(); but the loop wasn't properly terminated.
Added rtdm_task_should_stop() before wait fior nest period to detect
termination and break loop, fixed it:

//rtdm_task
void echo(void *arg)
{

for (;;) {
if (rtdm_task_should_stop()) //break loop and end function
//when rtdm_task_destroy() is called
break;
 ret = rtdm_task_wait_period(); //deschedule until next period

//...
}
}





On 30 March 2015 at 20:00, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/30/2015 05:55 PM, Helder Daniel wrote:
> > After moving rtdm_bind() to the module initialization the module loads,
> > but now something wrong happened to the kernel :). Probably I left the
> > program buggy when moving the xddp-echo example to kernel space. I will
> > take a deeper look.
> >
>
> You probably need to turn on CONFIG_FRAME_POINTER in order to get
> meaningful backtraces.
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel