public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Arnaud Chataignier" <achataignier@neotion.com>
To: "'Hook, James'" <jhook@bloomberg.com>, <ecos-discuss@sources.redhat.com>
Subject: [ECOS] RE : [ECOS] possible fix for eth_drv_recv blocking DSR
Date: Wed, 29 Jun 2005 10:47:00 -0000	[thread overview]
Message-ID: <01ce01c57c97$d6d275b0$0100a8c0@ArnaudC> (raw)
In-Reply-To: 

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

             reply	other threads:[~2005-06-29 10:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-29 10:47 Arnaud Chataignier [this message]
2005-06-29 11:13 ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='01ce01c57c97$d6d275b0$0100a8c0@ArnaudC' \
    --to=achataignier@neotion.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=jhook@bloomberg.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).