From: Benjamin Herrenschmidt <bh40@calva.net>
To: linuxppc-dev@lists.linuxppc.org, Paul.Mackerras@cs.anu.edu.au
Subject: Re: Strange PMAC IDE performance problem
Date: Thu, 7 Jan 1999 10:11:37 +0100 [thread overview]
Message-ID: <19990107101137.025655@smtp.calvacom.fr> (raw)
In-Reply-To: <199901062322.KAA00858@tango.anu.edu.au>
On Thu, Jan 7, 1999, Paul Mackerras <paulus@cs.anu.edu.au> wrote:
>It's usually the instruction that reenables interrupts globally, after
>we have disabled the particular interrupt we are servicing. I think
>what happens is this: we write to the interrupt controller enable
>register to disable the interrupt. This write percolates through the
>PCI bridge down into the gc/ohare/heathrow/whatever chip, and some
>time later that chip will negate the interrupt request signal
>(assuming there are no other enabled interrupts). In the meantime the
>CPU has been proceeding from the write to the instruction where it
>reenables interrupts (by putting a new value in the MSR). If the CPU
>gets there first, you can get a bogus interrupt.
>
>I put in a sync instruction after the write to make the cpu wait at
>least until the pci bridge has acknowledged the write. That helps on
>many machines but isn't sufficient on some. Reading a register in the
>interrupt controller should help, especially if there was an eieio
>between the read and the write. (The eieio goes out onto the system
>bus and should therefore be seen by the PCI host bridge. Whether the
>bridge honors it by not allowing subsequent reads to bypass previous
>writes is another question. :-)
I discussed this with Cort not so long ago, since in theory, the write to
the ack register could still be in the bridge when you re-enable EE,
regardless of the sync (posted writes are always handled async by the
bridge, and I don't see why sync would sync anything with the PCI bridge,
at least not with an ordinary bridge but maybe Grackle has some
PPC-specific features here). I suggest adding a read from the controller
(with it's eieio) anyway. This will ensure that all bridges on the path
to the interrupt controller have been flushed (at least according to PCI
standard). A bridge that allow a read to bypass a previous write is
definitely a broken bridge (do you know one ?)
--
E-Mail: <mailto:bh40@calva.net>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]
next prev parent reply other threads:[~1999-01-07 9:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-01-05 8:52 Strange PMAC IDE performance problem Timothy A. Seufert
1999-01-05 11:33 ` Albrecht Dreß
1999-01-05 17:52 ` Marcus H. Mendenhall
1999-01-05 18:49 ` Timothy A. Seufert
1999-01-05 22:48 ` Benjamin Herrenschmidt
1999-01-06 5:56 ` Dan Malek
1999-01-06 9:59 ` Benjamin Herrenschmidt
1999-01-06 9:23 ` Albrecht Dreß
1999-01-06 10:02 ` Benjamin Herrenschmidt
1999-01-06 23:22 ` Paul Mackerras
1999-01-07 9:11 ` Benjamin Herrenschmidt [this message]
1999-01-05 22:39 ` Paul Mackerras
1999-01-06 6:01 ` Paul Mackerras
1999-01-06 11:51 ` Benjamin Herrenschmidt
1999-01-06 16:02 ` Great IDE perf (WAS: Strange PMAC IDE performance) Benjamin Herrenschmidt
1999-01-07 11:12 ` Timothy A. Seufert
1999-01-07 11:32 ` Paul Mackerras
1999-01-07 18:59 ` Timothy A. Seufert
1999-01-07 11:59 ` Benjamin Herrenschmidt
1999-01-07 18:59 ` Timothy A. Seufert
1999-01-07 20:15 ` Benjamin Herrenschmidt
1999-01-08 2:06 ` Paul Mackerras
1999-01-08 3:30 ` Benjamin Herrenschmidt
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=19990107101137.025655@smtp.calvacom.fr \
--to=bh40@calva.net \
--cc=Paul.Mackerras@cs.anu.edu.au \
--cc=linuxppc-dev@lists.linuxppc.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 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 NNTP newsgroup(s).