From: Jeremy Hall <jhall@maoz.com>
To: Robert Love <rml@tech9.net>
Cc: Jeremy Hall <jhall@maoz.com>, linux-mm@kvack.org
Subject: Re: interrupt context
Date: Mon, 14 Apr 2003 17:48:07 -0400 (EDT) [thread overview]
Message-ID: <200304142148.h3ELm7HB016432@sith.maoz.com> (raw)
In-Reply-To: <1050355133.3664.73.camel@localhost> from Robert Love at "Apr 14, 2003 05:18:54 pm"
In the new year, Robert Love wrote:
> On Mon, 2003-04-14 at 17:09, Jeremy Hall wrote:
>
> > with 2.5.67-mm2, it is SA_INTERRUPT|SA_SHIRQ and looks like it can call
> > multiple interrupts at once. I am not sure what SA_SHIRQ does, but this
> > does not address the case where one CPU holds an interrupt for one card
> > and the other CPU holds the interrupt for the other card.
>
> SA_SHIRQ means "this interrupt line can be shared" -- thus each handler
> on the line needs to be able to differentiate when it is called whether
> or not its device actually caused the interrupt.
>
oh, ok.
> Note two processors can never run the _same_ handler for the same line.
> A given line (say IRQ 8) is masked out on all processors while its
> handler.
>
ok, but in this case, the same handler appears on two different lines,
once for one RME card, once for the other. It is theoretically possible
that one line could be handled by once CPU and the other by the other CPU.
> Further, if SA_INTERRUPT is specified then all other interrupts are
> disabled, too, on the local processor.
>
It would appear this may not be true, or my understanding of the code is
not sound (more likely) it would also appear rme9652_read might not be
able to differuntiate between being called for an RME card or another
card.
rme9652_read says
return readl(rme9652->iobase+reg);
oh yeah and it says if it can't read, it just returns. I guess it can
tell the difference.
> If you need to protect some data, grab a spin lock in your handler.
>
I'm still digging at this, so don't know yet how to answer this point.
I'm thinking somehow we need to schedule the snd_pcm_period_elapsed, or
force it to run in interrupt context.
I thought I had done the latter by moving the snd_rme9652_write to the
bottom of the function so that it wouldn't clear the interrupt condition
until after it processed the data.
but I guess I hadn't because it didn't make a difference. This is why I
raise the question about whether other interrupts can be called.
_J
> > I moved the line
> >
> > rme9652_write(rme9652, RME9652_irq_clear, 0);
> >
> > to after the snd_pcm_period_elapsed calls in the hopes that they would be
> > run in interrupt context, but it did not make a difference. The backtrace
> > looks a little different, but it's still the same crash.
>
> I am afraid I don't understand nearly enough of the context of the
> problem to know what to suggest next.
>
> Keep hacking :)
>
> Robert Love
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
next prev parent reply other threads:[~2003-04-14 21:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-14 18:51 Jeremy Hall
2003-04-14 18:56 ` Robert Love
2003-04-14 19:32 ` Jeremy Hall
2003-04-14 19:35 ` Robert Love
2003-04-14 21:09 ` Jeremy Hall
2003-04-14 21:18 ` Robert Love
2003-04-14 21:48 ` Jeremy Hall [this message]
2003-04-14 22:57 ` Robert Love
2003-04-15 3:44 ` Jeremy Hall
2003-04-15 4:14 ` Jeremy Hall
2003-04-15 21:40 ` Robert Love
2003-04-15 23:02 ` Jeremy Hall
2003-04-16 3:41 ` Jeremy Hall
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=200304142148.h3ELm7HB016432@sith.maoz.com \
--to=jhall@maoz.com \
--cc=linux-mm@kvack.org \
--cc=rml@tech9.net \
/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