[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [rtl] cacheflush and RTLinux/QNX - problem found soon to be sloved
Thanks to all that aided and helped. The problem was found to be with the
hardware and PCI burst accesses. If the accesses were performed ~12usec
apart the system worked fine. Still determining problem with burst mode
access. Cahcing was not a concern, it was "mapped" as io non-cached space
:| (oh well).
Thanks again for your help.
Bob
At 08:42 AM 8/3/99 -0400, Robert Warner wrote:
>The shared memory interface and status indication should be defined as
>volatile space.
>
>
>
>> > Is it possible that the data that is suppose to be in the shared memory
>is
>> > actually in cached memory? I know the cacheflush() command would help
>me
>> > in RTLinux, but what about QNX? Any other ideas?
>>
>> I guess it is possible that the data is cached. To prove this you could
>use
>
>Yes. It is possible, that "ioremap" Linux call also disables the cache for
>the remapped memory.
>
>Then there is no need for flushing.
>Search the linux-kernel and RTL mailing lists.
>
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
echo "unsubscribe rtl <Your_email>" | mail majordomo@rtlinux.cs.nmt.edu
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/