lkml.org 
[lkml]   [2011]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Sparc-32 doesn't work in 3.1.
    From
    Date
    Le mercredi 14 décembre 2011 à 20:42 +0300, Sergei Trofimovich a écrit :
    > [ CCed Jakub ]
    >
    > >>> Boot time fixup v1.6. 4/Mar/98 Jakub Jelinek (jj@ultra.linux.cz).
    > >>> Patching kernel for srmmu[Fujitsu TurboSparc]/iommu
    > >>> Fixup i f029ddfc doesn't refer to a valid instruction at
    > >>> f00de648[95eea000]
    > >>> halt, power off
    >
    > > I put the broken image up at http://landley.net/sparc-image for the
    > > moment, but if you build 3.1 with the attached .config and the toolchain
    > > mentioned last time, it should reproduce for you. It's 100% reliable
    > > for me...
    >
    > Nice! With this config it breaks for me on your and mine toolchains.
    > The offending function is ext4_kvmalloc (and similar ext4_kvzalloc).
    >
    > The usual relocation in sparc looks like a pair of instructions loading
    > two pats of address in 2 instructions:
    >
    > Like that:
    > > sethi %hi(ext4_fill_super), %o4 !, tmp113
    > > or %o4, %lo(ext4_fill_super), %o4 ! tmp113,, tmp28
    >
    > In our case relocatable symbol sits in tail call, so %lo part is in "unusual"
    > RESTORE instruction:
    >
    > > ext4_kvmalloc:
    > ...
    > > sethi %hi(___i_page_kernel), %i2 !, tmp112
    > > call __vmalloc, 0 !
    > > restore %i2, %lo(___i_page_kernel), %o2 ! tmp112,,
    > ...
    >
    > David: is this code correct? Or it's a compiler bug? I am sparc32 newbie.
    > (C source and asm sources of function are in [1])
    >
    > I think this kind of code is generated only in -Os.
    > So to workaround it I tried this hack:
    >
    > > --- a/fs/ext4/super.c
    > > +++ b/fs/ext4/super.c
    > > ret = kmalloc(size, flags);
    > > if (!ret)
    > > ret = __vmalloc(size, flags, PAGE_KERNEL);
    > > +
    > > + asm __volatile__("nop":::"memory");
    > > +
    > > return ret;
    > > }
    > (for both ext4_kvmalloc / ext4_kvzalloc. Attached workaround as a patch.)
    >
    > It forces compiler to geterate "usual" pattern for relocation.
    >
    > I think of 2 solutions:
    >
    > 1. trying to fix sparc/boot/btfixupprep.c and arch/sparc/mm/btfixup.c
    > to distinct HI22 and LO10 relocations as different ones.
    > Right now they are merged into one 'i' type and rely on instruction heuristics to fix it.
    > 2. Add a hack to arch/sparc/mm/btfixup.c to recognize restore instruction as well
    >
    > Any others?

    3) Adding a memset() in ext4_kvmalloc() and ext4_kvzalloc() to prefault
    pages ?

    4) (Unrelated) : add __GFP_HIGHMEM to __vmalloc() flags, so that high
    memory pages can be used for large allocations.



    --
    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: 2011-12-14 18:53    [W:3.285 / U:0.264 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site