Re: [Adeos-main] at91sam9260

Re: [Adeos-main] at91sam9260

[Michael Trimarchi]

Hi,

> Ok. Could you try something ? It will work with I-pipe only but will
> break Xenomai, so do not try to run Xenomai over this modification.
> 

I tried the adeos-2.6.20-arm-1.8-02 patch and linux 2.6.20 and  I obtained the
same results. When the system is not loaded I can't receive from the serial
line using the adeos patch and null modem cable. 

AT91sam9260 8MB ram (using filesystem on ramdisk)
I removed spi flash support, mmc support.
I have only serial driver and using lrz for receiving file

Can I do some tests for you using my board? Do you have and updated patch 
for linux 2.6.23?

Regards 
Michael






      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

On Dec 20, 2007 7:44 PM, Michael Trimarchi <trimarchimichael@domain.hid> wrote:
> Hi,
>
> > Ok. Could you try something ? It will work with I-pipe only but will
> > break Xenomai, so do not try to run Xenomai over this modification.
> >
>
> I tried the adeos-2.6.20-arm-1.8-02 patch and linux 2.6.20 and  I obtained the
> same results. When the system is not loaded I can't receive from the serial
> line using the adeos patch and null modem cable.
>
> AT91sam9260 8MB ram (using filesystem on ramdisk)
> I removed spi flash support, mmc support.
> I have only serial driver and using lrz for receiving file
>
> Can I do some tests for you using my board?

Yes, just to be sure, could you try using the serial port on Linux
without I-pipe put under load ?


-- 
                                               Gilles Chanteperdrix

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

Michael Trimarchi wrote:
 > Hi,
 > 
 > > Ok. Could you try something ? It will work with I-pipe only but will
 > > break Xenomai, so do not try to run Xenomai over this modification.
 > > 
 > 
 > I tried the adeos-2.6.20-arm-1.8-02 patch and linux 2.6.20 and  I obtained the
 > same results. When the system is not loaded I can't receive from the serial
 > line using the adeos patch and null modem cable. 
 > 
 > AT91sam9260 8MB ram (using filesystem on ramdisk)
 > I removed spi flash support, mmc support.
 > I have only serial driver and using lrz for receiving file
 > 
 > Can I do some tests for you using my board? Do you have and updated patch 
 > for linux 2.6.23?

No, patch for Linux 2.6.23 is not there yet. Current I-pipe patch has
performance problems (probably a spurious interrupts masking section of
around 100us) which I would like to find first.

-- 


					    Gilles Chanteperdrix.

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

On Dec 20, 2007 7:44 PM, Michael Trimarchi <trimarchimichael@domain.hid> wrote:
> Hi,
>
> > Ok. Could you try something ? It will work with I-pipe only but will
> > break Xenomai, so do not try to run Xenomai over this modification.
> >
>
> I tried the adeos-2.6.20-arm-1.8-02 patch and linux 2.6.20 and  I obtained the
> same results. When the system is not loaded I can't receive from the serial
> line using the adeos patch and null modem cable.
>
> AT91sam9260 8MB ram (using filesystem on ramdisk)
> I removed spi flash support, mmc support.
> I have only serial driver and using lrz for receiving file
>
> Can I do some tests for you using my board?

in drivers/serial/atmel_serial.c, add the IRQF_DISABLED flag to request_irq.

When linux is running without adeos, the AT91 serial driver interrupt
is shared with the timer interrupt, so it automatically gets this
flag. Adeos does not use the same hardware timer as linux, so, when
adeos is enabled the serial interrupt is no longer shared with the
timer interrupt and it no longer gets this flag.

-- 
                                               Gilles Chanteperdrix

Re: [Adeos-main] at91sam9260

[Michael Trimarchi]

Hi
----- Messaggio originale -----
> Da: Gilles Chanteperdrix <gilles.chanteperdrix@domain.hid>
> A: Michael Trimarchi <trimarchimichael@domain.hid>
> Cc: adeos-main@gna.org> Inviato: Mercoledì 26 dicembre 2007, 6:59:31
> Oggetto: Re: [Adeos-main] at91sam9260
> 
> On Dec 20, 2007 7:44 PM, Michael Trimarchi wrote:
> > Hi,
> >
> > > Ok. Could you try something ? It will work with I-pipe only but will
> > > break Xenomai, so do not try to run Xenomai over this modification.
> > >
> >
> > I tried the adeos-2.6.20-arm-1.8-02 patch and linux 2.6.20 and I obtained the
> > same results. When the system is not loaded I can't receive from the serial
> > line using the adeos patch and null modem cable.
> >
> > AT91sam9260 8MB ram (using filesystem on ramdisk)
> > I removed spi flash support, mmc support.
> > I have only serial driver and using lrz for receiving file
> >
> > Can I do some tests for you using my board?
> 
> in drivers/serial/atmel_serial.c, add the IRQF_DISABLED flag to request_irq.
> 
> When linux is running without adeos, the AT91 serial driver interrupt
> is shared with the timer interrupt, so it automatically gets this
> flag. Adeos does not use the same hardware timer as linux, so, when
> adeos is enabled the serial interrupt is no longer shared with the
> timer interrupt and it no longer gets this flag.
> 
I will try.
 
Thank's


      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

Re: [Adeos-main] at91sam9260

[Bosko Radivojevic]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

Hi all!

Are there some conclusions or test reports regarding this discussion?

Thanx!

On Dec 26, 2007 12:10 PM, Michael Trimarchi <trimarchimichael@domain.hid>
wrote:

> Hi
> ----- Messaggio originale -----
> > Da: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> > A: Michael Trimarchi <trimarchimichael@domain.hid>
> > Cc: adeos-main@gna.org
> > Inviato: Mercoledì 26 dicembre 2007, 6:59:31
> > Oggetto: Re: [Adeos-main] at91sam9260
> >
> > On Dec 20, 2007 7:44 PM, Michael Trimarchi wrote:
> > > Hi,
> > >
> > > > Ok. Could you try something ? It will work with I-pipe only but will
> > > > break Xenomai, so do not try to run Xenomai over this modification.
> > > >
> > >
> > > I tried the adeos-2.6.20-arm-1.8-02 patch and linux 2.6.20 and I
> obtained the
> > > same results. When the system is not loaded I can't receive from the
> serial
> > > line using the adeos patch and null modem cable.
> > >
> > > AT91sam9260 8MB ram (using filesystem on ramdisk)
> > > I removed spi flash support, mmc support.
> > > I have only serial driver and using lrz for receiving file
> > >
> > > Can I do some tests for you using my board?
> >
> > in drivers/serial/atmel_serial.c, add the IRQF_DISABLED flag to
> request_irq.
> >
> > When linux is running without adeos, the AT91 serial driver interrupt
> > is shared with the timer interrupt, so it automatically gets this
> > flag. Adeos does not use the same hardware timer as linux, so, when
> > adeos is enabled the serial interrupt is no longer shared with the
> > timer interrupt and it no longer gets this flag.
> >
> I will try.
>
> Thank's
>
>
>      ___________________________________
> L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail:
> http://it.docs.yahoo.com/nowyoucan.html
>
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
>

[-- Attachment #2: Type: text/html, Size: 2847 bytes --]

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

Bosko Radivojevic wrote:
 > On Dec 26, 2007 12:10 PM, Michael Trimarchi <trimarchimichael@domain.hid>
 > wrote:
 > 
 > > Hi
 > > ----- Messaggio originale -----
 > > > Da: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
 > > > A: Michael Trimarchi <trimarchimichael@domain.hid>
 > > > Cc: adeos-main@gna.org
 > > > Inviato: Mercoledì 26 dicembre 2007, 6:59:31
 > > > Oggetto: Re: [Adeos-main] at91sam9260
 > > >
 > > > On Dec 20, 2007 7:44 PM, Michael Trimarchi wrote:
 > > > > Hi,
 > > > >
 > > > > > Ok. Could you try something ? It will work with I-pipe only but will
 > > > > > break Xenomai, so do not try to run Xenomai over this modification.
 > > > > >
 > > > >
 > > > > I tried the adeos-2.6.20-arm-1.8-02 patch and linux 2.6.20 and I
 > > obtained the
 > > > > same results. When the system is not loaded I can't receive from the
 > > serial
 > > > > line using the adeos patch and null modem cable.
 > > > >
 > > > > AT91sam9260 8MB ram (using filesystem on ramdisk)
 > > > > I removed spi flash support, mmc support.
 > > > > I have only serial driver and using lrz for receiving file
 > > > >
 > > > > Can I do some tests for you using my board?
 > > >
 > > > in drivers/serial/atmel_serial.c, add the IRQF_DISABLED flag to
 > > request_irq.
 > > >
 > > > When linux is running without adeos, the AT91 serial driver interrupt
 > > > is shared with the timer interrupt, so it automatically gets this
 > > > flag. Adeos does not use the same hardware timer as linux, so, when
 > > > adeos is enabled the serial interrupt is no longer shared with the
 > > > timer interrupt and it no longer gets this flag.
 > > >
 > > I will try.
 > >
 > Hi all!
 > 
 > Are there some conclusions or test reports regarding this discussion?
 > 
 > Thanx!

I received a mail from Michael recently telling me that he observes the
same behaviour with the PREEMPT_RT patch, so the I-pipe patch is
probably out of cause. He now suspects a hardware issue (one serial port
pin seems to be shared with another peripheral, as I think I understood).

-- 


					    Gilles Chanteperdrix.

Re: [Adeos-main] at91sam9260

[Bosko Radivojevic]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

Thanks. Actually, I have simillar problems (buffer overrun) when working
with serial port (at91sam9260-ek based board). But, I haven't inspected the
problem more than that. I'll do that next week.

On Feb 8, 2008 8:36 PM, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
wrote:

>
> I received a mail from Michael recently telling me that he observes the
> same behaviour with the PREEMPT_RT patch, so the I-pipe patch is
> probably out of cause. He now suspects a hardware issue (one serial port
> pin seems to be shared with another peripheral, as I think I understood).
>
>

[-- Attachment #2: Type: text/html, Size: 895 bytes --]

Re: [Adeos-main] at91sam9260

[Michael Trimarchi]

Hi,
> Thanks. Actually, I have simillar problems (buffer
> overrun) when working
> with serial port (at91sam9260-ek based board). But,
> I haven't inspected the
> problem more than that. I'll do that next week.
> 
> On Feb 8, 2008 8:36 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org>
> wrote:
> 
> >
> > I received a mail from Michael recently telling me
> that he observes the
> > same behaviour with the PREEMPT_RT patch, so the
> I-pipe patch is
> > probably out of cause. He now suspects a hardware
> issue (one serial port
> > pin seems to be shared with another peripheral, as
> I think I understood).
> >
> >
>
I finish my investigation, and I think that depens
only 
in some overhead. In linux is present using hrtimer
and doesn't depends on NO_HZ options. If some hrtimer
is executed with the interrupts disabled and the
serial
must receive a single char, you receive and overrun.
I suppose that the NO_HZ option can be a solution
(less interrupt) but an the end, doesn't change. The
dma
patch on serial device resolve the problem. I think
that for adeos is the same. I try to investigate, how
long is the max blocking time in hrtimer interrupt.

Using TC timer is ok. David and Gilles, you are right
but I want to know how in linux-rt and adeos, I can
reduce the latency to support this interrupts
frquency.

Regards Michael



      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

Michael Trimarchi wrote:
 > Hi,
 > > Thanks. Actually, I have simillar problems (buffer
 > > overrun) when working
 > > with serial port (at91sam9260-ek based board). But,
 > > I haven't inspected the
 > > problem more than that. I'll do that next week.
 > > 
 > > On Feb 8, 2008 8:36 PM, Gilles Chanteperdrix
 > > <gilles.chanteperdrix@xenomai.org>
 > > wrote:
 > > 
 > > >
 > > > I received a mail from Michael recently telling me
 > > that he observes the
 > > > same behaviour with the PREEMPT_RT patch, so the
 > > I-pipe patch is
 > > > probably out of cause. He now suspects a hardware
 > > issue (one serial port
 > > > pin seems to be shared with another peripheral, as
 > > I think I understood).
 > > >
 > > >
 > >
 > I finish my investigation, and I think that depens
 > only 
 > in some overhead. In linux is present using hrtimer
 > and doesn't depends on NO_HZ options. If some hrtimer
 > is executed with the interrupts disabled and the
 > serial
 > must receive a single char, you receive and overrun.
 > I suppose that the NO_HZ option can be a solution
 > (less interrupt) but an the end, doesn't change. The
 > dma
 > patch on serial device resolve the problem. I think
 > that for adeos is the same. I try to investigate, how
 > long is the max blocking time in hrtimer interrupt.
 > 
 > Using TC timer is ok. David and Gilles, you are right
 > but I want to know how in linux-rt and adeos, I can
 > reduce the latency to support this interrupts
 > frquency.

If I were you, if this serial driver was used only for debugging, I
would tolerate overruns. And if my application relied on the correct
working of a serial driver, I would use another driver, because you can
not base a system on a driver needing 10000 interrupts by second without
loss. This is not reasonable, especially on ARM. Or use a lower baud
rate.

-- 


					    Gilles Chanteperdrix.

Re: [Adeos-main] at91sam9260

[Michael Trimarchi]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]


Hi,
>Ok. Could you try something ? It will work with I-pipe only but will
>break Xenomai, so do not try to run Xenomai over this modification.

>In include/asm-arm/system.h in the definition of the switch_to macro
>try removing the calls to local_irq_disable_hw_cond and
>local_irq_enable_hw_cond, and tell us if you still get the serial
>driver overruns.
Ok,
now I can't because I have a flight in the afternoon. Maybe this night 
or tomorrow :)

>This means that there is a fault in xnpod_schedule, that causes a
>Linux function to be called over Xenomai domain. But the problem is
>the fault in the first place. To debug this, we need a disassembly of
>xnpod_schedule. This will be best discussed on Xenomai mailing list.
>You probably have a problem in your port of the I-pipe patch, since
>Xenomai is reported to works on other AT91s.
Ok

Regards MIchael






      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

[-- Attachment #2: Type: text/html, Size: 1578 bytes --]

Re: [Adeos-main] at91sam9260

[Michael Trimarchi]

[-- Attachment #1: Type: text/plain, Size: 3600 bytes --]


Hi,
>> >Wait a minute. You mean that you want more than 5000 interrupts by
>> >second ? Are you sure you do not get overruns with plain, unpatched
>> >Linux, if you load it sufficiently ?
>> If you do a simple count ( 115200 bps ) considering buffer length = 1
 the
>> answer is yes.
>>
>> :)
>>
>> regards Michael
>>
>> PS work with linux

>Do you observe this behaviour with I-pipe only or with Xenomai running
>? If we xenomai, could you try only booting Linux with I-pipe enabled
>?
>
>-- 
>                                               Gilles Chanteperdrix

I report this only using ipipe. I have some trouble with xenomai, that I will try to solve ( see below )


== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
I-pipe: Detected illicit call from domain 'Xenomai'
        into a service reserved for domain 'Linux' and below.
[<c0021988>] (show_stack+0x0/0x48) from [<c005cca0>] (ipipe_check_context+0x88/0xa4)
[<c005cc18>] (ipipe_check_context+0x0/0xa4) from [<c0057e40>] (search_module_extables+0x3c/0xe8)
 r5:00000000 r4:c0063cf0
[<c0057e04>] (search_module_extables+0x0/0xe8) from [<c004887c>] (search_exception_tables+0x30/0x3c)
 r8:00000154 r7:00000017 r6:00000000 r5:c0271e00 r4:c0063cf0
[<c004884c>] (search_exception_tables+0x0/0x3c) from [<c00231c0>] (fixup_exception+0x18/0x30)
 r4:c0271e00
[<c00231a8>] (fixup_exception+0x0/0x30) from [<c002339c>] (__do_kernel_fault+0x24/0x7c)
 r4:00000154
[<c0023378>] (__do_kernel_fault+0x0/0x7c) from [<c0023670>] (do_page_fault+0x27c/0x29c)
 r7:00000000 r6:c0266520 r5:c01a1e6c r4:ffffffff
[<c00233f4>] (do_page_fault+0x0/0x29c) from [<c001c2c8>] (do_DataAbort+0x3c/0x11c)
[<c001c28c>] (do_DataAbort+0x0/0x11c) from [<c001cb40>] (__dabt_svc+0x40/0x60)
Exception stack(0xc0271e00 to 0xc0271e48)
1e00: 204c0000 c0457860 40000093 40000093 c0457860 00000000 c01bf860 00000000 
1e20: c0280b30 c0270000 c01bf890 c0271e80 00000000 c0271e48 c0063ce4 c0063cf0 
1e40: 40000093 ffffffff                                                       
 r8:c0280b30 r7:00000000 r6:c01bf860 r5:c0271e34 r4:ffffffff
[<c00636ec>] (xnpod_schedule+0x0/0x7ac) from [<c00608f8>] (xnintr_clock_handler+0xa8/0x124)
[<c0060850>] (xnintr_clock_handler+0x0/0x124) from [<c005deb0>] (__ipipe_dispatch_wired+0xdc/0x104)
 r8:c0266520 r7:c01bf480 r6:c01a8120 r5:c01aa4e0 r4:c01bd140
[<c005ddd4>] (__ipipe_dispatch_wired+0x0/0x104) from [<c0021efc>] (__ipipe_handle_irq+0x94/0x1c8)
 r6:c0271f20 r5:00000011 r4:c01bd140
[<c0021e68>] (__ipipe_handle_irq+0x0/0x1c8) from [<c00220f4>] (__ipipe_grab_irq+0xc4/0x120)
[<c0022030>] (__ipipe_grab_irq+0x0/0x120) from [<c001cb90>] (__irq_svc+0x30/0x78)
 r8:c0266520 r7:c0457860 r6:00000011 r5:fefff000 r4:ffffffff
[<c014e0d4>] (schedule+0x0/0x814) from [<c006af54>] (gatekeeper_thread+0xfc/0x194)
[<c006ae58>] (gatekeeper_thread+0x0/0x194) from [<c004b1a4>] (kthread+0x58/0x90)
[<c004b14c>] (kthread+0x0/0x90) from [<c003780c>] (do_exit+0x0/0x94c)
 r6:00000000 r5:00000000 r4:00000000


There is a patch to using the serial device with DMA too and I use it with other board

 equipped with the at91rm9200. But my question is this:



spi prioriy < serial priority



In linux the interrupt nesting is controlled by the hardware logic. Is it true?



The priority is mainted using ipipe in at91sam9260? 





Regards Michael






      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

[-- Attachment #2: Type: text/html, Size: 4957 bytes --]

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

On Dec 17, 2007 3:20 PM, Michael Trimarchi <trimarchimichael@domain.hid> wrote:
>
>
>
> Hi,
> >> >Wait a minute. You mean that you want more than 5000 interrupts by
> >> >second ? Are you sure you do not get overruns with plain, unpatched
> >> >Linux, if you load it sufficiently ?
> >> If you do a simple count ( 115200 bps ) considering buffer length = 1 the
> >> answer is yes.
> >>
> >> :)
> >>
> >> regards Michael
> >>
> >> PS work with linux
>
> >Do you observe this behaviour with I-pipe only or with Xenomai running
> >? If we xenomai, could you try only booting Linux with I-pipe enabled
> >?
> >
> >--
> >                                              Gilles Chanteperdrix
>
> I report this only using ipipe. I have some trouble with xenomai, that I
> will try to solve ( see below )

Ok. Could you try something ? It will work with I-pipe only but will
break Xenomai, so do not try to run Xenomai over this modification.

In include/asm-arm/system.h in the definition of the switch_to macro
try removing the calls to local_irq_disable_hw_cond and
local_irq_enable_hw_cond, and tell us if you still get the serial
driver overruns.

> == Sampling period: 100 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> I-pipe: Detected illicit call from domain 'Xenomai'
>         into a service reserved for domain 'Linux' and below.
> [<c0021988>] (show_stack+0x0/0x48) from [<c005cca0>]
> (ipipe_check_context+0x88/0xa4)
> [<c005cc18>] (ipipe_check_context+0x0/0xa4) from [<c0057e40>]
> (search_module_extables+0x3c/0xe8)
>  r5:00000000 r4:c0063cf0
> [<c0057e04>] (search_module_extables+0x0/0xe8) from [<c004887c>]
> (search_exception_tables+0x30/0x3c)
>  r8:00000154 r7:00000017 r6:00000000 r5:c0271e00 r4:c0063cf0
> [<c004884c>] (search_exception_tables+0x0/0x3c) from [<c00231c0>]
> (fixup_exception+0x18/0x30)
>  r4:c0271e00
> [<c00231a8>] (fixup_exception+0x0/0x30) from [<c002339c>]
> (__do_kernel_fault+0x24/0x7c)
>  r4:00000154
> [<c0023378>] (__do_kernel_fault+0x0/0x7c) from [<c0023670>]
> (do_page_fault+0x27c/0x29c)
>  r7:00000000 r6:c0266520 r5:c01a1e6c r4:ffffffff
> [<c00233f4>] (do_page_fault+0x0/0x29c) from [<c001c2c8>]
> (do_DataAbort+0x3c/0x11c)
> [<c001c28c>] (do_DataAbort+0x0/0x11c) from [<c001cb40>]
> (__dabt_svc+0x40/0x60)
> Exception stack(0xc0271e00 to 0xc0271e48)
> 1e00: 204c0000 c0457860 40000093 40000093 c0457860 00000000 c01bf860
> 00000000
> 1e20: c0280b30 c0270000 c01bf890 c0271e80 00000000 c0271e48 c0063ce4
> c0063cf0
> 1e40: 40000093 ffffffff
>  r8:c0280b30 r7:00000000 r6:c01bf860 r5:c0271e34 r4:ffffffff
> [<c00636ec>] (xnpod_schedule+0x0/0x7ac) from [<c00608f8>]
> (xnintr_clock_handler+0xa8/0x124)
> [<c0060850>] (xnintr_clock_handler+0x0/0x124) from [<c005deb0>]
> (__ipipe_dispatch_wired+0xdc/0x104)
>  r8:c0266520 r7:c01bf480 r6:c01a8120 r5:c01aa4e0 r4:c01bd140
> [<c005ddd4>] (__ipipe_dispatch_wired+0x0/0x104) from [<c0021efc>]
> (__ipipe_handle_irq+0x94/0x1c8)
>  r6:c0271f20 r5:00000011 r4:c01bd140
> [<c0021e68>] (__ipipe_handle_irq+0x0/0x1c8) from [<c00220f4>]
> (__ipipe_grab_irq+0xc4/0x120)
> [<c0022030>] (__ipipe_grab_irq+0x0/0x120) from [<c001cb90>]
> (__irq_svc+0x30/0x78)
>  r8:c0266520 r7:c0457860 r6:00000011 r5:fefff000 r4:ffffffff
> [<c014e0d4>] (schedule+0x0/0x814) from [<c006af54>]
> (gatekeeper_thread+0xfc/0x194)
> [<c006ae58>] (gatekeeper_thread+0x0/0x194) from [<c004b1a4>]
> (kthread+0x58/0x90)
> [<c004b14c>] (kthread+0x0/0x90) from [<c003780c>] (do_exit+0x0/0x94c)
>  r6:00000000 r5:00000000 r4:00000000

This means that there is a fault in xnpod_schedule, that causes a
Linux function to be called over Xenomai domain. But the problem is
the fault in the first place. To debug this, we need a disassembly of
xnpod_schedule. This will be best discussed on Xenomai mailing list.
You probably have a problem in your port of the I-pipe patch, since
Xenomai is reported to works on other AT91s.

>
>
> There is a patch to using the serial device with DMA too and I use it with
> other board
>   equipped with the at91rm9200. But my question is this:
>
>  spi prioriy < serial priority
>
>  In linux the interrupt nesting is controlled by the hardware logic. Is it
> true?
>
>  The priority is mainted using ipipe in at91sam9260?

This is a difficult subject, will give a detailed explanation later.
The I-pipe evolved between the 1.7-08 and 1.8-02 versions, and Linux
is going to evolve in the same way. But the short answer is that
interrupt controller priority should matter only when receiving
several interrupts at the same time, which means not often, if it
matters it is because there is a bug in the interrupt handling, the
bug that was fixed in I-pipe version 1.8 and which is going to be
fixed in Linux soon.
http://marc.info/?l=linux-arm-kernel&m=119776017521950&w=2
-- 
                                               Gilles Chanteperdrix

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

Michael Trimarchi wrote:
 > In linux the interrupt nesting is controlled by the hardware logic. Is it true?
 > 
 > 
 > 
 > The priority is mainted using ipipe in at91sam9260? 

On AT91 the interrupt controller works as follows: when an interrupt
occurs, the processor irq line is asserted, until the processor reads
the AIC_IVR register. At that point, and until the processor writes to
the AIC_EOICR register, interrupts of lower priority are masked, and
only interrupts of higher priority could cause the processor irq line to
be reasserted.

In linux implementation (as of today), the write to the AIC_EOICR
register occurs at the end of the asm_do_IRQ function, after the
interrupt handler is invoked. So, this means that during all the work
done by an interrupt handler, lower priority interrupts are masked, and
only higher or equal priority interrupts can trigger the next
interrupt. So, the answer to your first question is yes, the interrupt
nesting of Linux _on AT91_ is controlled by the hardware logic.

Now about the I-pipe. The first implementation of I-pipe on AT91
followed the same logic as Linux, and this caused me a lot of headaches:
when testing the I-pipe: I could get timer interrupt jitter of 40 ms
when the board was put under ethernet irq load and could not understand
why. Until I understood that the interrupt controller had priorities,
and that the TC (used as timer hardware on AT91) had a lower priority
than the ethernet interrupt. So my first conclusion was that TC should
be given a priority higher than any other interrupt on the system if we
wanted to run Xenomai on AT91. And the result is that the I-pipe patch,
until 1.7-06 followed the same logic as Linux.

But this behaviour means that a non real-time interrupt can delay a
real-time interrupt if its hardware priority is higher. And discussion
with Jan convinced me that the behaviour was wrong: interrupt controller
priorities should only arbiter interrupts occuring at the same time, and
soon I understood why this happened: because of the late writing to the
AIC_EOICR register, so, I changed the write to the AIC_EOICR register to
happen when acknowleding the interrupt, at the very beginning of the
interrupt handling, which allowed me to test successfully the I-pipe
patch with the original interrupt priorities. So, the answer to your
second question is no: the priority in I-pipe (from 1.8-00 onward) is no
longer handled in hardware, and it is probably better the way it is.

Interestingly enough, I have not followed that discussion at all, but a
discussion took place about interrupt handling and the RT patch on AT91,
and looking at the patches sent to the linux-arm-kernel mailing list, it
seems that these people came to the same conclusion: write to the
AIC_EOICR should take place when acknowleding the interrupt, that is why
I say that the I-pipe patch is probably better the way it is.

-- 


					    Gilles Chanteperdrix.

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
 > But this behaviour means that a non real-time interrupt can delay a
 > real-time interrupt if its hardware priority is higher. And discussion
 > with Jan convinced me

Philippe was also involved in the discussion. The discussion starts
here:
https://mail.gna.org/public/xenomai-core/2007-10/msg00050.html

-- 


					    Gilles Chanteperdrix.

Re: [Adeos-main] at91sam9260

[Michael Trimarchi]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]


