Re: [Xenomai-core] preemptive doesn't work

2012-04-04 Thread Gilles Chanteperdrix
On 03/07/2012 07:13 PM, Roberto Bielli wrote:
 Hi Gilles,
 
 this is the trace and the test.
 
 It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with 
 disable interrupts.
 
 
 Thanks a lot for your time.

Hi Roberto,

any news about this issue?

Regards.

-- 
Gilles.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] preemptive doesn't work

2012-04-04 Thread Roberto Bielli

Hi Gilles,

i have always this big problem but the timer and the avic are programmed 
correctly.

There is something else but i don't know what.
In this moment i'm doing another work but soon i want to debug that error.

Thanks for all

Il 04/04/2012 11:21, Gilles Chanteperdrix ha scritto:

On 03/07/2012 07:13 PM, Roberto Bielli wrote:

Hi Gilles,

this is the trace and the test.

It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with
disable interrupts.


Thanks a lot for your time.

Hi Roberto,

any news about this issue?

Regards.




--
++

Roberto Bielli
Sviluppo Software   
Axel S.r.l. 

Via Del Cannino, 3  
21020 Crosio Della Valle
Varese - Italy  

Telefono: +39 0332 949600   
Fax:  +39 0332 969315   

E-mail:   roberto.bie...@axelsw.it  
Web Site: www.axelsw.it

++

Si precisa che le informazioni contenute in questo messaggio sono riservate e 
ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di 
eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da 
Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo 
autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o 
cancellazione dei Vostri dati: i...@axelsw.it

This e-mail and any attachments is confidential and may contain privileged 
information
intended for the addressee(s) only. Dissemination, copying, printing or use by 
anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you. 

++


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] preemptive doesn't work

2012-04-04 Thread Gilles Chanteperdrix
On 04/04/2012 11:29 AM, Roberto Bielli wrote:
 Hi Gilles,
 
 i have always this big problem but the timer and the avic are programmed 
 correctly.
 There is something else but i don't know what.
 In this moment i'm doing another work but soon i want to debug that error.

It is undoubtly a timer ack/program issue. There is no other problem,
the trace is quite clear: the timer is programmed, should tick, but
does not.

I had a look at the imx code again for other reasons, what may be also
missing in __ipipe_mach_acktimer function is a read of the timer status
register. As in:

void __ipipe_mach_acktimer(void)
{
uint32_t tstat;

if (timer_is_v2())
tstat = __raw_readl(timer_base + V2_TSTAT);
else
tstat = __raw_readl(timer_base + MX1_2_TSTAT);

gpt_irq_acknowledge();
}

And put that piece of code in mxc_timer_interrupt in the #ifndef
CONFIG_IPIPE section.

You may also want to issue a register read after programming the
compare register. As in:


void __ipipe_mach_set_dec(unsigned long delay)
{
 if (delay  mxc_min_delay) {
 unsigned long tcmp;
 
 if (!timer_is_v2()) {
 tcmp = __raw_readl(timer_base + MX1_2_TCN) + delay;
 __raw_writel(tcmp, timer_base + MX1_2_TCMP);
 __raw_readl(timer_base + MX1_2_TCN);
 } else {
 tcmp = __raw_readl(timer_base + V2_TCN) + delay;
 __raw_writel(tcmp, timer_base + V2_TCMP);
 __raw_readl(timer_base + V2_TCN);
 }
 } else
 ipipe_trigger_irq(__ipipe_mach_timerint);
}

-- 
Gilles.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


[Xenomai-core] [PULL] rt-puts fix, mprotect testsuite

2012-04-04 Thread Jan Kiszka
The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433:

  Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200)

are available in the git repository at:
  git://git.xenomai.org/xenomai-jki.git for-upstream

Jan Kiszka (3):
  Append missing newline to rt_[f]puts output
  testsuite: Add rt-print buffer flushes to native error paths
  Add regression test for mprotect on pinned memory

 src/skins/common/rt_print.c|7 ++-
 src/testsuite/regression/native/check.h|2 +
 src/testsuite/regression/native/leaks.c|1 +
 src/testsuite/regression/posix/Makefile.am |2 +-
 src/testsuite/regression/posix/Makefile.in |   15 -
 src/testsuite/regression/posix/check.h |   10 +++
 src/testsuite/regression/posix/mprotect.c  |   97 
 7 files changed, 129 insertions(+), 5 deletions(-)
 create mode 100644 src/testsuite/regression/posix/mprotect.c

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] [PULL] rt-puts fix, mprotect testsuite

