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

[Joel Sherrill]

On 03/01/2011 06:20 AM, Fabrício de Novaes Kucinskis wrote:
> Hi Joel,
>
> As I said before, we've solved our problem by replacing printf with printk, and we'll keep it this way; the main reason of this question was to understand what could have changed.
>
> If this new version of the driver will allow printf to work without affecting anything else on 4.10, then ok. But if there's some side effect, please keep the code as it is - I'm worried you're committing a patch just to solve OUR problem...
>
The driver should support polled so adding that back in as the
default behaviour is correct.

If there are other issues with the new driver, I would like to
nail them before 4.10.1.

--joel
> Thanks again,
>
> Fabrício.
>
>
> -----Mensagem original-----
> De: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> Enviada em: segunda-feira, 28 de fevereiro de 2011 17:11
> Para: Fabrício de Novaes Kucinskis
> Cc: filipe at dea.inpe.br
> Assunto: Re: RES: RES: Is there any change on interrupt catch between RTEMS 4.9.4 and 4.10.0?
>
> I think I see a problem.  In 4.9.x, the console driver defaults
> to polled.  You are using UARTA RX ISR.  In 4.10, the driver
> only supports interrupt mode as best I can tell.  Your ISR
> is taking the ISR source and not letting it get processed by
> the driver.
>
> I am committing a version of the driver to the head which
> SHOULD be OK with 4.10 and supports polled.  So your
> test probably will work again.
>
> --joel
>
> On 02/28/2011 12:19 PM, Fabrício de Novaes Kucinskis wrote:
>> Joel,
>>
>> Thanks for the answer. As you asked, I'm sending attached a simple example of the problem. The .zip has also two versions of the executable (stripped for sizing reasons): You'll see that the 4.9.4 version runs on SIS, while the 4.10 version no.
>>
>> Regards,
>>
>> Fabrício.
>>
>>
>>
>> -----Mensagem original-----
>> De: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
>> Enviada em: segunda-feira, 28 de fevereiro de 2011 11:07
>> Para: Fabrício de Novaes Kucinskis; rtems-users at rtems.com
>> Assunto: Re: RES: Is there any change on interrupt catch between RTEMS 4.9.4 and 4.10.0?
>>
>> 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.
>


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985