lkml.org 
[lkml]   [2003]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this
    On Mon, Sep 01, 2003 at 11:12:24AM +0100, Jamie Lokier wrote:
    > Russell King wrote:
    > > This looks like an old kernel on your NetWinder. Later 2.4 kernels
    > > should get this right (by marking the pages uncacheable in user space.)
    >
    > How do they know which pages to mark uncacheable? Surely not all
    > MAP_SHARED|MAP_FIXED mappings are uncacheable?

    By looking at the mappings present in the process. If a process maps the
    same file using MAP_SHARED _and_ we fault the same page of data into two
    or more mappings, we turn off the cache for those pages.

    We actually only turn off the cache and leave the write buffer (aka your
    store buffer) turned on for these regions, which should be sufficient for
    it to remain coherent between different virtual addresses.

    I've been doing some further investigation, and I'm now of the opinion
    that "SA110" StrongARM chips have buggy write buffers, because:

    - if I turn off the cache, leaving the write buffer on, this program
    works on StrongARM-1110 CPUs but not some StrongARM-110 CPUs.
    - if I turn off the cache and write buffer on these twice-mapped pages,
    StrongARM-110 behaves as expected.

    I've tested on several silicon revisions of StrongARM-110's:
    - H appears buggy (reports as rev. 2)
    - K appears fine (reports as rev. 2)
    - S appears buggy (reports as rev. 3)

    Unfortunately, the written documentation makes zero mention of the exact
    write buffer behaviour. The best that I have to go on for the
    StrongARM-110 is a block diagram which indicates that the write buffer
    uses physical addresses, and that the D-cache contains the physical
    address which the line was fetched from for writeback (via the write
    buffer.)

    So it seems your test program finds problems which DaveM's aliastest
    program fails to detect... Gah. ;(

    I guess its time to devise a kernel test and alter our behaviour on ARM
    accordingly.

    --
    Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
    http://www.arm.linux.org.uk/personal/aboutme.html

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:48    [W:0.022 / U:116.720 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site