All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jose Luis Marchetti <joseluismarchetti@yahoo.com.br>
To: Robert Hancock <hancockrwd@gmail.com>
Cc: Andreas Mohr <andi@lisas.de>, linux-kernel@vger.kernel.org
Subject: Re: Is interrupt priority supported ?
Date: Sun, 22 Feb 2009 19:17:38 -0800 (PST)	[thread overview]
Message-ID: <260723.67629.qm@web34408.mail.mud.yahoo.com> (raw)
In-Reply-To: <499DFF79.6090404@gmail.com>


> It doesn't really work that way in Linux. Normally
> disabling interrupts is all or nothing. Whether or not other
> devices can cause interrupts during an interrupt handler
> execution by default is a bit platform-dependent, I think
> (unless the driver requests IRQF_DISABLED which requests
> that other interrupts should not run).
> 
> Normally in Ethernet drivers these days only very minimal
> processing is done during the interrupt handler, the rest is
> deferred to softirq context which runs with interrupts
> enabled so other interrupts can happen. That's not to
> say that all Ethernet drivers are so well-behaved, however,
> especially if they haven't been updated to use NAPI. (In
> the NAPI case, the driver disables further interrupts from
> the device until the softirq is able to run and process the
> packets.) In your case it seems likely that yours is not
> behaving so well, as one would expect the interrupt handler
> to complete in less than the time  it takes one character to
> arrive on the serial port..

Interesting, thanks for all the info, I had to research before responding.
It appears network cards was one of the reasons for the softirqs, there is two definitions for network cards in softirqs.
Yes, I looked the DM9000 driver and saw the data being read inside the interrupts so... you are right, that driver was not changed to use softirqs.
I also saw how the IRQF_DISABLED flag works.
I Think using this flag is the way to go for my 4 byte FIFO uart, I would say a 4 byte FIFO is critical enough to be read inside an interrupt.
I know it is kind of strange, the correct way it would be to fix the Ethernet driver and instead of doing that I will not allow any other interrupt inside the uart interrupt, which degrades the system somehow.
What do you think ?
Do you know if the same kind of problem I am having with Ethernet is also seen with USBs ?

Thanks again for all your response.



      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

  reply	other threads:[~2009-02-23  3:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-19 20:24 Is interrupt priority supported ? Jose Luis Marchetti
2009-02-19 20:49 ` Andreas Mohr
2009-02-20  0:33   ` Jose Luis Marchetti
2009-02-20  0:55     ` Robert Hancock
2009-02-23  3:17       ` Jose Luis Marchetti [this message]
2009-02-20  0:26 ` Robert Hancock
2009-02-20  0:36   ` Jose Luis Marchetti

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=260723.67629.qm@web34408.mail.mud.yahoo.com \
    --to=joseluismarchetti@yahoo.com.br \
    --cc=andi@lisas.de \
    --cc=hancockrwd@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.