This is a discussion on ISR Overflowing Stack - Why? - VxWorks ; I have a Pentium IV with a DEC 21143 NIC running VxWorks 5.4 (Tornado 2.0.2). VxWorks is configured to use the tasks' stacks for the ISR instead of having a dedicted ISR stack. In my test, I am sending a ...
I have a Pentium IV with a DEC 21143 NIC running VxWorks 5.4 (Tornado
2.0.2). VxWorks is configured to use the tasks' stacks for the ISR
instead of having a dedicted ISR stack.
In my test, I am sending a high rate of SYN packets at the interface,
which does not have a configured IP.
After I start my test, I start spamming 'checkStack' and I'll catch a
task or two with OVERFLOW stamped out to the side of output. Killing
my test quickly keeps the box in a somewhat stable state. It's
repeatable on multiple boxes.
The stack(s) that are overflowed are 10-20K in size. Upon sleuthing
from the top of the stack, I observe patterns pointing at VxWorks'
interrupt handling code.
01c32f40: 01c32f70 00abd5ec 00000007 00055f5a *p/..........Z_..*
01c32f50: 00000020 00000200 00000200 001094f1 * ...............*
01c32f60: 00000020 00000206 00000200 00000200 * ...............*
01c32f70: 01c32fa4 01893cb6 00000005 00000005 *./...<..........*
01c32f80: 00055f59 00000020 00000200 00000200 *Y_.. ...........*
01c32f90: 001094f1 00000020 00000206 00000200 *.... ...........*
01c32fa0: 00000200 01c32fdc 01893cb6 00000005 *...../...<......*
01c32fb0: 00000005 00055f58 00000020 00000200 *....X_.. .......*
01c32fc0: 00000200 001094a4 00000020 00000206 *........ .......*
01c32fd0: 00000200 00eeeeee 00000200 01c3300c *.............0..*
01c32fe0: 00abd5ec 00000007 00055f58 00000020 *........X_.. ...*
01c32ff0: 00000200 00000200 001094f1 00000020 *............ ...*
01c33000: 00000206 00000200 00109465 001094a4 *........e.......*
Interesting notes about the "stack frames":
- This basic pattern of following stack frames continues all the way
down to the current task's stack frame'
- The pattern ocassionally breaks by an sfp landing on 0x00109a4.
More on this address in a moment.
- The return ip's are either:
0x00abd5ec - intBoiExit()
0x01893cb6 - Instructions offset ~65K into the heap that are
exactly like that of intBoiExit with the exception
that the first instruction is:
ADD ESP, 8
ADD ESP, 4
Why is this in the heap and how did it get there?
- Within the stack frames, two other addresses are prevalent:
0x001094a4 and 0x001094f1.
0x001094a4 - Instruction after intUnlock() in i8259IntBoi().
0x001094f1 - Instruction after intUnlock() in i8259IntEoiMaster().
- Looking at i8259IntBoi(), it plays funny games with the return ip,
basically by rewriting it return to intBoiExit().
sysStrayIntCount++; /* increment the counter */
/* Very Dangerous Arch. dependent code follows: */
/* Indexes off of parameter to return address on stack */
/* On Intel platform this is -1 NOT +1 from &irqNo */
*((UINT32 *)&irqNo - 1) = (UINT32)intBoiExit; /* change return
- Since both intBoiExit() and i8259IntBoi() addresses appear
in the dump (whether residual cruft from old stack frames or not),
I dumped 'sysStrayIntCount'. It is almost as large as the number
of RX interrupts I've processed. Lots o' spurious interrupts,
which apparently is normal for Tulip chips (the DEC card).
What is happening? I don't think the ISR is recursing (the DEC driver
doesn't) and I wouldn't expect VxWorks to be doing that.
How would the ISR incrementally use more stack?
The specific mechanism of when the ISR starts and finishes using the
task's stack is an unknown to me:
- Does the first frame of the ISR stack point back to the tasks
stack (i.e., ebp storing the previous base pointer)? I
would presume not.
- How is the stack pointer used when starting the ISR handling?
- How is the task's stack pointer restored?
What I'm wondering is if the task's stack pointer isn't being restored
properly and back-to-back-to-back interrupts are causing the stack
usage to "creep". Is this feasible?
Any help, indirectly or otherwise, would be tremendous. Thanks