Re: rtnet i219 setup

It finally works! I meet several compile errors. After modifing codes, Finally works!: 1. netdev.c : "dma_error:" I deleted "dma_error:" in netdev.c. 2. rtdev.h : Providing-rtnetdev_alloc_rtskb_ip_align rtnetdev_alloc_rtskb_ip_align compile error occured. I found your patch https://www.xenoma

Re: 5.10-dovetail regression?

On 07.04.22 17:24, Philippe Gerum wrote: > > Jan Kiszka writes: > >> Hi Philippe, >> >> does this already ring some bell? >> >> https://source.denx.de/Xenomai/xenomai-images/-/jobs/419210 >> >> Only triggers with qemu-amd64, not on real HW and not with 5.15. >> > > I could not reproduce locally

Re: rtnet i219 setup

-- next part -- A non-text attachment was scrubbed... Name: Makefile Type: text/x-makefile Size: 277 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20220407/f3f7e504/attachment.bin>

Re: [PATCH 1/5] cobalt/events: add auto-clear feature

Jan Kiszka writes: > On 07.04.22 13:16, Philippe Gerum wrote: >> >> Jan Kiszka writes: >> >>> On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: From: Philippe Gerum The current implementation does not atomically consume+clear the event set to be received by the waiter

Re: [PATCH 1/5] cobalt/events: add auto-clear feature

On 07.04.22 13:16, Philippe Gerum wrote: > > Jan Kiszka writes: > >> On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: >>> From: Philippe Gerum >>> >>> The current implementation does not atomically consume+clear the event >>> set to be received by the waiter(s), which makes it useless for >

Re: 5.10-dovetail regression?

Jan Kiszka writes: > Hi Philippe, > > does this already ring some bell? > > https://source.denx.de/Xenomai/xenomai-images/-/jobs/419210 > > Only triggers with qemu-amd64, not on real HW and not with 5.15. > I could not reproduce locally, but visual inspection revealed something fishy in #8e2c0

Re: 5.10-dovetail regression?

Philippe Gerum writes: > a > Jan Kiszka writes: > >> Hi Philippe, >> >> does this already ring some bell? >> >> https://source.denx.de/Xenomai/xenomai-images/-/jobs/419210 >> >> Only triggers with qemu-amd64, not on real HW and not with 5.15. >> >> Jan > > 8e2c09ee5323 is most likely causing t

Re: 5.10-dovetail regression?

a Jan Kiszka writes: > Hi Philippe, > > does this already ring some bell? > > https://source.denx.de/Xenomai/xenomai-images/-/jobs/419210 > > Only triggers with qemu-amd64, not on real HW and not with 5.15. > > Jan 8e2c09ee5323 is most likely causing this. It's a backport of the fix developed fo

5.10-dovetail regression?

Hi Philippe, does this already ring some bell? https://source.denx.de/Xenomai/xenomai-images/-/jobs/419210 Only triggers with qemu-amd64, not on real HW and not with 5.15. Jan -- Siemens AG, Technology Competence Center Embedded Linux

Re: [PATCH 5/5] drivers: ipc: enable non-blocking write from regular threads

Jan Kiszka writes: > On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: >> From: Philippe Gerum >> >> Regular threads should be allowed to write to RTIPC sockets provided >> MSG_DONTWAIT is implicitly set for such a request. This would match >> the existing behavior with other synchronizati

Re: [PATCH 2/5] cobalt/events: add single-waiter delivery mode

Jan Kiszka writes: > On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: >> From: Philippe Gerum >> >> Allow for sending a set of event bits to the heading waiter only, >> instead of broadcasting them to all waiters. >> >> This change affects the ABI, since we add a set of operation flags t

Re: [PATCH 1/5] cobalt/events: add auto-clear feature

Jan Kiszka writes: > On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: >> From: Philippe Gerum >> >> The current implementation does not atomically consume+clear the event >> set to be received by the waiter(s), which makes it useless for >> anything but a plain one-time latch due to the r

Re: rtnet i219 setup

ards, Gino -- next part -- An embedded and charset-unspecified text was scrubbed... Name: error_raw.txt URL: <http://xenomai.org/pipermail/xenomai/attachments/20220407/927992b5/attachment.txt>

Re: rtnet i219 setup

are so you can already give them a try if you like. Best Regards, Gino -- next part -- An embedded and charset-unspecified text was scrubbed... Name: error_raw.txt URL: <http://xenomai.org/pipermail/xenomai/attachments/20220407/11aa8c30/attachment.txt>

Re: rtnet i219 setup

-- An embedded and charset-unspecified text was scrubbed... Name: error_raw.txt URL: <http://xenomai.org/pipermail/xenomai/attachments/20220407/52002a10/attachment.txt>

Re: [PATCH 5/5] drivers: ipc: enable non-blocking write from regular threads

On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: > From: Philippe Gerum > > Regular threads should be allowed to write to RTIPC sockets provided > MSG_DONTWAIT is implicitly set for such a request. This would match > the existing behavior with other synchronization objects, such as > semaphor

Re: [PATCH 2/5] cobalt/events: add single-waiter delivery mode

On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: > From: Philippe Gerum > > Allow for sending a set of event bits to the heading waiter only, > instead of broadcasting them to all waiters. > > This change affects the ABI, since we add a set of operation flags to > the cobalt_event_sync servi

Re: [PATCH 1/5] cobalt/events: add auto-clear feature

On 06.04.22 17:56, Philippe Gerum via Xenomai wrote: > From: Philippe Gerum > > The current implementation does not atomically consume+clear the event > set to be received by the waiter(s), which makes it useless for > anything but a plain one-time latch due to the race window this opens > with a

Re: [PATCH] Remove __work from PIPELINE_INBAND_WORK_INITIALIZER

On 06.04.22 23:06, Richard Weinberger via Xenomai wrote: > ipipe took a copy of the queued work, __work was used to determine how much > bytes had to get copied. > With dovetail no copy as taken and the __work parameter is no longer > useful, so we can get rid of it. > > Signed-off-by: Richard Wei

Re: pthread_cancel services not documented

On 07.04.22 10:20, Yunjie Gu via Xenomai wrote: > Hi All, > > I'm trying to use xenomai with posix interface, and I found some > differences in the documentation for xenomai 2 and xenomai 3. In xenomai > 2, pthread_cancel related services (including pthread_setcancelstate, .etc) > are clearly docu

pthread_cancel services not documented

Hi All, I'm trying to use xenomai with posix interface, and I found some differences in the documentation for xenomai 2 and xenomai 3. In xenomai 2, pthread_cancel related services (including pthread_setcancelstate, .etc) are clearly documented. In xenomai 3, however, only pthread_kill is document

Re: [PATCH] Remove __work from PIPELINE_INBAND_WORK_INITIALIZER

On Thu, Apr 7, 2022 at 10:03 AM Bezdeka, Florian via Xenomai wrote: > > Hi Richard, > > On Wed, 2022-04-06 at 23:06 +0200, Richard Weinberger via Xenomai > wrote: > > ipipe took a copy of the queued work, __work was used to determine how much > > bytes had to get copied. > > With dovetail no copy

Re: [PATCH] Remove __work from PIPELINE_INBAND_WORK_INITIALIZER

Hi Richard, On Wed, 2022-04-06 at 23:06 +0200, Richard Weinberger via Xenomai wrote: > ipipe took a copy of the queued work, __work was used to determine how much > bytes had to get copied. > With dovetail no copy as taken and the __work parameter is no longer ^^ is > usefu