Porting ethernet driver from FREEBSD to rtems-libbsd

[Isaac Gutekunst]

I'm going to chime in since this sounds like a similar problem I've
experienced on a PIC32.

I wanted to reword what Ragunath said in my own words to see if I
understand it.

1) The RX ISR fires, vectoring the code to the ISR entry.
2) The code in the ISR disables interrupts, creates an event to be handled
by RTEMS (in a non interrupt context)
3) At some point (dispatch function), interrupts are enabled
4) Since the RTEMS task responsible for performing non-generic handling
hasn't run, the hardware condition that created the initial interrupt has
not been cleared. Therefore, the interrupt controller vectors to the ISR
entry again, repeating the cycle.


In this case, the fundamental problem is that an ISR will continue firing
until the condition causing it is resolved. In the case of an RX interrupt,
that usually would mean reading data from a SFR or buffer. I'm not familiar
with this specific case, but it sounds awfully similar.

Does this sound right?

If so, it seems like a rather fundamental problem I haven't been able to
resolve. I'm hoping someone has found a reasonable solution that I wasn't
smart enough to figure out my self.

Isaac

On Thu, May 28, 2015 at 8:01 AM, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> It depends on the capabilities of the interrupt controller. Maybe you have
> to drop the support for nested interrupts. The bsp_interrupt_dispatch()
> function for a state of the art interrupt controller looks like this
> (arm-gic-irq.c):
>
> void bsp_interrupt_dispatch(void)
> {
>   volatile gic_cpuif *cpuif = GIC_CPUIF;
>   uint32_t icciar = cpuif->icciar;
>   rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
>   rtems_vector_number spurious = 1023;
>
>   if (vector != spurious) {
>     uint32_t psr = _ARMV4_Status_irq_enable();
>
>     bsp_interrupt_handler_dispatch(vector);
>
>     _ARMV4_Status_restore(psr);
>
>     cpuif->icceoir = icciar;
>
>   }
> }
>
> On 28/05/15 13:50, ragu nath wrote:
>
>> Hi Sebastian,
>>
>> The problem is with rx interrupt. We are enabling rx interrupt before
>> it is processed. The rtems server task do not get an opportunity to
>> run.
>>
>> I found this might be the logical explanation of the issue.
>> bsp_interrupt_dispatch() calls bsp_interrupt_server_trigger which
>> disables the rx interrupt and creates BSP_INTERRUPT_EVENT .  For this
>> event, bsp_interrupt_server_task() was supposed to call the actual
>> interrupt handler and then enable the rx interrupt. But before the
>> event is processed, we enable the rx interrupt in dispatch function.
>> So again rx interrupt is generated and event is created and the cycle
>> goes on. Server task is never executed in turn actual interrupt
>> handler is never executed.
>>
>> Since we enable the interrupt, it occurs again and again as we never
>> handle it.
>>
>> Is there any other possibility that I might need to look into?
>>
>>
>> Thanks,
>> Ragunath
>>
>> On Thu, May 28, 2015 at 4:58 PM, Sebastian Huber
>> <sebastian.huber at embedded-brains.de> wrote:
>>
>>> Hello,
>>>
>>> the bsp_interrupt_dispatch() is quite complicated in the beagle BSP. Is
>>> the
>>> interrupt controller of this chip really that broken? Sane interrupt
>>> controllers block interrupts of equal or lower priority relative to the
>>> currently pending interrupt.
>>>
>>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150528/e29f6390/attachment-0002.html>