From: ashish anand <ashisha@india•infogain.com>
To: David Ashley <dash@xdr•com>, linuxppc-embedded@lists•linuxppc.org
Subject: Re: 8260 + cache/dma issues
Date: Wed, 26 Dec 2001 07:28:43 +0530 [thread overview]
Message-ID: <3C292ED3.38B6A810@india.infogain.com> (raw)
In-Reply-To: 200112260427.fBQ4Rvi00224@dave.home
though i haven't dealt with 8260 specific cache consistency protocol and all , but feel using
pci_alloc_consistent may be cause.
also snooping should be clearly understood whether it is presenting a consistent view
between cpu and devices or diffeent cpu in a smp setup.
David Ashley wrote:
>
> I'm running into repeated problems related to cache problems on
> ppc 8260 based hardware. The kernel is based on Montevista's 2.4.2.
> The same problem keeps coming up again and again. Here it is:
>
> If some external device, such as the pci usb device, writes into system
> ram, the 8260 doesn't get the changes--instead when the 8260 reads the
> ram it uses the data in the cache, defeating the whole purpose. We're
> using the usb-ohci.c driver. In order to get it to work I've had to hack
> the driver to instead of using pci_alloc_consistent, allocate memory
> out of a section of local bus ram, which is non-cacheable. The burden
> of doing this for every driver is just too great.
>
> The original driver itself assumes that the dma works properly, meaning it
> does nothing to invalidate the cache or cause a refresh/flush/update or
> whatever. The driver initiates a transfer, the usb writes into ram, an
> interrupt occurs, the driver examines the buffer--and crashes and generally
> doesn't work because the data it sees isn't in ram, it is what was in the
> cache.
>
> My belief is there is something misconfigured on the hardware level. Meaning
> the cache should work properly. In studying the 8260 docs I read hints at
> snooping, but no details. My understanding is that snooping is when the
> 8260 watches the bus to see what activity there is, and if there is a write
> to something the 8260 holds in a cache, the cache is updated accordingly.
> Perhaps this snooping is turned off?
>
> Also there is talk of C + R bits in the page tables (C = changed, R =
> referenced). Possibly is the external dma mechanism supposed to update the
> C + R bits in the page tables itself, causing the 8260 to realize something
> has been done to the page and so it needs to be updated?
>
> The driver doesn't ask for any special non-cacheable memory, just dma
> capable. Following this through in the code that means in the case of
> the ppc, all of dram because there is no limit on the dma range. On the
> i386 tree dma appears limited to the first 16 megabytes. But nothing appears
> to be demanding non-cacheable memory.
>
> I guess I have several questions:
> 1) How is the system supposed to work so that the cpu and other pci devices
> have the same concept of the contents of memory?
> 2) What is missing in our system that is causing this not to work?
> 3) What is snooping, and can it be turned on or off by the 8260, or is it
> fixed in the hardware?
> 4) Am I misunderstanding how the linux drivers where, such that when they
> allocate memory for dma transfers, it is automatically marked as
> non-cacheable?
> 5) While I'm at it, I'm getting lock ups related to the external pci device
> writing into dram. I've heard mention of cache deadlocks, but I don't know
> details. Any pointers to documentation will be helpful.
>
> Thanks very much for any ideas/advice.
>
> -Dave
> dash@xdr•com
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-12-26 1:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-26 4:27 8260 + cache/dma issues David Ashley
2001-12-26 1:58 ` ashish anand [this message]
2001-12-26 19:53 ` Wolfgang Denk
-- strict thread matches above, loose matches on Subject: below --
2001-12-26 21:25 David Ashley
2001-12-28 3:17 David Ashley
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=3C292ED3.38B6A810@india.infogain.com \
--to=ashisha@india$(echo .)infogain.com \
--cc=dash@xdr$(echo .)com \
--cc=linuxppc-embedded@lists$(echo .)linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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