From: "Mark A. Greer" <mgreer@mvista.com>
To: "Curtis, Allen" <Allen.Curtis@Thales-IFS.com>
Cc: "'linuxppc-embedded@lists.linuxppc.org'"
<linuxppc-embedded@lists.linuxppc.org>
Subject: Re: 64260/PCI accesses cached by CPU?
Date: Fri, 16 May 2003 16:17:06 -0700 [thread overview]
Message-ID: <3EC57172.9060504@mvista.com> (raw)
In-Reply-To: <FA06AA2C99BCD511951200005A99441001E3F17F@irvexch1.sextantifs.com>
Allen,
I just sent essentially the same reply to a private email you sent me
but since you posted here too, I'll also answer here.
If PCI I/O or MEM space was being cached, your PCI drivers wouldn't work
at all...or at least not for very long. I also mentioned that the
GT64260 is very slow when cache coherency is enabled. What you
described here sounds like either an interrupt problem--which you've
apparently investigated--or is symptomatic of how the GT64260 handles
cache snooping. I don't know what your problem is but I think your "PCI
I/O and/or MEM being cached" theory is wrong. My $0.02.
Also, PCI mem space is mapped by the driver. That's why you don't see
it mapped by any of the gt64260-specific code.
Mark
--
Curtis, Allen wrote:
>I am using the Artesyn PM/PPC750F PMC in conjunction with a Ramix 100BT quad
>Ethernet PMC module. When the system has *low* load, the performance of the
>Ethernet ports on the second module is *very* slow. (will not complete `ttcp
>-t 10.10.1.1 -s`) If the system is heavily loaded, in this case generating
>lots of SCSI disk activity, the same ports have very high performance.
>
>Note:
>1. SCSI is also a PCI peripheral
>2. The Ethernet ports on the processor are fine
>
>At first I thought this was a hardware, IRQ line, problem but I see the same
>behavior on Ethernet ports which do not share interrupt lines. (did not see
>anything funny with a scope either)
>
>I have come to the conclusion that the processor is caching either the PCI
>I/O or memory access operations. Originally I thought the problem must have
>been PCI memory access. I can see from gt64260_find_bridges() the I/O space
>is going through ioremap(). However I do not see any such mapping for PCI
>memory operations. (nothing in <platform>_setup.c) However after review of
>mptbase.c, which works, and pcnet32.c, which is slow, it appears the problem
>is reverse.
>
>Linux kernel version:
>linux-pmppc750f-prerelease_1_1 (from linux_2_4_galileo)
>
>same results using:
>linuxppc_2_4_devel - 2.4.21pre5
>
>Ideas? Suggestions?
>
>Thanks
>
>
>
>
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2003-05-16 23:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-16 21:48 64260/PCI accesses cached by CPU? Curtis, Allen
2003-05-16 23:17 ` Mark A. Greer [this message]
2003-05-17 4:06 ` Allen Curtis
2003-05-19 19:24 ` Mark A. Greer
-- strict thread matches above, loose matches on Subject: below --
2003-05-19 19:36 Johnson, Stephen
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=3EC57172.9060504@mvista.com \
--to=mgreer@mvista.com \
--cc=Allen.Curtis@Thales-IFS.com \
--cc=linuxppc-embedded@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 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.