ROSSIER Daniel wrote:
Dear Xenomai workers,
Would it be possible to have an updated API documentation for Xenomai
2.0.x ? (I mean with formal parameters in function prototypes)
I tried to regenerate it with make generate-doc, but it seems that a
SVN working dir is required.
It would be
Jan Kiszka wrote:
ROSSIER Daniel wrote:
Dear Xenomai workers,
Would it be possible to have an updated API documentation for Xenomai
2.0.x ? (I mean with formal parameters in function prototypes)
I tried to regenerate it with make generate-doc, but it seems that a
SVN
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the following if
the interrupt handler takes too long (i.e. next interrupt gets generated before
the previous one has finished)
[ 42.543765] [c00c2008] spin_bug+0xa8/0xc4
[ 42.597617] [c00c22d4] _raw_spin_lock+0x180/0x184
[
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jeroen Van den Keybus wrote:
Hello,
I'm currently not at a level to participate in your discussion. Although I'm
willing to supply you with stresstests, I would nevertheless like to learn
more from task migration as this debugging session
In the following code (ppc), shouldn't first be either declared static or
deleted? To me it looks like first is always equal to one when the else clause
is evaluated.
asmlinkage int __ipipe_grab_irq(struct pt_regs *regs)
{
extern int ppc_spurious_interrupts;
Philippe Gerum wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jeroen Van den Keybus wrote:
Hello,
I'm currently not at a level to participate in your discussion.
Although I'm
willing to supply you with stresstests, I would nevertheless like
to learn
more from task migration as
Philippe Gerum wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jeroen Van den Keybus wrote:
Hello,
I'm currently not at a level to participate in your discussion.
Although I'm
willing to supply you with stresstests, I would nevertheless like
to learn
more from task migration as
Anders Blomdell kirjoitti:
In the following code (ppc), shouldn't first be either declared static
or deleted? To me it looks like first is always equal to one when the
else clause is evaluated.
You're right. first doesn't need to be there at all, it's probably an
old copy of something in the
Philippe Gerum wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jeroen Van den Keybus wrote:
Hello,
I'm currently not at a level to participate in your
discussion. Although I'm
willing to supply you with stresstests, I would nevertheless like
to learn
Jan Kiszka wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765] [c00c2008] spin_bug+0xa8/0xc4
[ 42.597617]
Anders Blomdell wrote:
Jan Kiszka wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765] [c00c2008]
Jan Kiszka wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765]
Anders Blomdell wrote:
Philippe Gerum wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next
interrupt gets generated before the previous one has finished)
[ 42.543765] [c00c2008]
Jan Kiszka wrote:
Jan Kiszka wrote:
...
[Update] While writing this mail and letting your test run for a while,
I *did* get a hard lock-up. Hold on, digging deeper...
And here are its last words, spoken via serial console:
c31dfab0 0086 c30d1a90 c02a2500 c482a360 0001 0001
Jan Kiszka wrote:
Hi,
well, if I'm not totally wrong, we have a design problem in the
RT-thread hardening path. I dug into the crash Jeroen reported and I'm
quite sure that this is the reason.
So that's the bad news. The good one is that we can at least work around
it by switching off
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Therefore we need a dedicated function to re-enable interrupts in
the ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is
more obvious. On non-PPC archs it would translate to *_irq_enable.
I
Wolfgang Grandegger wrote:
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Therefore we need a dedicated function to re-enable interrupts in
the ISR. We could name it *_end_irq, but maybe
Jan Kiszka wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Therefore we need a dedicated function to re-enable interrupts in
the ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is
more obvious. On non-PPC archs it would translate to
Philippe Gerum wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Therefore we need a dedicated function to re-enable interrupts in
the ISR. We
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
well, if I'm not totally wrong, we have a design problem in the
RT-thread hardening path. I dug into the crash Jeroen reported and I'm
quite sure that this is the reason.
So that's the bad news. The good one is that we can at least work around
it
Dear Xenomai workers,
Would it be possible to have an updated API documentation for Xenomai 2.0.x ?
(I mean with formal parameters in function prototypes)
I tried to regenerate it with make generate-doc, but it seems that a SVN
working dir is required.
It would be great.
Thanks a lot
Daniel
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Philippe Gerum wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Therefore we need a dedicated function to re-enable
Jan Kiszka wrote:
Hi,
Gilles' work on cancellation for the posix skin reminded me of this
issue I once discovered in the native skin:
https://mail.gna.org/public/xenomai-core/2005-12/msg00014.html
I found out that this can easily be fixed by switching the pthread of a
native
...
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 tosolve it.
My fault. I meant the way preempt_schedule() and
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 to
solve it.
My fault. I meant the
ROSSIER Daniel wrote:
Dear Xenomai workers,
Would it be possible to have an updated API documentation for Xenomai
2.0.x ? (I mean with formal parameters in function prototypes)
I tried to regenerate it with make generate-doc, but it seems that a
SVN working dir is required.
It would be
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
ROSSIER Daniel wrote:
Dear Xenomai workers,
Would it be possible to have an updated API documentation for Xenomai
2.0.x ? (I mean with formal parameters in function prototypes)
I tried to regenerate it with make
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 to
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the following if
the interrupt handler takes too long (i.e. next interrupt gets generated before
the previous one has finished)
[ 42.543765] [c00c2008] spin_bug+0xa8/0xc4
[ 42.597617] [c00c22d4] _raw_spin_lock+0x180/0x184
[
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765] [c00c2008] spin_bug+0xa8/0xc4
[ 42.597617] [c00c22d4]
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jeroen Van den Keybus wrote:
Hello,
I'm currently not at a level to participate in your discussion. Although I'm
willing to supply you with stresstests, I would nevertheless like to learn
more from task migration as this debugging session
In the following code (ppc), shouldn't first be either declared static or
deleted? To me it looks like first is always equal to one when the else clause
is evaluated.
asmlinkage int __ipipe_grab_irq(struct pt_regs *regs)
{
extern int ppc_spurious_interrupts;
Philippe Gerum wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jeroen Van den Keybus wrote:
Hello,
I'm currently not at a level to participate in your discussion.
Although I'm
willing to supply you with stresstests, I would nevertheless like
to learn
more from task migration as
Heikki Lindholm wrote:
Anders Blomdell kirjoitti:
In the following code (ppc), shouldn't first be either declared static
or deleted? To me it looks like first is always equal to one when the
else clause is evaluated.
You're right. first doesn't need to be there at all, it's probably an
Philippe Gerum wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jeroen Van den Keybus wrote:
Hello,
I'm currently not at a level to participate in your
discussion. Although I'm
willing to supply you with stresstests, I would nevertheless like
to learn
Jan Kiszka wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765] [c00c2008] spin_bug+0xa8/0xc4
[ 42.597617]
Anders Blomdell wrote:
Jan Kiszka wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765] [c00c2008]
Jan Kiszka wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765]
Hi all,
as a reminder (userspace, native skin, shared heap) [1]:
API documentation: If the heap is shared, this value can be either zero, or
the same value given to rt_heap_create().
This is not true. As the heapsize gets altered in rt_heap_create for page size
alignment, the following call to
40 matches
Mail list logo