Hi,
>Wait a minute. You mean that you want more than 5000 interrupts by
>second ? Are you sure you do not get overruns with plain, unpatched
>Linux, if you load it sufficiently ?
If you do a simple count ( 115200 bps ) considering buffer length = 1 the answer is yes.

:)

regards Michael

PS work with linux





      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

[-- Attachment #2: Type: text/html, Size: 964 bytes --]

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

On Dec 17, 2007 11:23 AM, Michael Trimarchi <trimarchimichael@domain.hid> wrote:
>
>
> Hi,
>
> >Wait a minute. You mean that you want more than 5000 interrupts by
> >second ? Are you sure you do not get overruns with plain, unpatched
> >Linux, if you load it sufficiently ?
> If you do a simple count ( 115200 bps ) considering buffer length = 1 the
> answer is yes.
>
> :)
>
> regards Michael
>
> PS work with linux

When there is no load yes, but are you sure this is still true under load ?
I see discussions and patches on linux-arm-kernel about changing AT91
serial interrupt handling. So, are you sure this works that well with
Linux ?


-- 
                                               Gilles Chanteperdrix

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

On Dec 17, 2007 11:23 AM, Michael Trimarchi <trimarchimichael@domain.hid> wrote:
>
>
> Hi,
>
> >Wait a minute. You mean that you want more than 5000 interrupts by
> >second ? Are you sure you do not get overruns with plain, unpatched
> >Linux, if you load it sufficiently ?
> If you do a simple count ( 115200 bps ) considering buffer length = 1 the
> answer is yes.
>
> :)
>
> regards Michael
>
> PS work with linux

