On 04.06.19 09:45, Per Oberg wrote:
----- 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? ).
SO_REUSEADDR is not implemented in RTnet. You should get an error when trying to
apply that on an RT socket.
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 ]---
That is weird. I don't see yet where we can crash here. Let me see if I can
reproduce. Is it as simple as __RT(socket) followed by that setsockopt?
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
