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 refer
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 you
Hello Jan,
well, take it with 2 huge grains of salt.. it's even not compile-tested :-)
I don't think I've got it really nicer than your first patch.. the only
additional point is that
'prev = xnstat_get_current()' reference is also tracked as reference accounting
becomes
a part of the xnstat i
Dmitry Adamushko wrote:
> 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)
>> {
>>
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 = xnpod_cu
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 responsibilit
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, whe
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
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.
>
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 respe
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 pa
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 a
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
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 reporte
Dmitry Adamushko wrote:
> 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/de
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
16 matches
Mail list logo