Do you observe this behaviour with I-pipe only or with Xenomai running
? If we xenomai, could you try only booting Linux with I-pipe enabled
?

-- 
                                               Gilles Chanteperdrix

Re: [Adeos-main] at91sam9260

[Michael Trimarchi]

[-- Attachment #1: Type: text/plain, Size: 314 bytes --]

Hi,

another simple question:

How the interrupt controllor priority are manteined by adeos for the root domain (LINUX)?

Regards Michael





      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

[-- Attachment #2: Type: text/html, Size: 685 bytes --]

Re: [Adeos-main] at91sam9260

[Michael Trimarchi]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

Hi,
>> 
 >> Hi,
 >> 
 >> I think that the problem of the overruns are related to the latency
 introduced by adeos, and the
 >> serial buffer of the at91sam9260 ( length = 1 ). 

>Wait a minute. You mean that you want more than 5000 interrupts by
>second ? Are you sure you do not get overruns with plain, unpatched
>Linux, if you load it sufficiently ?

Thank's for you help. I'm new on ipipe & xenomai. Yesterday I find a problem related to my patch and the at91 clock initialization ( I forgot to patch timex.h file ) and I will test serial line again as 
soon as possible. Now I try to integrate the leatest patch of ipipe from the git repository.
I think that is not possible to have a "wired interrupt" for the root domain, or exclude ipipe 
for a series of interrupt (just to try). I try to use linux without ipipe patch and I don't have
overrun on serial line. It is possible to count unhandled interrupt? Maybe I have some problem
but dosen't related to ipipe ( just visible with it ). are there test suite for ipipe?

Regards Michael


Regards Michael







      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

[-- Attachment #2: Type: text/html, Size: 1790 bytes --]

Re: [Adeos-main] at91sam9260

[Michael Trimarchi]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]


Hi,

+#define PICK_SPINUNLOCK_IRQ_RAW(lock)                          \
+do {                                                                   \
+       if (TYPE_EQUAL((lock), __ipipe_spinlock_t)) {                   \
+               __ipipe_spin_lock_irq(&((__ipipe_spinlock_t *)(lock))->__raw_lock); \
+       } else if (TYPE_EQUAL(lock, spinlock_t))                        \
+               __raw_spin_unlock(&((spinlock_t *)(lock))->raw_lock);   \
+               local_irq_enable();                                     \
+} while (0)

Who can me explain this in the official adeos-ipipe-2.6.20-arm-1.7-06.patch ?
I don't understand

Regards Michael





      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

[-- Attachment #2: Type: text/html, Size: 2368 bytes --]

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

Michael Trimarchi wrote:
 > 
 > Hi,
 > 
 > +#define PICK_SPINUNLOCK_IRQ_RAW(lock)                          \
 > +do {                                                                   \
 > +       if (TYPE_EQUAL((lock), __ipipe_spinlock_t)) {                   \
 > +               __ipipe_spin_lock_irq(&((__ipipe_spinlock_t *)(lock))->__raw_lock); \
 > +       } else if (TYPE_EQUAL(lock, spinlock_t))                        \
 > +               __raw_spin_unlock(&((spinlock_t *)(lock))->raw_lock);   \
 > +               local_irq_enable();                                     \
 > +} while (0)
 > 
 > Who can me explain this in the official adeos-ipipe-2.6.20-arm-1.7-06.patch ?
 > I don't understand
 > 
 > Regards Michael

Looks like a cut and paste bug.

-- 


					    Gilles Chanteperdrix.

Re: [Adeos-main] at91sam9260

[Michael Trimarchi]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]


Hi
>
>
> Hi,
>
> I think that the problem of the overruns are related to the latency
> introduced by adeos, and the
> serial buffer of the at91sam9260 ( length = 1 ).
>
>
> >Do you get the same behaviour if you apply
> >adeos-ipipe-2.6.20-arm-1.8-02.patch on a linux 2.6.20 ?
> >                                              Gilles Chanteperdrix
>
> I'll send soon my xeno-test. It is possible to serve an interrupt
 without
> pass
> throw the log system in the root domain?

>If you do not want to test the I-pipe patch on the kernel for which it
>is made, then I am afraid we can not conclude anything from any result
>you obtain.

>-- 
>                                               Gilles Chanteperdrix
I will test it on my board. 

Regards Michael






      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

[-- Attachment #2: Type: text/html, Size: 1755 bytes --]

Re: [Adeos-main] at91sam9260

[Michael Trimarchi]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]


Hi,

I think that the problem of the overruns are related to the latency introduced by adeos, and the
serial buffer of the at91sam9260 ( length = 1 ). 

>Do you get the same behaviour if you apply
>adeos-ipipe-2.6.20-arm-1.8-02.patch on a linux 2.6.20 ?
>                                               Gilles Chanteperdrix

I'll send soon my xeno-test. It is possible to serve an interrupt without pass
throw the log system in the root domain?

Regards Michael








      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

[-- Attachment #2: Type: text/html, Size: 1251 bytes --]

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

On Dec 13, 2007 4:27 PM, Michael Trimarchi <trimarchimichael@domain.hid> wrote:
>
>
> Hi,
>
> I think that the problem of the overruns are related to the latency
> introduced by adeos, and the
> serial buffer of the at91sam9260 ( length = 1 ).
>
>
> >Do you get the same behaviour if you apply
> >adeos-ipipe-2.6.20-arm-1.8-02.patch on a linux 2.6.20 ?
> >                                              Gilles Chanteperdrix
>
> I'll send soon my xeno-test. It is possible to serve an interrupt without
> pass
> throw the log system in the root domain?

If you do not want to test the I-pipe patch on the kernel for which it
is made, then I am afraid we can not conclude anything from any result
you obtain.

-- 
                                               Gilles Chanteperdrix

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

Michael Trimarchi wrote:
 > 
 > Hi,
 > 
 > I think that the problem of the overruns are related to the latency introduced by adeos, and the
 > serial buffer of the at91sam9260 ( length = 1 ). 

Wait a minute. You mean that you want more than 5000 interrupts by
second ? Are you sure you do not get overruns with plain, unpatched
Linux, if you load it sufficiently ?

-- 


					    Gilles Chanteperdrix.

Re: [Adeos-main] at91sam9260

[Michael Trimarchi]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

Hi,

>> adeos-ipipe-2.6.20-arm-1.7-06.patch
>>
>> I don't understand your question ?!

>Do you get the same behaviour if you apply
>adeos-ipipe-2.6.20-arm-1.8-02.patch on a linux 2.6.20 ?
>
>-- 
>                                               Gilles Chanteperdrix

I dont't try! because I don't have time to test my board for the 2.6.20, 
I hope that there are another people that work on at91sam9260 and ipipe.

Regards Michael






      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

[-- Attachment #2: Type: text/html, Size: 1240 bytes --]

Re: [Adeos-main] at91sam9260

[Michael Trimarchi]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

Hi,
>> I prepare an adeos patch for the at91sam9260 and linux 2.6.22, and I
 test it
>> with success. I reported only a problem with
>> the serial drivers. I have overrun and I can't using it in interrupt
 mode
>> with trasfer rate > 57600 using zmodem
>> protocol. Is there any suggest?

>Do you get the same behaviour with the "official" I-pipe patch ?

I start from the patch:
adeos-ipipe-2.6.20-arm-1.7-06.patch

I don't understand your question ?!

Michael






      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

[-- Attachment #2: Type: text/html, Size: 1158 bytes --]

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

On Dec 11, 2007 7:23 PM, Michael Trimarchi <trimarchimichael@domain.hid> wrote:
>
> Hi,
>
> >> I prepare an adeos patch for the at91sam9260 and linux 2.6.22, and I test
> it
> >> with success. I reported only a problem with
> >> the serial drivers. I have overrun and I can't using it in interrupt mode
> >> with trasfer rate > 57600 using zmodem
> >> protocol. Is there any suggest?
>
> >Do you get the same behaviour with the "official" I-pipe patch ?
>
> I start from the patch:
> adeos-ipipe-2.6.20-arm-1.7-06.patch
>
> I don't understand your question ?!

Do you get the same behaviour if you apply
adeos-ipipe-2.6.20-arm-1.8-02.patch on a linux 2.6.20 ?

-- 
                                               Gilles Chanteperdrix

[Adeos-main] at91sam9260

[Michael Trimarchi]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

Hi all,

I prepare an adeos patch for the at91sam9260 and linux 2.6.22, and I test it with success. I reported only a problem with
the serial drivers. I have overrun and I can't using it in interrupt mode with trasfer rate > 57600 using zmodem 
protocol. Is there any suggest?

Regards Michael




      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

[-- Attachment #2: Type: text/html, Size: 807 bytes --]

Re: [Adeos-main] at91sam9260

[Gilles Chanteperdrix]

On Dec 11, 2007 6:19 PM, Michael Trimarchi <trimarchimichael@domain.hid> wrote:
>
> Hi all,
>
> I prepare an adeos patch for the at91sam9260 and linux 2.6.22, and I test it
> with success. I reported only a problem with
> the serial drivers. I have overrun and I can't using it in interrupt mode
> with trasfer rate > 57600 using zmodem
> protocol. Is there any suggest?

Do you get the same behaviour with the "official" I-pipe patch ?

-- 
                                               Gilles Chanteperdrix