).
Jan
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On 02/07/07, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote:
On 01/07/07, Jan Kiszka [EMAIL PROTECTED] wrote:
Hi all,
I've just uploaded my rebased patch stack, including specifically the
last bits that should go in before -rc1,
a few comments:
(1) in xnintr_irq_handler
. Otherwise, I'm fine with cleanups like this.
But I think there was once a reason for #define.
yeah.. now I recall it as well :-)
Thanks,
Jan
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org
(intr);
I guess, 'intr' can be NULL here.
Could you please send me attached (non-inlined) a combo patch on top
of the trunk version (as I see this one seems to be on top of your
previous one)? I'll try to come up with some solution during this
weekend.
--
Best regards,
Dmitry Adamushko
a case when intr == end and hence, the loop
would be finished anyway by the while (intr intr != end)
condition.. So sometimes it acts as yet _another_ check to exit the
loop, IOW while (intr intr != end) may be converted to just
while (intr).
Jan
--
Best regards,
Dmitry Adamushko
the non-shared, standard scenario.
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) :-/
Sigh, the never ending IRQ story...
should be reviewed.
Jan
--
Best regards,
Dmitry Adamushko
synchronize_irq() would not just wait on some simple
handler to exit...
Yeah.. we had already conversations on this topic (I think with
Philippe) and, if I recall right, that was one of the reasons. That's
why synchronize_irq() is in the nucleus layer.
Jan
--
Best regards,
Dmitry Adamushko
make code
shorter (and likely simpler), right? I don't see any problems it would
possibly cause (maybe I'm missing smth yet :)
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
, no. But that would
definitely have been a good idea.
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
and unlock for x86 seem to imply a
full memory barrier (and, probably, all the rest systems does the same).
Just look at definitions of mb() and spinlocks() for x86. asm(lock; some
write ops) does the trick in both cases.
Jan
--
Best regards,
Dmitry Adamushko
a background for such objections.
Well, if we conclude that the enhanced scheme provides better
informativeness and everyone benefiits from it, then let it be so. I
don't have any more objections [chores : uufff, haleluia!]
Jan-- Best regards,Dmitry Adamushko
the numbers while the
complex one makes the answer more complex trying to be fair in one
place and at the same time adding unfairness in another place.
--Philippe.-- Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https
On 15/09/06, Philippe Gerum [EMAIL PROTECTED] wrote:
On Fri, 2006-09-15 at 00:12 +0200, Dmitry Adamushko wrote:[...] And it's not a good idea to get ipipe_catch_event() buzy spinning as (as I understand) ipipe_dispatch_event() may take, in general, an
unbounded amount of time.Actually
() that
blocks a cleanup caller (which calls unregister_domain()) untill all
the readers are done with their activities.
Maybe it's wrong. Some more code reading would be required.
Jan-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core
- unlock
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
instructions does objdump -d kernel/ipipe/core.o
show for a given offset in the __ipipe_dispatch_event().
0xcd in case of Nils.
[c013f158] __ipipe_dispatch_event+0xcd/0xeb
?
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
XENO_OPT_SHIRQ_EDGE is on or (2) select XENO_OPT_SHIRQ_EDGE
automatically when the driver has been choosen.
Jan-- Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
declares that it's ready to work in shared mode but it doesn't mean it
can't work in non-shared one.
If a user has a separate line for it, then the shared-IRQ
infrastracture adds just non-used overhead. Yep, you are right (heh...
you are asking who had doubts? :)
Jan-- Best regards,Dmitry Adamushko
On 06/09/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote:
-menu Shared interrupts +menuconfig XENO_OPT_SHIRQ
+ bool Shared interrupts config XENO_OPT_SHIRQ_LEVEL bool Level-triggered interrupts - default n + depends on XENO_OPT_SHIRQ
+ default y help - + Enables support
with memory
or
[ write-back ] --- delay synching
?
It seems to be correct indeed. IOW, any write op. involves cache line
fetching (from L2 cache or main memory) if it's not in the L1.
--
Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai
in the soup (as it's said in my country).
But as I can see Philippe's corrections fix only compilation issues,
i.e. (2). (1) still remains unclear. Can't see any explanation so far,
if only xeno_16550A sees some of interrupts as its own and returns
HANDLED :)
Jan-- Best regards,
Dmitry Adamushko
the following transformation :
unlikely(a) unlikely(b) = unlikely(a + b)
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On 30/08/06, Dmitry Adamushko [EMAIL PROTECTED] wrote:
(cache line == 128 bits) let's say cacheline[4]
int a = 1; // e.g. a == 0xabcd0004
this part of memory is currently not in the cache. So :
1) [0xabcd, 0xabcd0010] == 128 bits is loaded from memory into cacheline.
Nop, it looks wrong
(xnintr_check_status: %d of unhandled consequent interrupts.
+
Disabling the IRQ line #%d\n,
+
XNINTR_MAX_UNHANDLED, irq);
+ s |= XN_ISR_NOENABLE;
+ }
I tend to think this would be nicer?
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core
-ENOATTACHMENT (also a common issue...)
now fixed.
Jan-- Best regards,Dmitry Adamushko
diff -upr xenomai-SVN/include/nucleus/intr.h xenomai/include/nucleus/intr.h
--- xenomai-SVN/include/nucleus/intr.h 2006-07-20 11:09:01.0 +0200
+++ xenomai/include/nucleus/intr.h 2006-08-29 21:20
On 22/08/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote:. diff -urp xenomai-SVN/include/nucleus/intr.h xenomai-a/include/nucleus/intr.h --- xenomai-SVN/include/nucleus/intr.h2006-07-20 11:09:01.0 +0200 +++ xenomai-a/include/nucleus/intr.h2006-08-22 09:32:
24.0
in
xnpipe_recv() as I don't like a check for timeout 1 to be placed
there. It's something that should be decided at the timer layer - I
mean, whether it's too late to sleep or not.
hope, I haven't overlooked anything this time :o)
-- Best regards,Dmitry Adamushko
--- pipe-SVN.c 2006-08-20 15:04
is rounded up to a page size.
rt_pipe_create()
{
...
if (poolsize 2 * PAGE_SIZE)
poolsize = 2 * PAGE_SIZE;
poolsize = xnheap_rounded_size(poolsize, PAGE_SIZE);
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https
WARRANTY... but indeed :) apply this patch so far if you really need synch. message passing mechanism.
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
or maybe I'm completely wrong and see the things which do not exist at all :)
p.s. I cc'ed xenomai-core as it may involve further discussions and it's the right place indeed.
-- Best regards,Dmitry Adamushko
diff -urp xenomai-a/include/nucleus/synch.h xenomai-b/include/nucleus/synch.h
--- xenomai
,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
. e.g. if ecx is wrong (points to non-existent vma).
It's also interesting that 2 tasks get GPF, both returning from some syscall.
Maybe Philippe who (I suppose) introduced sysenter/exit support for
Adeos/ipipe can shed some light.
--
Best regards,
Dmitry Adamushko
() call is amongst safe ones.
http://www.die.net/doc/linux/man/man2/signal.2.html
So write(1, ); heh... not that nice? :)
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
.
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
*) must be
cleared. Another logic could be applied for the rest, I guess.
p.s. I haven't read you patch yet so all said above is out of current context :)
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https
Hello,
this fix prevents possible deadlocks in rt_intr_delete() vs. ISR
handlers that I have mentioned earlier.
--
Best regards,
Dmitry Adamushko
native-intr.c-delete-rework.patch
Description: Binary data
posix-intr.c-delete-rework.patch
Description: Binary data
Changelog-delete
() - i.e. xnintr_disable (sync) can't be called
from a locked section as it's actually done in rt_intr_delete() (of
course, if we do really need the atomicy in the later one).
--
Philippe.
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
and safe without xnintr_shirq_spin() on detaching step and it becomes
somewhat blured with the enforcement like on SMP systems one should
always call xnintr_synchronize() right after calling xnintr_detach().
So I'm still thinking how to fix it better...
--
Best regards,
Dmitry Adamushko
hal.c
can be used instead.
this would solve one synch. problem in xnintr_* code, though there is
yet another and more complex one I'm banging my head on now :o)
--
Best regards,
Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https
that this is a _must_ now for any arch
to be compatible with adeos-ipipe.
If so, with some minor cleanups (XN_ISR_NOENABLE should be removed all
over the map,
docs fixes, ...) and testing the patch may hopefully find its way into
the codebase.
Any feedback?
TIA,
--
Best regards,
Dmitry Adamushko
Hello,
I overlooked that the logic of decrementing the interrupt nesting count has been changed recently and
both xnintr_shirq_handler() and xnintr_edge_shirq_handler() behave wrong in this respect.
The attached patch fixes this misbehavior.
-- Best regards,Dmitry Adamushko
intr.c.patch
to store the nesting counter becomes an
option, I guess.
Let's start from defining possible use cases with nested irq enable/disable calls then.
Maybe we just don't need them at all (at least the same way Linux deals with them)?
--
Philippe.
-- Best regards,Dmitry Adamushko
int xnintr_shirq_detach (xnintr_t *intr)
return err;
}
+static void xnintr_synchronize (xnintr_t *intr)
+{
+ xnintr_shirq_spin(xnshirqs[intr-irq]);
+}
+
int xnintr_mount(void)
{
int i;
---
-- Best regards,Dmi
| RTDM_IRQ_HANDLED;
+ret = RTDM_IRQ_HANDLED; } if (ctx-in_nwait 0) {
My fault, sorry. I should have fixed that but overlooked again.
Jan-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
.
Ok, some paranoid programmers would think differently even then
but there is always the (*) way :o)
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On 01/03/06, Philippe Gerum [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: On 01/03/06, *Philippe Gerum* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
The other option I've described for dealing with overruns in rt_task_wait_period would be as follows: - save the count of overruns - clear
On 28/02/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: ... Ok, are there any objections as to the current patch? If no, please apply.Oops, I found a minor problem:make[2]: Entering directory `/usr/src/xenomai/build/doc/doxygen'
doxygen/usr/src/xenomai/ksrc/skins/native/intr.c:523
is not yet clear at the moment. That's it...
Ok, are there any objections as to the current patch? If no, please apply.
CHANGELOG.patch is here https://mail.gna.org/public/xenomai-core/2006-02/msg00154.html
-- Best regards,Dmitry Adamushko
shirq-combo.patch
Description: Binary data
shirq
y
enable (e.g. enable_irq() - handler-enable() in bottom half)
Could it be such an arch feature? It looks to me that it's logically wrong anyway.
Heh... if one is still reading these lines, thanks for your time indeed! :o)
-- Best regards,Dmitry Adamushko
__
to lost interrupts on some archs.
Moreover, it avoids the need for ENABLE flag even in non-shared interrupt case.
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
to lost interrupts on some archs.
Moreover, it avoids the need for ENABLE flag even in non-shared interrupt case.
-- Best regards,Dmitry Adamushko
On 21/02/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: N.B. Amongst other things, some thoughts about CHAINED with shared interrupts. On 20/02/06, Anders Blomdell
[EMAIL PROTECTED] wrote: A number of questions arise: 1. What happens if one of the shared handlers leaves
On 21/02/06, Anders Blomdell [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: N.B. Amongst other things, some thoughts about CHAINED with shared interrupts. On 20/02/06, *Anders Blomdell*
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: A number of questions arise:
1. What happens if one
,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On 21/02/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: N.B. Amongst other things, some thoughts about CHAINED with shared interrupts. On 20/02/06, Anders Blomdell
[EMAIL PROTECTED] wrote: A number of questions arise: 1. What happens if one of the shared handlers leaves
On 21/02/06, Anders Blomdell [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: N.B. Amongst other things, some thoughts about CHAINED with shared interrupts. On 20/02/06, *Anders Blomdell*
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: A number of questions arise:
1. What happens if one
,Dmitry Adamushko
on this line, otherwise that may lead to the IRQ line
being .end-ed twice (lost interrupts in some cases).
#define UNHANDLED 0#define HANDLED_ENABLE 1#define HANDLED_NOENABLE 2#define PROPAGATE 3
Yep, I'd agree with you. Moreover, PROPAGATE should not be used for shared interrupts.
-- Best regards,Dmitry
consider HANDLED == 1 and NOINT == 0 as really scalar values
and
NOENABLE and PROPAGATE as additional bits (used only if needed).
-- Best regards,Dmitry Adamushko
On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: On 16/02/06, Jan Kiszka
[EMAIL PROTECTED] wrote: Hmm, I still find XN_ISR_NOINT in the patch. Shouldn't we solve this before merging (i.e. make
On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Hmm, I still find XN_ISR_NOINT in the patch. Shouldn't we solve this before merging (
i.e. make XN_ISR_HANDLED non-zero)? Ok, XN_ISR_NOINT is removed in favor of XN_ISR_HANDLED
On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: On 16/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: On 16/02/06, Jan Kiszka
[EMAIL PROTECTED] wrote: Hmm, I still find XN_ISR_NOINT in the patch. Shouldn't we solve this before merging (i.e. make
;
CONFIG_XENO_OPT_SHIRQ_EDGE - -//- for edge-triggered ones.
I addressed all the remarks and now, IMHO, it's (hopefully) ready for merge.
-- Best regards,Dmitry Adamushko
shirq-combo.patch
Description: Binary data
shirq-KConfig.patch
Description: Binary data
ChangeLog.patch
Description: Binary data
;
CONFIG_XENO_OPT_SHIRQ_EDGE - -//- for edge-triggered ones.
I addressed all the remarks and now, IMHO, it's (hopefully) ready for merge.
-- Best regards,Dmitry Adamushko
shirq-combo.patch
Description: Binary data
shirq-KConfig.patch
Description: Binary data
ChangeLog.patch
Description: Binary data
On 13/02/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: On 11/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: And as an additional option, it could be interesting to print out to the log if not all counter
values then min,max,average (the same like
it was signaled.
I guess, it's not true for devices that e.g. do not rise a new interrupt until
the ISR handler does some special acknowledgement device-wise.
am I right?
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
On 11/02/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: And as an additional option, it could be interesting to print out to the log if not all counter values then min,max,average (the same like for the latency :) per second or per
1000 interrupts; so to see whether tweaking
On 11/02/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: And as an additional option, it could be interesting to print out to the log if not all counter values then min,max,average (the same like for the latency :) per second or per
1000 interrupts; so to see whether tweaking
comments on the one with a given number of threads are wellcome too.
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
comments on the one with a given number of threads are wellcome too.
-- Best regards,Dmitry Adamushko
a close-to-zero-overhead should be made optional.
Ok, let's go for it upon getting the test results.
Enclosed a small optimization to reduce the code in (optional in future) ISR.
Jan
-- Best regards,Dmitry Adamushko
shirq-v9.patch
Description: Binary data
a close-to-zero-overhead should be made optional.
Ok, let's go for it upon getting the test results.
Enclosed a small optimization to reduce the code in (optional in future) ISR.
Jan
-- Best regards,Dmitry Adamushko
shirq-v9.patch
Description: Binary data
to be applied as follows :
- shirq-base
- shirq-v8
- shirq-proc
- shirq-edge
- shirq-ext
Happy testing ! :)
-- Best regards,Dmitry Adamushko
shirq-base.patch
Description: Binary data
shirq-v8.patch
Description: Binary data
shirq-proc.patch
Description: Binary data
shirq-edge.patch
Description
(~1 for UP and ~2 for SMP) KBs of data are not that critical taking
into account where and how they are used, both latency and cache-wise.
Wolfgang. -- Best regards, Dmitry Adamushko
On 02/02/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: Hi there, as I promised, here go the following patches (ordered as they have to be applied one by one) : 1) shirq-base.patch Adds the name field to the interrupt object of the nucleus layer.
Reworks the related bits
-triggered stuff.
This is a very preliminary version so the only thing I promise so far
is that it compiles successfully.
The functionality added by first 3 patches seem to be working.-- Best regards,Dmitry Adamushko
shirq-base.patch
Description: Binary data
shirq-v7.patch
Description: Binary
Hi,
the previous version contained an ugly bug, namely the misuse of the test_and_set/clear_bit interface
that led to a broken system from time to time.
-- Best regards,Dmitry Adamushko
shirq-v6.patch
Description: Binary data
On 31/01/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: Hi, the previous version contained an ugly bug, namely the misuse of the test_and_set/clear_bit interface that led to a broken system from time to time.
What about the ISA/edge-triggered stuff? :DMy problem is that we cannot
one else who has
written that nonsense :o) -- Best regards, Dmitry AdamushkoJan-- Best regards,Dmitry Adamushko
On 30/01/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: ... I have not checked it yet but my presupposition that something as easy as : preempt_disable() wake_up_interruptible_sync();
schedule(); preempt_enable(); It's a no-go: scheduling while atomic. One of my first attempts
On 23/01/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: Hello Jan, as I promised earlier today, here is the patch.I finally had a look at your patch (not yet a try), and it looks reallynice and light-weight.
I have another version here at hand. The only difference
and list iterations for non-shared IRQs. What do you
think? Worth it? Might be when the ISA/edge handling adds
further otherwise unneeded overhead.
Yep, maybe. But let's take something working first..
Jan
-- Best regards,Dmitry Adamushko
___
Xenomai
and list iterations for non-shared IRQs. What do you
think? Worth it? Might be when the ISA/edge handling adds
further otherwise unneeded overhead.
Yep, maybe. But let's take something working first..
Jan
-- Best regards,Dmitry Adamushko
Hello Jan,
as I promised earlier today, here is the patch.
hehe.. more comments later together with other explanations I promised.
I have to go now since I have to make a trip and my bus is leaving in
45 minutes :)
-- Best regards,Dmitry Adamushko
shirq-v4.patch
Description: Binary data
On 09/01/06, Gilles Chanteperdrix [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote:
Hi everybody,
I'm presenting it one last time as a draft, so it's a right time to give
all
the remarks concerning design/implementation issues for all interested
parties.
Any feedback
.. :)
Jan
--
Best regards,
Dmitry Adamushko
On 05/01/06, Philippe Gerum [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote: err... I have to orginize some issues next few days so I'll be out of my notebook. Then I'll finilize the ipipe-irq-related patch so to be ready for the .01 version.
Meanwhile, I have finished merging the shared IRQ
.
when there is no APC interface yet, mea culpa.
--Philippe.-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
.
when there is no APC interface yet, mea culpa.
--Philippe.-- Best regards,Dmitry Adamushko
gracefully I'd say.
Ok, it's enough for the New Year's Eve.
Happy New Year to everybody! I wish you all the best for the New Year :o)
-- Best regards,Dmitry Adamushko
nucleus_intr.c.patch
Description: Binary data
nucleus_intr.h.patch
Description: Binary data
gracefully I'd say.
Ok, it's enough for the New Year's Eve.
Happy New Year to everybody! I wish you all the best for the New Year :o)
-- Best regards,Dmitry Adamushko
nucleus_intr.c.patch
Description: Binary data
nucleus_intr.h.patch
Description: Binary data
that sum of all apcs in
/proc/xenomai/apc != virq from /proc/xenomai/irq, but ipipe_printk_virq
is not listed since it's registered without rthal::apc interface. Ok,
should take a look at it closer, i.e. maybe at least rthal_linux_irq
can be reworked now.
-- Best regards,Dmitry Adamushko
ipipe
that sum of all apcs in
/proc/xenomai/apc != virq from /proc/xenomai/irq, but ipipe_printk_virq
is not listed since it's registered without rthal::apc interface. Ok,
should take a look at it closer, i.e. maybe at least rthal_linux_irq
can be reworked now.
-- Best regards,Dmitry Adamushko
ipipe
shorter.
Some points are more likely to be changed in the next iteration (e.g.
__ipipe_irq_cookie() vs. changing the ipipe_virtualize_irq()
interface).
The struct rthal_realtime_irq::hits[per-IRQ] is missed so far.
Anyway, comments are very wellcome.
--
Best regards,
Dmitry Adamushko
diff -urp linux
shorter.
Some points are more likely to be changed in the next iteration (e.g.
__ipipe_irq_cookie() vs. changing the ipipe_virtualize_irq()
interface).
The struct rthal_realtime_irq::hits[per-IRQ] is missed so far.
Anyway, comments are very wellcome.
--
Best regards,
Dmitry Adamushko
diff -urp linux
[EMAIL PROTECTED] wrote on 22.11.2005 11:21:09:
Jan Kiszka wrote:
...
A patch says more than thousand words. ;)
As a first approach, I picked the second variant and implemented a new
function called rt_pipe_setpool. I also had to extend rt_pipe_alloc and
rt_pipe_free so that the
[EMAIL PROTECTED] wrote on 18.11.2005 09:57:15:
Exactly, I have just found out that and posted actually a long mail just
before getting this mail from you :o)
Yep, and before getting blocked, read() increments the counter as
well, that's
why we don't have a xnpipe_realease() called
Hi,
I failed to find the original message from Sebastian that led to the following change:
-
2005-11-09 Philippe Gerum [EMAIL PROTECTED]
* nucleus/pipe.c (xnpipe_disconnect): Flush the output queue
upon closure. Issue spotted by Sebastian Smolorz.
Philippe Gerum [EMAIL PROTECTED] wrote on 18.11.2005 11:14:26:
...
it looks like we can't make the whole xnpipe_release() atomic because of
PREEMPT_RT + wake_up_interruptible_all() things, right? Or no.
You must _never_ _ever_ reschedule with the nucleus lock held; this
is a major
1 - 100 of 124 matches
Mail list logo
