<To RTLinux [EMAIL PROTECTED]>
Dear Victor & David,
Thank you both so much for your thoughtful and rapid response to my
email regarding the stack in RT Linux. I find this sort of
discussion insightful and I hope others do, too.
I mistakenly thought that it would be an easy matter to define a
stack for an RTL ISR but, but as David points out, this wouldn't
address reentrancy correctly.
And as Victor says that, it would also add additional time, albeit
only a few instructions, to the processing of each interrupt.
>Why do you use "lots" of stack space inside RTL ISRs and FIFO
>handlers in the first place?
For debugging the RTL ISR (for the pci-das-1602, an Analog-to-Digital
card from Computer Boards), I am trying to use a printf-like routine
called "videof()" which writes a formatted string to monochrome
memory. I found this to be an extremely useful technique for
debugging ISRs in DOS and was just trying to utilize it in RTLinux.
Videof() originally allocated char buf[256] on the stack into which
it would vsprintf() a string before it loads it into monochrome
memory (at 0xB0000).
I suspected that videof() was corrupting the stack. I made the
buffer static (not on stack) but this has not eliminated the bug
that I've been chasing down.
The reason why I think I have a stack corruption is the way
the bug is behaving: it seems to occur randomly and none of
my code is detecting any errors.
I have combed the ISR and all the routines it calls for excessive
stack usage (beyone one or two variables and a few function
arguments) and I believe that the stack requirement is now
minimal (eg. no arrays on the stack, no large structs, etc).
Yet the PC freezes during a write() by a Linux process to an RTL
fifo.
The fifo handler gets control, processes the "command" (from the
linux process to initialize the card) correctly and exits. Then the
machine freezes and I have to power boot it. I see plenty of
messages on the monochrome screen from both the linux process and
from the fifo handler indicating that everything went well yet I
still get the freeze.
Strangely, this is not repeatable. When I reboot and rerun the
test, it works perfectly! The card initialization code is identical
to the code that works with the DOS software. So I'm reasonably
sure that I'm not mucking up something with the pci-das-1602.
Besides, all the initialization appears to run correctly (from
the messages I see on the mono monitor).
This is why I thought that perhaps the stack was being corrupted
(eg. through an unintended interraction with another ISR and my RTL
code). I am using TELNET to access the computer running the test so
there is network activity during the test. (The TELNET session
stops responding when the machine freezes).
When the machine freezes, it is consistent. The Linux process's
write(fifo, ) statement hasn't returned and after the RTL fifo
handler has exited, I'm at a bit of a loss as to where to look for
the bug!
Could someone suggest an approach that I might take to isolate this bug?
I'm using RedHat 6.1 on a p233 with Linux version 2.2.14-rtl2.2 (gcc
version egcs-2.91.66 19990314/Lin ux (egcs-1.1.2 release)) #4
Thank you again for your kind consideration.
-------------------------
Shel Hoffman
Reflective Computing
917 Alanson Dr
St. Louis, MO 63132 USA
(314) 993-6132 voice
(314) 993-3316 fax
[EMAIL PROTECTED]
-------------------------
-- [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/
