Interrupt descriptor overwriting - windows

Interrupt descriptor overwriting - windows

Post by Kasper Pederse » Sat, 02 Aug 2003 05:26:17



A year (or two?) ago someone on this group tried overwriting the timer
interrupt descriptors under windows, bypassing the normal HAL stuff, and
got some (for plain windows) pretty impressive response- and jitter
times. I replicated it under WDOSX, and found it to be very effective.
Unfortunately I lost both the original posts and the code I wrote.

Hello, are you still here?

/Kasper

--

 
 
 

1. VME interrupts interrupting VME interrupts

This question has to do with a higher priority VME interrupt interrupting a
lower priority one. Preempting here means that if a lower priority ISR
(interrupt service routine) is running, the higher priority one will "interrupt"
it, finish its ISR, and then the lower priority interrupt's ISR will continue.

We are VxWorks "users", not "developers". Or, our application is a laboratory
engine control and instrumentation system that is VME and VXI with all hand
written C; we are not writing BSPs. However, we are not totally ignorant; we do
know a bit about VxWorks and its inner workings. Also, the main motivation
behind all this is that we have one interrupt for which we would like to keep
the latency "constant", which is the case on a 68k board. We are trying to get
this to work on a PPC board, on which the interrupt latency happens to not be
"constant".

We are using VxWorks 5.3.1 (and 5.2 and even 5.1), but not really using Tornado
1.?, since we use "5.2 mode" with the shell on the target and a startup script
or whatever it's called; we do it the old fashioned way.

The VME specification prioritizes the IRQ levels (and then the daisy chain
prioritizes interrupters on the same level), and says that if two interrupts
occur simultaneously, the higher priority one will be serviced first. I haven't
found any spec. for what should happen if a higher priority interrupt is
asserted while a lower priority interrupt's ISR is executing.

The context of the question is the situation on a 68k board versus a PPC (604)
board that uses a Universe II VME-PCI interface. On the 68K board a higher
priority interrupt does preempt a lower priority one (as observed using some
hardware signals), while on the particular PPC board, if the lower priority
interrupt is running while the higher priority one is asserted, the higher
priority one does not execute until the lower priority ISR has completed.

We understand the concept of why this is so; the 68k interrupts _are_
prioritized, while on the PPC BSP the Universe II uses one PCI interrupt for all
VME interrupts. Some people have said that one might be able to remap one or
more of the VME interrupts to another PCI interrupt. We can see how this might
happen (we have the Universe II user manual, among other info).

Without enough detailed knowledge, it is hard to tell how difficult remapping an
interrupt would be, and if one would even want to do it (i.e., modify the BSP
for one particular situation).

So, the question more or less is if anyone has any similar experience with, or
comments on this situation. What I would really like to know is if anyone knows
if we have any hope of readily doing this, or if it would get really ugly. I
don't wish to spend a lot of (or, rather, more)  time on this. The vendor is
already (apparently) pondering the question as well. Thanks for any assistance
or comments.

--
Francis Connolly            Technical Specialist
FMC-FAO-PD-R&VT-P&AE-CAPE-APPTE-CEFET-P/T ET

313-317-7404 fax                CDS ID: fconnoll

2. Step rates and subdirectories ("fold - (nf)

3. Suppressing Overwrite Messages in Windows 9x

4. Still looking for...

5. Getting Descriptors the Windows way

6. IRQ Conflict

7. Interrupt number vs. Interrupt level

8. Quicken Win 5 Video Problem

9. mpc860 interrupt debug problem "uninitialized interrupt"?

10. debuging fads860 interrupt problems "uninitialized interrupt"

11. "interrupt: bad vme interrupt 0" on MVME2604

12. Installing Interrupt Handler with a pending interrupt

13. interrupt 0x08 and interrupt 0x1c !!!!