Frequent interrupt hangs VxWorks 5.4 on PowerPC
Mike Johnson
generated approximately every 10 microseconds, and hung his MPC7400
CPU board. Resetting and examining memory from the VxWorks boot
prompt, we observed that a task's stack was corrupted, and so was our
code. Obviously, this is not a practical application; an interrupt at
this frequency leaves very little time for anything else.
Nevertheless, the system should handle interrupts at any frequency
without overflowing stacks or corrupting code. Has anyone else
observed this problem?
Joe Durusau
I haven't seen this personally, but there are some things that
you just can't do. For example, if your ISR gives a semaphore or does
something that in effect makes the kernel have some deferred task that
it needs to work on later, you willl cause a kernel panic if you do
things
at this rate. Also, on some arch's, the ISR uses a task's stack, so if
the ISR does any significant work, (not likely in your test case) it
can overflow the stack. Finally, it might just be a simple memory leak
in the ISR code itself.
Speaking only for myself,
Joe Durusau
Aaron MacDonald
calling chain? We have seen a specific case of someone calling
taskUnlock inside an ISR which can cause problems. If you do see
reschedule in the stack trace, I can give you more details.
Cheers,
Aaron
Varndell Engineering
Mike,
If your coworker went around the PIC (assuming there is one, EPIC?),
and drove the CPU interrupt pin directly, I would say this is exactly
what you should expect to see. If, on the other hand, he was driving
an input to an interrupt controller, then you have a legitimate gripe.
Even so, the problem in this case would be with the BSP, not the kernel.
I have several PPC boards I can hit with line-rate Gigabit ethernet
packets. They clam up under the load, because they're doing nothing
other than handling interrupts, but they don't croak. And when the
packet storm subsides, they resume functioning normally.
Regards,
George Varndell
--
Varndell Engineering, LLC
Embedded Systems Expertise
http://www.varndellengineering.com
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Mike Johnson
> I haven't seen this personally, but there are some things that
> you just can't do. For example, if your ISR gives a semaphore or does
> something that in effect makes the kernel have some deferred task that
> it needs to work on later, you willl cause a kernel panic if you do
> things
> at this rate. Also, on some arch's, the ISR uses a task's stack, so if
> the ISR does any significant work, (not likely in your test case) it
> can overflow the stack. Finally, it might just be a simple memory leak
> in the ISR code itself.
>
> Speaking only for myself,
>
> Joe Durusau
Thanks, Joe. I've only been using real-time OSs for eighteen years,
and VxWorks for nine years, so, obviously, I don't know everything. I
am well aware, however, of kernel work queue panics, and of the system
calls that ISRs aren't allowed to make. My ISR (actually I'm using the
decrementer) doesn't do much more than decrement a counter and flash
some LEDs. It makes no system calls.
This problem isn't a kernel work queue panic. Kernel work queue panics
usually reboot the board and leave some textual information in low
memory (at 0x4300 on the Synergy board I'm using). My board doesn't
reboot, and there's no text at 0x4300. The board just hangs. Stacks
and code, seen from the VxWorks boot prompt after reset and before the
OS is reloaded, are corrupted. If this symptom is caused by a stack
overflow, the stack usage doesn't increase gradually over time.
Frankly, I suspect a race condition in Wind River's interrupt handling
code.
You might have seen this same problem yourself without really noticing
it. Ever have a board running VxWorks just lock up for no apparent
reason? If so, when you reset the board, did you ever stop it at the
VxWorks boot prompt and examine memory?
Koen Van Hulle
I've seen this behaveour also. In my case, the system put a limit on the
interrupts frequency because the kernel workqueue was full.
If the interrupt frequency is too high, you won't even see the related
"WorkQ Panic message" getting thru.
The WorkQ full problem has been discussed many times in this newsgroup
(check the archives) and on WindSurf.
Other than that, I know of no errors (except bugs in the interrupt handler)
that could limit the interrupt frequency.
Regards,
Koen
"Mike Johnson" <mwj...@hotmail.com> wrote in message
news:82606370.0205...@posting.google.com...