Philippe,
this bug was introduced with recent clock_event modifications:
--- ksrc/nucleus/timer.c(Revision 2766)
+++ ksrc/nucleus/timer.c(Arbeitskopie)
@@ -245,7 +245,7 @@ void xntimer_tick_aperiodic(void)
translates into precious microsecs on low-end
On Thu, 2007-07-19 at 09:22 +0200, Jan Kiszka wrote:
Philippe,
this bug was introduced with recent clock_event modifications:
--- ksrc/nucleus/timer.c (Revision 2766)
+++ ksrc/nucleus/timer.c (Arbeitskopie)
@@ -245,7 +245,7 @@ void xntimer_tick_aperiodic(void)
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue could be
that we hold that lock while calling into xnpod_renice_root [1], ie.
doing a potential context switch. Was this checked to be save?
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue could be
that we hold that lock while calling into xnpod_renice_root [1], ie.
doing a potential context switch. Was this checked to be save?
Philippe Gerum wrote:
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue could be
that we hold that lock while calling into xnpod_renice_root [1], ie.
doing a potential context switch. Was this checked to be
On Thu, 2007-07-19 at 17:35 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue could be
that we hold that lock while calling into xnpod_renice_root [1], ie.
Philippe Gerum wrote:
On Thu, 2007-07-19 at 17:35 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue could be
that we hold that lock while calling into
Philippe Gerum wrote:
Ok, the rpilock is local, the nesting level is bearable, let's focus on
putting this thingy straight.
Well, redesigning things may not necessarily improve the situation, but
reducing the amount of special RPI code might be worth a thought:
What is so special about RPI
On Thu, 2007-07-19 at 19:18 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 17:35 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue
Philippe Gerum wrote:
On Thu, 2007-07-19 at 19:18 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 17:35 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock,
Mathias,
Could you try applying the attached patch against v2.3.2, and run your
box using the failing configuration. This patch is a _preliminary_
attempt at fixing two major issues, it is not complete, and may not even
be fully correct since it does not address all the pending issues yet.
11 matches
Mail list logo