enableIRQ + _native_in_isr after long idle

[jnohlgard]

I left two native rpl_udp instances running over night since yesterday. One was configured as a root node, the other a regular routing node. Communication was working properly and the shell was responding to my commands. When I came back this morning both terminals were filled with thousands of lines of the text enableIRQ + _native_in_isr and the shell does not accept commands any more. It has not printed any more lines now since this morning when I tried typing some shell commands which were not executed.

Is this a known issue? Is it be related to some timer problem which doesn't occur until a certain uptime is reached?

I don't have time to investigate this right now but I wanted to create an issue before I forgot about it. Please close this issue if this is a duplicate.

[jnohlgard]

I attached gdb to get a backtrace:

(gdb) bt
#0  0xf77a8b40 in __kernel_vsyscall ()
#1  0xf764c283 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:81
#2  0x0804cd3d in native_isr_entry ()
#3  <signal handler called>
#4  0xf764c1fc in __read_nocancel () at ../sysdeps/unix/syscall-template.S:81
#5  0x0804cc02 in _native_popsig ()
#6  0x0804cc54 in native_irq_handler ()
#7  0xf75b022b in makecontext () at ../sysdeps/unix/sysv/linux/i386/makecontext.S:87
#8  0x00000000 in ?? ()

[jnohlgard]

unfortunately, I did not compile with debugging in mind so I don't have any line numbers..

[LudwigKnuepfer]

I think I never experienced this, thanks for the heads up.

[kushalsingh007]

I also experienced the same problem , I left the shell running for some time (~2 hrs) and then
enableIRQ + _native_in_isr message kept coming. In my case I left the examples/default running.

A screenshot [ though it is not very usefull ]

[miri64]

As far as I know #2071 fixes this (at least I did not encounter it at my usual problem zones when I merged that PR).

[miri64]

Making a longterm test to see if it is fixed now that #2071 is merged.

[miri64]

I had an instance idling for about 5h now and non of the described bugs occured, so I deam this issue fixed via #2071.