I won't say the driver is improperly written, this ioctl call may not
be expected to be used in a low latency situation. Some code maybe
expected to be called at initialization time and then never again so
it doesn't impact RT operation. The rt_imx_uart driver is part of the
Xenomai code base, I'
So the fundamental issue here seems to be "how bad is bad enough" when
it
comes to these mode switches.
The write() call is wrapped with __RT(write)(...), so I assume it is
doing
an RTDM-based write request, and not a standard Linux write() syscall.
If
I remove that wrapper,
I'll try to answer part of this. The detection of a cross domain call
would come form the ipipe code in the kernel. This is being called
because the ipipe debug flags are on and it's detecting the switch
from the root domain and then causing a panic so we can see the stack
trace.
I'm not sure why
Greetings again,
Xenomai 3.0.6, armv7, imx6, imx_uart rtdm driver
I've seen many postings about this, and about symbol wrapping, etc,
etc. I'm still
not understanding something very basic here, I'm sure.
When I run a program built with --alchemy (no --posix) skin, and I
execute these lines
On 05/09/2018 12:27 PM, Edouard Tisserant wrote:
>
>>> [Xenomai] bad syscall <0xf0002>
>> #define __ARM_NR_BASE (__NR_SYSCALL_BASE+0x0f)
>> #define __ARM_NR_cacheflush (__ARM_NR_BASE+2)
>
> This special syscall is issued by Glibc in _dl_reloacate_object (see
> /elf/dl-reloc.c an
