Re: [Xenomai-help] Running out of stack memory in kernel-space

["Andreas Glatz" <AndreasGlatz@domain.hid>]

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

Hi,


> What bothers me is that you seem to determine a latency based on
> measurements of a round trip time, obtained on an ethernet network. So
> it is a bit difficult for me to give any interpretation about the 70 us
> figure; too many variables in that equation.
> 
> > 


I finally upgraded Xenomai from version 2.4.4 to 2.4.8
as you strongly suggested last time and I can say 
that this fixes all of the bugs we found in the earlier 
version. Thanks a lot for that!!

Furthermore I did some serious measurements with the new
Xenomai version on an MPC8360. In short, I measured
an interrupt latency around 7us when running in kernel-space
and around 35us when running in user-space. You can find
the details of those measurements the end of this Email!

I have two more questions:

1) In the legacy code I am porting, critical sections are
protected by disabling/enabling ALL interrupts (like
sti/cli in kernel-space). This method is much faster than
locking a mutex, which might put a task to sleep. Are there
similar, portable functions available under Xenomai or IPIPE?

2) In the legacy code we also have some low priority
tasks which are performing lengthy operations (around 1s).
Of course, those low-priority tasks prevent Linux tasks
from running. In our case this behaviour is bad. Just in 
the case of those low-priority task, Linux should be able 
to preempt those tasks. From our viewpoint, the best solution
to that problem would be if we could assign those tasks 
the same or a lower priority than Linux tasks. That would
give us the best of both worlds: We could call Xenomai 
API functions from those task without switching back and
forth between primary and secondary mode and Linux tasks 
wouldn't be preempted.


Thanks again to you and the other Xenomai contributors 
for producing such a good piece of Software!! I hope 
that you'll keep the good work up. I'm also looking
forward trying out Version 2.5!


Best regards,
Andreas Glatz









---------------------------------------------------------

The test setup is shown in file "testsetup.pdf". 

We are running a Xenomai application on the MPC8360 
which grabs the UEC 7 IRQ and replaces the RX and TX 
buffers and buffer rings of the Linux UEC driver by its 
own RX and TX buffers and buffer rings. Those buffers are 
allocated from a RT_HEAP object which was created with 
the H_DMA flag. The Xenomai application is highly portable 
between kernel- and user-space. The only differences between
the kernel-space and user-space version is the way they
are linked (shared libraries vs exported functions).

The Xenomai application periodically sends a 64byte 
Ethernet frame over the 100Mbit MII Interface to the 
Ethernet Switch where the Frame is looped back on
Port 1. The frame travels back over the MII interface 
to the MPC8360 and is received by the Xenomai application.

As described in "testsetup.pdf" we measured the following
signals with an Oscilloscope: Rx_DV, Tx_EN, GPIO Pin.

The GPIO Pin is toggled every time the UEC 7 ISR is called.
The UEC 7 Interrupt is triggered after Rx_DV and Tx_EN 
go from high to low. So the time between the neg. slope of
Rx_DV and Tx_EN and a Pin state change is the equal to 
the interrupt delay. See "loopks.pdf" and "loopus.pdf"
for detailed results. 

[-- Attachment #2: testsetup.pdf --]
[-- Type: application/pdf, Size: 30527 bytes --]

[-- Attachment #3: loopks.pdf --]
[-- Type: application/pdf, Size: 77576 bytes --]

[-- Attachment #4: loopus.pdf --]
[-- Type: application/pdf, Size: 76722 bytes --]