Steven Seeger wrote:
> Gilles believes he's on the track of our FPU issue when using kernel
> threads. Would using an RTDM timer to accomplish our need have the
> same issue? We would not use the FPU in the timer of course, because
> it is not allowed.
>
> I just don't want to spend the time
Hi,
the subject says it all. The patch is only compile-tested.
--
Sebastian
Index: ksrc/drivers/can/sja1000/rtcan_ixxat_pci.c
===
--- ksrc/drivers/can/sja1000/rtcan_ixxat_pci.c (Revision 4679)
+++ ksrc/drivers/can/sja1000/rtcan_ixx
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Meanwhile I played with some light-weight approach to relax a thread
>> that received a signal (according to do_sigwake_event). Worked, but on
Hi,
On Mon, 2009-03-09 at 18:02 +0100, Philippe Gerum wrote:
> Andreas Glatz wrote:
> > Hi,
> >
> > On Mon, 2009-03-09 at 17:08 +0100, Philippe Gerum wrote:
> >> Andreas Glatz wrote:
> >>> Hi,
> >>>
> >>> Calling rt_queue_create in a real-time task is supposed to fail
> >>> according to the docum
Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
Jan Kiszka wrote:
> Meanwhile I played with some light-weight approach to relax a thread
> that received a signal (according to do_sigwake_event). Worked, but only
> once due to a lim
Gilles believes he's on the track of our FPU issue when using kernel
threads. Would using an RTDM timer to accomplish our need have the
same issue? We would not use the FPU in the timer of course, because
it is not allowed.
I just don't want to spend the time converting things if it won't
Don't raise SIGXCPU while the process is being debugged. These mode
changes are expected, and reporting them doesn't provide any helpful
information to the application. Rather, it may raise error storms on the
application side.
Signed-off-by: Jan Kiszka
---
ksrc/nucleus/shadow.c |2 +-
1 fi
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
Don't raise SIGXCPU while the process is being debugged. These mode
changes are expected, and reporting them doesn't provide any helpful
information to the application. Rather, it may raise error
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Don't raise SIGXCPU while the process is being debugged. These mode
>>> changes are expected, and reporting them doesn't provide any helpful
>>> information to the application. Rather, it may raise error storms on the
>>> applicatio
Jan Kiszka wrote:
> Don't raise SIGXCPU while the process is being debugged. These mode
> changes are expected, and reporting them doesn't provide any helpful
> information to the application. Rather, it may raise error storms on the
> application side.
>
> Signed-off-by: Jan Kiszka
> ---
>
> k
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Don't raise SIGXCPU while the process is being debugged. These mode
>> changes are expected, and reporting them doesn't provide any helpful
>> information to the application. Rather, it may raise error storms on the
>> application side.
>>
>> Signed-off-
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Hi,
>>>
>>> the watchdog is currently broken in trunk ("zombie [...] would not
>>> die..."). In fact, it should al
Don't raise SIGXCPU while the process is being debugged. These mode
changes are expected, and reporting them doesn't provide any helpful
information to the application. Rather, it may raise error storms on the
application side.
Signed-off-by: Jan Kiszka
---
ksrc/nucleus/shadow.c |3 ++-
1 f
13 matches
Mail list logo