2012-04-04 Thread Gilles Chanteperdrix
On 04/04/2012 02:56 PM, Jan Kiszka wrote:
 The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433:
 
   Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200)
 
 are available in the git repository at:
   git://git.xenomai.org/xenomai-jki.git for-upstream
 
 Jan Kiszka (3):
   Append missing newline to rt_[f]puts output
   testsuite: Add rt-print buffer flushes to native error paths

As I said, I do not agree with calling rt_print_flush_buffers outside of
xenomai libs. If you want to avoid the issue you should use rt_printf only.

-- 
Gilles.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] [PULL] rt-puts fix, mprotect testsuite

2012-04-04 Thread Jan Kiszka
On 2012-04-04 15:02, Gilles Chanteperdrix wrote:
 On 04/04/2012 02:56 PM, Jan Kiszka wrote:
 The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433:

   Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200)

 are available in the git repository at:
   git://git.xenomai.org/xenomai-jki.git for-upstream

 Jan Kiszka (3):
   Append missing newline to rt_[f]puts output
   testsuite: Add rt-print buffer flushes to native error paths
 
 As I said, I do not agree with calling rt_print_flush_buffers outside of
 xenomai libs.

rt_print_flush_buffers is a Xenomai API function that we export for
quite a while now. The rt_* functions are about explicit control when
what is invoked, both in the native skin and in what used to be rtdk.
Also, you can't avoid this function when you interact with libraries
that are unwrapped.

That said, I can fix that minor issue in leaks differently if you insist.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] [PULL] rt-puts fix, mprotect testsuite

2012-04-04 Thread Gilles Chanteperdrix
On 04/04/2012 03:12 PM, Jan Kiszka wrote:
 On 2012-04-04 15:02, Gilles Chanteperdrix wrote:
 On 04/04/2012 02:56 PM, Jan Kiszka wrote:
 The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433:

   Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200)

 are available in the git repository at:
   git://git.xenomai.org/xenomai-jki.git for-upstream

 Jan Kiszka (3):
   Append missing newline to rt_[f]puts output
   testsuite: Add rt-print buffer flushes to native error paths

 As I said, I do not agree with calling rt_print_flush_buffers outside of
 xenomai libs.
 
 rt_print_flush_buffers is a Xenomai API function that we export for
 quite a while now. The rt_* functions are about explicit control when
 what is invoked, both in the native skin and in what used to be rtdk.
 Also, you can't avoid this function when you interact with libraries
 that are unwrapped.
 
 That said, I can fix that minor issue in leaks differently if you insist.

I added rt_print_flush_buffers for xenomai 2.6.0, in order to implement
systematic wrapping of printf by the posix skin, my intent was not to
really export it. From my point of view, having to call this flush
function all over the place reveals a problem in the application. If you
use always printf or always rt_printf, you do not need to call this
function.

-- 
Gilles.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] [PULL] rt-puts fix, mprotect testsuite

2012-04-04 Thread Jan Kiszka
On 2012-04-04 15:23, Gilles Chanteperdrix wrote:
 On 04/04/2012 03:12 PM, Jan Kiszka wrote:
 On 2012-04-04 15:02, Gilles Chanteperdrix wrote:
 On 04/04/2012 02:56 PM, Jan Kiszka wrote:
 The following changes since commit 
 0ef2410a2c9cf7102dead861241bd2d9957e4433:

   Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200)

 are available in the git repository at:
   git://git.xenomai.org/xenomai-jki.git for-upstream

 Jan Kiszka (3):
   Append missing newline to rt_[f]puts output
   testsuite: Add rt-print buffer flushes to native error paths

 As I said, I do not agree with calling rt_print_flush_buffers outside of
 xenomai libs.

 rt_print_flush_buffers is a Xenomai API function that we export for
 quite a while now. The rt_* functions are about explicit control when
 what is invoked, both in the native skin and in what used to be rtdk.
 Also, you can't avoid this function when you interact with libraries
 that are unwrapped.

 That said, I can fix that minor issue in leaks differently if you insist.
 
 I added rt_print_flush_buffers for xenomai 2.6.0, in order to implement
 systematic wrapping of printf by the posix skin, my intent was not to
 really export it. From my point of view, having to call this flush
 function all over the place reveals a problem in the application. If you
 use always printf or always rt_printf, you do not need to call this
 function.

Still, there are those use cases where you cannot replace the print
functions. So it remains useful.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core