RES: Is there any change on interrupt catch between RTEMS 4.9.4 and 4.10.0?

[Joel Sherrill]

I don't think this is the overall interrupt processing code. The console code was reworked after 4.9.  It is a bug in the new console. Please try to put the old code in the 4.10 or just compare it to find the change that broke this. It really sounds like it is simply not processing the interrupt from the uart.  Then the ISR is not tripping termios and tasks are not unblocking.  With nothing unblocked, you end up in idle.

Does someone have a simple example so I can repeat this?

--joel

Fabrício de Novaes Kucinskis <fabricio at dea.inpe.br> wrote:

>Hello,
>
>I'm experiencing the same problem Filipe described, and have some more details.
>
>I have a simple application that runs on SPARC/SIS. It uses printf to show the user some info, and gets data through the UART A interrupt.
>
>This application worked fine on RTEMS 4.6.4 through 4.9.4. After upgrading to 4.10, it stopped working.
>
>What happens, as far as I could go, is the following:
>
>1. The application starts and prints a lot of messages;
>2. At some point, it calls 'rtems_interrupt_catch' to install the handler for UARTA (the same UART used by printf);
>3. After the rtems_interrupt_catch, it runs some more instructions, until it reaches the next printf;
>4. When executing this printf, only the first character is printed, and then the application halts.
>
>Debugging, I could identify that, after step 4 above, the application is only running the Idle task, as if there were nothing else to run (which is not true). It seems that the control never returns to the task that called printf, since any breakpoint after this call is reached.
>
>If I use printk instead of printf, this doesn't happen.
>
>As this didn't occur until RTEMS 4.9.4, what could've changed? Maybe the change on the interrupt handler type on the Interrupt Extension API? Something related to printf?
>
>It seems I could change all printf's to printk's to solve the issue, but it would be important to know the reason of the problem.
>
>Thanks in advance and best regards,
>
>Fabrício de Novaes Kucinskis.