> you should really upgrade to 2.4.9.1. I'm now running Xenomai 2.4.9.1 on Linux 2.6.28.9.
>>> I had a look at handle_prio_irq in arch/arm/mach-ns9xxx/irq.c. What >>> this irq handler does is bad, really bad. If you care about interrupt >>> latencies, you should really use handle_level_irq. That is, replace the >>> #if 0 with a #if 1. Interrupt latency in the Linux kernel is not important to me, but Xenomai interrupt latency is critical. Just for the fun of it, I tried switching to handle_level_irq() and then adding an irq_finish() function similar to the AT91, but Linux locks up during the boot sequence while initializing the Ethernet stack. The timing of ACK/EOI on this chip is sensitive. Currently the problem is that a Xenomai ISR on this system needs to respond to interrupts consistently under 50 microseconds. When the system is running idle or when running "dd if=/dev/zero of=/dev/zero", it's able to respond to an IRQ trigger by toggling a GPIO within 35 microseconds. But if I run "top" and then flood the serial input buffer with carriage returns (holding down the enter key) the oscope occasionally shows a large delay, in about 1 out of every 30 ISR calls the GPIO toggles late on the order of 100-300 microseconds. The timing is worse when I flood the system with pings, upwards of 3 milliseconds to respond, although the majority remain under 35 microseconds. These tests have been run using a LeCroy 1 GHz Oscilloscope. I've been through the Troubleshooting and verified that all power management, frequency modulation, etc. are disabled. The serial port driver does not appear to be masking the interrupts. Any ideas as to what could be causing these delays? Thanks for your help. - James _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
