On 12.06.20 17:47, Per Oberg via Xenomai wrote:
> ----- Den 12 jun 2020, på kl 17:33, Jan Kiszka jan.kis...@siemens.com skrev:
>
>> On 12.06.20 17:26, Per Oberg via Xenomai wrote:
>>> Hi list
>
>>> I get a massive amount of "swithching ... to secondary mode after exception
>>> #14
>>> in kernel-space ..." followed by a WARNING as shown below.
>
>>> Can someone enlighten me regarding the meaning of exception #14 ?
>
>>> Is the "WARNING: CPU: 0 ..." the cause or the symptom ? It has a macro at
>>> fd.c
>>> calling "XENO_WARN_ON(COBALT, fd->refs <= 0);
>
>
>> Likely related: The WARN_ON triggers a stack dump and that may trigger
>> fixable or ignorable faults. We may consider converting that
>> XENO_WARN_ON into XENO_WARN_ON_ONCE.
>
>> What is actually interesting is the warning itself. Reference counting
>> became imbalanced. How do you trigger that?
>
> Where do you see that? I can't figure out anything about what is going on
> from that warning...
>
Warning at .../rtdm/fd.c:299:
static void __put_fd(struct rtdm_fd *fd, spl_t s)
{
...
XENO_WARN_ON(COBALT, fd->refs <= 0);
So, the file descriptor is released although its internal reference
counter says it's not held. That is a bug in the kernel, likely leading
to use-after-release issues.
> Not sure what I am actually doing, but I'd be glad to debug it if I knew
> where to start.
>
> I'm working on compiling a network library for use in Xenomai. It uses a lot
> of extra stuff to get everything up and running,but in the end it will use
> UDP for the data exchange. So switching to secondary mode may be ok during
> the startup.
>
I suppose you are writing a userspace application that uses RT-TCP here.
That usage pattern up to the point you see the first warning would be
interesting, ideally as minimal testcase. Also the configuration of the
RTnet stack (compile-time and runtime).
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
