----- Den 3 jun 2019, på kl 17:33, Jan Kiszka jan.kis...@siemens.com skrev:
> On 03.06.19 11:10, Per Oberg via Xenomai wrote:
> > ----- Den 3 jun 2019, på kl 11:06, xenomai xenomai@xenomai.org skrev:
> >> Hi,
> >> My program opens a RTnet socket successfully but the program gets killed
> >> by a different issue that has nothing to do with this. However, the
> >> RTnet socket is still bound. If I try to start the program again i get
> >> the error "Address already in use". If it would be a normal unix socket
> >> I would simply call it with SO_REUSEADDR but this is not possible with
> >> RTnet from what I understand.
>> I tried this and failed miserably. That said, I'm also interested in the
>> answer
> > to this question.
> >> My question is why the socket is not unbound after the binding process
> >> is killed and if there is a way to reclaim this socket. By the way, it
> >> has to be this socket since the communication partner expects the server
> >> to listen on this exact port.
> >> Cheers,
> >> Johannes
> > Per Öberg
> Are we talking about UDP in both cases?
I use UDP, yes. But I had no problems with the UDP part.
The problem I had was regarding the use of setsockopt. Because I test the code
on a regular linux machine the lingering of the sockets after killing the
application can be annoying. From what you describe below, SO_REUSEADDR should
not be necessary for this case (did I get that correctly? ).
Because I use the posix skin, and because it was necessary in regular linux, i
started out using it in the common code base but I never managed to get it
working in RT so I removed it again.
I used something like:
> int reuseSetting = 1;
> setsockopt(datagramSocket, SOL_SOCKET, SO_REUSEADDR, &reuseSetting,
> sizeof(int);
Or even (because I use both rt and not rt sockets in the same code and I got
the feeling that the automatic handling of this didn't quite work out.)
> __cobalt_setsockopt(datagramSocket, SOL_SOCKET, SO_REUSEADDR, &reuseSetting,
> sizeof(int);
This gave me:
----------------------------------------------------------------------------------------------------------------------
70642.666691] [Xenomai] switching App Thread to secondary mode after exception
#14 in kernel-space at 0xffffffffa0281787 (pid 633)
[70642.667326] BUG: unable to handle kernel paging request at 00007fe06ff84d20
[70642.667948] IP: [<ffffffffa0281787>] rt_ip_ioctl+0x27/0x120 [rtipv4]
[70642.668566] PGD 80000002631e7067
[70642.668575] PUD 24a07d067
[70642.669184] PMD 260cab067
[70642.669189] PTE 800000023b6cc067
[70642.669805]
[70642.670403] Oops: 0001 [#5] PREEMPT SMP
[70642.670989] Modules linked in: rtudp rtipv4 intel_powerclamp intel_rapl
coretemp rt_igb e1000e i915 rtnet pcan(O) video fan thermal_sys
[70642.671629] CPU: 3 PID: 633 Comm: App Thread Tainted: G D W O
4.9.90-xeno-cobolt #1
[70642.672239] Hardware name: Default string Default string/SKYBAY, BIOS
5.0.1.1 04/18/2016
[70642.672854] I-pipe domain: Linux
[70642.673459] task: ffff880263231b00 task.stack: ffffc90001798000
[70642.674066] RIP: 0010:[<ffffffffa0281787>] [<ffffffffa0281787>]
rt_ip_ioctl+0x27/0x120 [rtipv4]
[70642.674683] RSP: 0018:ffffc9000179bda8 EFLAGS: 00010246
[70642.675300] RAX: 000000000007ffff RBX: 0000000040180021 RCX: ffff88026dd80000
[70642.675923] RDX: 00007fe06ff84d20 RSI: 0000000040180021 RDI: ffff880262a86800
[70642.676544] RBP: ffffc9000179bdd0 R08: 0000000000000050 R09: ffff880263231b00
[70642.677166] R10: 00000000000000e6 R11: 0000000000000000 R12: ffff880262a86800
[70642.677783] R13: 0000000040180021 R14: 00007fe06ff84d20 R15: 0000000062a86800
[70642.678394] FS: 00007fe06ff85700(0000) GS:ffff88026dd80000(0000)
knlGS:0000000000000000
[70642.679009] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[70642.679621] CR2: 00007fe06ff84d20 CR3: 0000000261678000 CR4: 0000000000360630
[70642.680233] Stack:
[70642.680838] ffffffffa028c6f7 0000000000000001 ffffffff81178cd0
ffff880262a86800
[70642.681464] 0000000000000003 ffffc9000179be60 ffffffff811725be
0000000000000202
[70642.682086] ffff880263231b00 ffff880200000010 ffffc9000179be70
ffffc9000179be08
[70642.682711] Call Trace:
[70642.683325] [<ffffffffa028c6f7>] ? rt_udp_ioctl+0x67/0x8c [rtudp]
[70642.683949] [<ffffffff81178cd0>] ? CoBaLt_fcntl+0x20/0x20
[70642.684573] [<ffffffff811725be>] rtdm_fd_ioctl+0xee/0x280
[70642.685199] [<ffffffff81178cd0>] ? CoBaLt_fcntl+0x20/0x20
[70642.685825] [<ffffffff81178cd0>] ? CoBaLt_fcntl+0x20/0x20
[70642.686445] [<ffffffff81178cde>] CoBaLt_ioctl+0xe/0x20
[70642.687064] [<ffffffff81188472>] ipipe_syscall_hook+0x112/0x350
[70642.687686] [<ffffffff8110acb8>] __ipipe_notify_syscall+0xc8/0x190
[70642.688306] [<ffffffff8110adaa>] ipipe_handle_syscall+0x2a/0xb0
[70642.688925] [<ffffffff81001c3d>] do_syscall_64+0x2d/0xf0
[70642.689514] [<ffffffff818dffbe>] entry_SYSCALL_64_after_swapgs+0x58/0xc6
[70642.690073] Code: 68 b8 eb b0 e8 ab 04 66 e1 81 fe 27 00 10 40 0f 84 c1 00
00 00 7e 73 81 fe 20 00 18 40 74 3c 81 fe 21 00 18 40 0f 85 a0 00 00 00 <8b> 02
8b 4a 10 4c 8b 42 08 8b 72 04 85 c0 0f 85 d6 00 00 00 83
[70642.691405] RIP [<ffffffffa0281787>] rt_ip_ioctl+0x27/0x120 [rtipv4]
[70642.692026] RSP <ffffc9000179bda8>
[70642.692642] CR2: 00007fe06ff84d20
[70642.693250] ---[ end trace 53b7ee62f61c9cca ]---
----------------------------------------------------------------------------------------------------------------------
> What should happen: When a process dies, its open rt fds gets closed. RTDM
> will
> call down to the driver to do the necessary work, in case of UDP to
> rt_udp_close
> which also removes the entries from the port registry and bitmap. You can
> confirm that by tracing that part - or send a simple test case that reproduces
> the issue.
> Jan
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
Per Öberg