<To RTLinux [EMAIL PROTECTED]>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Date: Thu, 31 Aug 2000 22:22:14
> From: [EMAIL PROTECTED]
> To: Pierre Cloutier <[EMAIL PROTECTED]>
> Subject: Re: [rtl] RTAI and RTLinux
>--------------------------------------------------------------------------------
[snip]
> I do continue to think that RT software should be simple and
> not rely on dynamic allocation of resources -- since this is not
> compatible with determinism.
>
> This is an interesting and important technical topic and one that
> would benefit from real data and cases.
[snip]
Well, I think I have such a "real" case. I am working on a RTLinux
project that acquires data from an analog-to-digital card (16 channels
at 5000 Hz / channel) with interrupts paced by the A/D card.
I'm using Red Hat 6.1 with Linux version 2.2.14-rtl2.2 (gcc version
egcs-2.91.66 19990314/Lin ux (egcs-1.1.2 release)) #4 on a pentium
233 Mhz.
When I boot the computer and load and run my application, sometimes
it works correctly and sometimes it freezes the computer (no oops
kernel dump) requiring me to power boot it. The computer stops
after returning (without any errors detected) from a fifo handler.
I have not yet been able to determine what causes it to fail but I
suspect that I might be using too much stack space. Is it the
function call depth? Too many args to my functions? Too much
dynamic memory allocated on the stack?
My code is (should be) deterministic in its usage of the stack but
it may require a little more than the default stack has which is why
I would like to be able to define the stack size for my code so I
can be sure it will have enough stack when it executes.
I've identified, with the gracious help of Victor, that some of my
functions use too much dynamic stack space in the form of local function
variables.
It turns out, according to Victor, that the amount of stack memory
available to RTLinux code is, well, unpredictable (non-deterministic?)
Regarding the stack available to RTL interrupt service routines,
Victor explains:
> >> >It can be small and it is hard to predict - actually this is
> >> >a problem that we may have to address in detail later one. The cause
> >> >of the problem is that when RTLinux interrupts Linux during Linux kernel
> >> >mode, we must operate on what remains unused in the the Linux kernel stack.
> >> >So a poorly designed Linux driver, for example, may make heavy use of the
> >> >stack and leave us with very little.
Why can't I define the stack size for my RTL interrupt service routine?
Isn't the stack for an RTL interrupt service routine a RTL system
resource that should be managed by the RTLinux system? Wouldn't
that make it more robust (ie deterministic) than having to hope and
pray that other Linux drivers don't intermittently use "too much"
stack?
I can use the pthread_attr_setstacksize() to define the stack for my
RTLinux processes but how do I do this for a fifo handler? For
init_module() and cleanup_module() code? For my RTL interrupt
service routine?
I want my code to run predictably (ie deterministically) and not crash
unpredictably because of some other code as consumed too much stack.
I'm beginning to realize that there are quite a number of different
execution contexts, each with its own largely undocumented set of
rules. I would like to find out what "rules" there are for stack
usage in each of these contexts.
Here's what I count (so far) for execution contexts:
Standard Linux
USER MODE
1. linux processes
KERNEL MODE
2. init_module()
3. cleanup_module()
4. linux device driver code
5. linux interrupt service routine
RT Linux (all of the above plus:)
KERNEL MODE
6. RTL init_module() (additional rtl_xxx functions are available)
7. RTL cleanup_module() "
8. RTL fifo handler
9. RTL interrupt service routine
10 RTL processes (stack size set with pthread_attr_setstacksize())
There may actually be more execution contexts ("environments"?) that these.
RTLinux seems to have undocumented "rules" such as (in my words):
The stack size for an RTL interrupt service routine is extremely
limited and is not settable by the application programmer. To
be on the safe side, an RTL ISR should use no more than 10 or 20
bytes of stack. If an ISR overflows the stack, a system crash
will result. It is not possible for an ISR to determine how
much stack space it has available to it.
The stack size for an RTL process can be defined in the processes's
attribute block with the pthread_attr_setstacksize() function
before calling pthread_create(). pthread_attr_setstacksize() is
not found by the "man" program.
In otherwords, I think the stack should be a RTL system controlled
resource. Its use is unavoidable.
My wish: I would like to see RTLinux provide a way for me, the
application programmer, to define the stack size for each of these
contexts (#6-#9 above).
Interestingly, I did not find any information about the stack in
Rubini's Linux Device Drivers book.
Well, I feel that what I'm trying to do constitues a "real case" and
I am definitely interested in learning more about the using of the
stack in the RTLinux system.
I haven't had the chance to review RTAI but I would also be interested
in a discussion from that camp.
Finally, I want to thank Victor for all of his generous help!
-------------------------
Shel Hoffman
-------------------------
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
