AW: [En-Nut-Discussion] Serious bug in Realtek driver - concerning RC3.4.3

Oliver Schulz olischulz at web.de
Mon Apr 19 22:05:50 CEST 2004


Hi Pavel,

it seems, that you are richt with your analysis, as far as I can see.

In description for NutEventPostAsync everyone can read: "It is save to call
this function from within an interrupt handler. In any case interrupts must
be disabled when calling this function."

So I think, the "sei()" is definitly wrong.

Futhermore, the new irqstack, implemented in Nut/OS 3.5.x (works only with
gcc), is not compatible with nested interrupts. If an nested interrupt
occurs, the stack of the interrupted thread is blown up.

So I will try to make the irqstack compatible with nested interrupts in the
next hours...

Cheers,
Oliver.

> -----Ursprungliche Nachricht-----
> Von: en-nut-discussion-bounces at egnite.de
> [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von
> Pavel Chromy
> Gesendet: Montag, 19. April 2004 21:30
> An: Ethernut User Chat (English)
> Betreff: [En-Nut-Discussion] Serious bug in Realtek driver -
> concerning
> RC3.4.3
>
>
>
> Hi All,
>
> I discovered a serious bug in interrupt routine in Realtek driver -
> have a look at this (important lines only):
>
> cbi(EIMSK, RTL_SIGNAL_BIT);
> sei();
> NutEventPostAsync(&ni->ni_tx_rdy);
> cli();
> sbi(EIMSK, RTL_SIGNAL_BIT);
>
> That is, it enables interrupt and then calls
> NutEventPostAsync() with interrupts enabled,
> which basicly works unsless some other interrupt routine is
> using the same technique.
> In such case threads start dying, because of (I suppose)
> interrupted thread queue manipulation
> which is (naturally) not reentrant.
>
> I discovered this when programming my own driver for a device
> connected to external interrupt
> pins and used nested interrupts the same way as realtek driver does.
>
> When I surrounded NutEventPostAsync() by NutEnterCritical()
> and NutExitCritical()
> or simply by cli() and sei() in my code, everything works perfectly.
>
>
> The new VS1001 driver is also using nested interrupts, but it
> does not call any
> non-reentrant system functions though and thus it is not affected.
>
> Although the driver works with the code in the distribution I
> consider this to be a bug
> since it may conflict with similar user interrupt routines.
>
>
> --
> #define QUESTION ((bb)||!(bb))
>
> Mgr. Pavel Chromy
> ASIX s.r.o.
> Staropramenna 4
> 150 00 Praha 5
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion




More information about the En-Nut-Discussion mailing list