Hello Jan,
I appologize for the huge reply latency.
Yeah, that might explain while already trying to parse it manually
failed: What is xnintr_sync_stat_references? :)
yeah.. it was supposed to be xnintr_sync_stat_refs()
'prev = xnstat_get_current()' reference is also tracked as reference
Hi Dmitry,
Dmitry Adamushko wrote:
Hello Jan,
well, take it with 2 huge grains of salt.. it's even not compile-tested :-)
Yeah, that might explain while already trying to parse it manually
failed: What is xnintr_sync_stat_references? :)
I don't think I've got it really nicer than your
On 22/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ ... ]
Only compile-tested under various .configs. Any comment welcome.
@@ -76,7 +102,7 @@ static inline void xnintr_stat_counter_d
static void xnintr_irq_handler(unsigned irq, void *cookie)
{
xnsched_t *sched =
Jan Kiszka wrote:
Dmitry Adamushko wrote:
On 21/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ .. ]
surprise-surprise.. sure, one way or another it must be fixed. heh..
too many bugs (and I don't even want to say who's responsible) :-/
I wouldn't accept all the responsibility if I were you.
I
On 20/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ ... ]
xnintr_attach/detach()).. your approach does increase a worst case
length of the lock(intrlock) -- unlock(intrlock) section... but
that's unlikely to be critical.
I think, the patch I sent before addresses a reported earlier case
Dmitry Adamushko wrote:
On 20/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ ... ]
xnintr_attach/detach()).. your approach does increase a worst case
length of the lock(intrlock) -- unlock(intrlock) section... but
that's unlikely to be critical.
I think, the patch I sent before addresses
On 21/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ ... ]
Unfortunately, that whole thing make me meditate about the whole issue
again. And now I wonder why we make such a fuss about locking for shared
IRQs (where it should be correct with any of the new patches) while we
do not care about
Dmitry Adamushko wrote:
On 21/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ ... ]
Unfortunately, that whole thing make me meditate about the whole issue
again. And now I wonder why we make such a fuss about locking for shared
IRQs (where it should be correct with any of the new patches) while
On 21/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ .. ]
surprise-surprise.. sure, one way or another it must be fixed. heh..
too many bugs (and I don't even want to say who's responsible) :-/
I wouldn't accept all the responsibility if I were you.
I have no problems in this respect. I was
Dmitry Adamushko wrote:
On 21/06/07, Jan Kiszka [EMAIL PROTECTED] wrote:
[ .. ]
surprise-surprise.. sure, one way or another it must be fixed. heh..
too many bugs (and I don't even want to say who's responsible) :-/
I wouldn't accept all the responsibility if I were you.
I have no
On Thu, 2007-06-21 at 13:05 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
Well, and I wonder what this xnarch_memory_barrier() at each handler
entry is for. Seems to be there for ages, don't see why right now.
AFAICT, this probably dates back to Xenomai 1.x, when we used to have a
threaded
Philippe Gerum wrote:
On Thu, 2007-06-21 at 13:05 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
Well, and I wonder what this xnarch_memory_barrier() at each handler
entry is for. Seems to be there for ages, don't see why right now.
AFAICT, this probably dates back to Xenomai 1.x, when we used
Hello Jan,
Well, I hate nested locks when it comes to real-time, but in this case I
really found no simpler approach. There is the risk of deadlocks via
IRQ:xnintr_shirq::lock - handler - nklock vs.
Application:nklock - xnintr_attach/detach - xnintr_shirq::lock,
it's also
13 matches
Mail list logo
