[ECOS] RE : [ECOS] possible fix for eth_drv_recv blocking DSR

[ECOS] RE : [ECOS] possible fix for eth_drv_recv blocking DSR

[Arnaud Chataignier]

James,

As you had no answer and I know it, I will try to help.

There should be no DSR in an Ethernet driver device. Your ISR should
only ask for a DSR call. The DSR is handled in the IO ethernet part, not
in the device driver.

The IO ethernet DSR only triggers the execution of the Network alarm
thread, which then calls your ethernet driver 'deliver' function. Your
deliver function is thus called from a thread, and there is no interrupt
lock/unlock to be done in cyg_splx and spl_any.

Regards,
Arnaud.

-----Message d'origine-----
De : ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] De la part de Hook,
James
Envoyé : vendredi 24 juin 2005 19:35
À : ecos-discuss@sources.redhat.com
Objet : [ECOS] possible fix for eth_drv_recv blocking DSR


I mask Ethernet driver interrupts at the top of spl_any(), and unmask
Ethernet driver interrupts at the bottom of cyg_splx().  This prevents a
DSR from executing while the splx_mutex is owned by another thread. This
solution assumes that the only time a DSR will be delayed by the
scheduler is if the thread that was interrupted had locked the scheduler
for some reason.  The FreeBSD stack threads do not lock the scheduler so
the interrupt mask and mutex acquire operations in spl_any should be
atomic.  Is this a correct assumption to make?  I am worried that a
FreeBSD thread will mask the Ethernet driver interrupts while a DSR is
pending, and then the DSR will preempt the FreeBSD thread causing a race
condition.  If the ECOS scheduler guarantees that a DSR will execute
immediately after its ISR, then this should not be a problem.  Is this
the case?

Thanks,
James Hook



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] RE : [ECOS] possible fix for eth_drv_recv blocking DSR

[Andrew Lunn]

On Wed, Jun 29, 2005 at 12:46:43PM +0200, Arnaud Chataignier wrote:
> James,
> 
> As you had no answer and I know it, I will try to help.
> 
> There should be no DSR in an Ethernet driver device. Your ISR should
> only ask for a DSR call. The DSR is handled in the IO ethernet part, not
> in the device driver.
> 
> The IO ethernet DSR only triggers the execution of the Network alarm
> thread, which then calls your ethernet driver 'deliver' function. Your
> deliver function is thus called from a thread, and there is no interrupt
> lock/unlock to be done in cyg_splx and spl_any.

I think the problem stems from a conflict in the documentation.

packages/io/eth/current/doc/driver_doc says you should be doing it
from the DSR. The sgml documentation says something different and
describes what you say.

The sgml documentation is correct. I will remove the driver_doc which
is now old and wrong.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss