----- Den 4 jun 2019, på kl 9:45, Per Öberg p...@wolfram.com skrev:
> ----- 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.
Sorry, just remembered that the socket is created using SOCK_DGRAM, so I it is
a UDP socket already when I call this (I got the order of things wrong in my
head...)
I tried using a SOCK_STREAM socket, and for this case there was no kernel bug.
> 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
Per Öberg
