make cast explicit to avoid warning when user code is compiled with
-Wconversion
---
include/copperplate/clockobj.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/copperplate/clockobj.h
b/include/copperplate/clockobj.h
index 8568794d9..063bcce90 100644
--- a/include/co
Hi all,
just testing new kernels with smokey, and one of them had RTnet on. This
triggered a bug with the net_packat_dgram test:
[ 50.610997] initializing loopback...
[ 50.613799] RTnet: registered rtlo
[ 50.692154] [ cut here ]
[ 50.693577] WARNING: CPU: 1 PID: 11
Without this patch compilation fails with
lib/cobalt/clock.c:251: error: conflicting types for '__wrap_clock_adjtime'
include/cobalt/time.h:43: error: previous declaration of '__wrap_clock_adjtime'
was here
lib/cobalt/clock.c:251: error: conflicting types for '__cobalt_clock_adjtime'
include/coba
Fix linking error when using glibc versions which do not provide
recvmmsg or sendmmsg.
Signed-off-by: Sebastian Smolorz
---
lib/cobalt/wrappers.c | 8
1 file changed, 8 insertions(+)
diff --git a/lib/cobalt/wrappers.c b/lib/cobalt/wrappers.c
index 20ad63a..951cd15 100644
--- a/lib/coba
The previous commit introduced a fix for old toolchains by including
sys/timex.h in include/cobalt/time.h. However, that breaks the
compilation of analogy_calibrate. Removing #include
from analogy_calibrate.c fixes compilation again.
Signed-off-by: Sebastian Smolorz
---
utils/analogy/analogy_ca
Sebastian Smolorz (3):
lib/cobalt: Do not call glibc's {recv|send}mmsg if it is too old
cobalt/time: add missing include for old toolchains
utils/analogy: fix compilation of analogy_calibrate with old
toolchains
include/cobalt/time.h | 1 +
lib/cobalt/wrappers.c
Hi all,
to clarify the current and planned maintenance situation for I-pipe on kernels
*prior* to 4.14, I'd like explain a couple of things and also ask for support.
4.4
---
As we (Siemens) have a couple of products with Xenomai on 4.4 now, we plan to
maintain the ipipe-4.4.y branch as LTS f
On 27.09.18 19:05, Jan Kiszka wrote:
The following changes since commit f4dfbe3f8ecff040c66cd13c49861bb4cb3a2009:
ipipe: fix preemption damage in hard_preempt_enable() (2018-03-26 19:30:20
+0200)
are available in the Git repository at:
https://gitlab.denx.de/Xenomai/ipipe-x86.git for-up
Hi to all,
I am running 32bit application on 64bit kernel i.e my driver compiled on
64bit.
In my driver I used rtdm_fd_is_compat(), to know user land request came
from 32-bit or 64bit app.
My doubt is what it will return if both the driver & app are different?
Regards,
Manikanta
Hi,
on 10/19/18 04:00 AM, Pham, Phong wrote:
> I do see a TCP packet sent out on the LAN when rt_dev_connect() is
> invoked; however, the packet itself is not valid. The SYN flag in
> the TCP protocol is not set when the first TCP packet was sent.
Strange. Wireshark shows me that a connection in
esc: wireshark_capture.png
URL:
<http://xenomai.org/pipermail/xenomai/attachments/20181030/3faf5119/attachment.png>
-- next part --
A non-text attachment was scrubbed...
Name: wireshark_capture.png
Type: image/png
Size: 135068 bytes
Desc: wireshark_capture.png
URL:
&
# Test result show below:
```
[ 59.778342] RTcfg: rtcfg_do_main_event() rtdev=1,
event=RTCFG_CMD_ADD, stateG
Waiting for all slaves...[ 59.868079] RTcfg: rtcfg_do_main_event()
rtdev=1, eG
[ 60.37] RTcfg: error -11 while sending stage 1 frame
```
We change the e1000_main.c line wit
12 matches
Mail list logo