> >>
> >> If you are calling into an "unknown" non-RT blob, dropping from RT
> >> may actually be required. We do not promote explicit mode switches
> >> because they are not needed if you control (wrap) all your code. This
> >> might be an exception.
> >
> > The non-RT "blob" is the regular
> -Original Message-
> From: Jan Kiszka
> Sent: Donnerstag, 20. Dezember 2018 14:33
> To: Lange Norbert ; Xenomai
> (xenomai@xenomai.org)
> Subject: Re: Cobalt Preemption of kernel update_fast_timekeeper can cause
> deadlocks
>
> E-MAIL FROM A NON-ANDRITZ SO
On 20.12.18 13:29, Lange Norbert via Xenomai wrote:
On 19.12.18 19:26, Auel, Kendall via Xenomai wrote:
Jan,
I'm very much in favor of providing a way to prevent Xenomai modules
from using features which can result in deadlock, if there is a clean way to
detect such a situation.
We used
> On 19.12.18 19:26, Auel, Kendall via Xenomai wrote:
> > Jan,
> >
> > I'm very much in favor of providing a way to prevent Xenomai modules
> from using features which can result in deadlock, if there is a clean way to
> detect such a situation.
> >
> > We used gettimeofday in one of our modules
On 19.12.18 19:26, Auel, Kendall via Xenomai wrote:
Jan,
I'm very much in favor of providing a way to prevent Xenomai modules from using
features which can result in deadlock, if there is a clean way to detect such a
situation.
We used gettimeofday in one of our modules and it mostly worked
; Lange Norbert
> ; Xenomai (xenomai@xenomai.org)
>
> Subject: Re: Cobalt Preemption of kernel update_fast_timekeeper can cause
> deadlocks
>
> On 19.12.18 13:09, Philippe Gerum via Xenomai wrote:
> > On 12/19/18 11:20 AM, Lange Norbert via Xenomai wrote:
> >> There is a
On 12/19/18 1:44 PM, Jan Kiszka wrote:
> On 19.12.18 13:09, Philippe Gerum via Xenomai wrote:
>> On 12/19/18 11:20 AM, Lange Norbert via Xenomai wrote:
>>> There is a deadlock issue that haunted me for several weeks,
>>> it is caused by the kernels update of the user-visible
>>> timekeeping
> -Original Message-
> From: Jan Kiszka
> Sent: Mittwoch, 19. Dezember 2018 13:45
> To: Philippe Gerum ; Lange Norbert
> ; Xenomai (xenomai@xenomai.org)
>
> Subject: Re: Cobalt Preemption of kernel update_fast_timekeeper can cause
> deadlocks
>
> E-
On 19.12.18 13:09, Philippe Gerum via Xenomai wrote:
On 12/19/18 11:20 AM, Lange Norbert via Xenomai wrote:
There is a deadlock issue that haunted me for several weeks,
it is caused by the kernels update of the user-visible
timekeeping structures used by the VDSO clock_gettime functions.
The
On 12/19/18 11:20 AM, Lange Norbert via Xenomai wrote:
> There is a deadlock issue that haunted me for several weeks,
> it is caused by the kernels update of the user-visible
> timekeeping structures used by the VDSO clock_gettime functions.
>
> The kernel regularly updates a Timestamp structure,
There is a deadlock issue that haunted me for several weeks,
it is caused by the kernels update of the user-visible
timekeeping structures used by the VDSO clock_gettime functions.
The kernel regularly updates a Timestamp structure, which is accessible in
user-mode,
it does so by something akin
11 matches
Mail list logo
