# Consecutive PendSV IRQ Handler Delays Other Interrupt Handler **URL:** \ **Category:** Kernel\ **Tags:** debug\ **Created:** [October 12, 2022, 1:15pm UTC](https://forums.freertos.org/t/consecutive-pendsv-irq-handler-delays-other-interrupt-handler/15999 "2022-10-12T13:15:21Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![D\_TTSA](https://avatars.discourse-cdn.com/v4/letter/d/5f9b8f/32.png) [@D\_TTSA](https://forums.freertos.org/u/D_TTSA)\ **Post date:** [October 17, 2022, 12:59pm UTC](https://forums.freertos.org/t/consecutive-pendsv-irq-handler-delays-other-interrupt-handler/15999/4 "2022-10-17T12:59:48Z")
Good day @rtel We have done further testing, and believe that we have narrowed down the problem. To test if the problem was caused by interrupt nesting, we set all interrupt priorities to 0x0F (same priority as SysTick and PendSV). However, this worsened the interrupt delays: ![image](https://d2v6vdsk2p900z.cloudfront.net/original/2X/6/6adbacb6ae6def128ac01b25ee840e3526f4cd02.png) It is worth noting that the problem is not specific to the GPT2 ISR, as I may have implied in my first post (above delay is in SysTick handler, for example). We noticed that the SysTick and PendSV ISR’s don’t call `__DSB()` in their last line (other ISR’s do). To test if this was related, we added `__DSB()` in the last line of the PendSV ISR. This caused the PendSV ISR to be delayed every time it was called: ![image](https://d2v6vdsk2p900z.cloudfront.net/original/2X/6/6a7384ffbfe846bbe4979ccf28f1f7c6356d6b09.png) Consequently, our hypothesis is that the `__DSB()` call is what is slowing down our interrupt handlers, intermittently. This could be caused by [ARM’s non-sequential memory accesses](https://www.embedded.com/dealing-with-memory-access-ordering-in-complex-embedded-designs/). Do you agree with our hypothesis? Do you have advice for us? Kind regards D\_TTSA --- _[View the full topic](https://forums.freertos.org/t/consecutive-pendsv-irq-handler-delays-other-interrupt-handler/15999)._