[lkml]   [2010]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectCommit 085219f79cad broke Sparc-32 back in 2.6.28.
    On Saturday 20 February 2010 17:12:22 Rob Landley wrote:
    > On Saturday 20 February 2010 15:59:31 Blue Swirl wrote:
    > > > I've got 2.6.32 booting to a command prompt (albeit with serial console
    > > > and intentionall restricted set of hardware). But then it misbehaves.
    > > >
    > > > I'll try getting 2.6.18 to build with a known .config, and then bisect
    > > > forward if that seems to work...
    > >
    > > Good plan. Bisecting backwards could be interesting too, to find out
    > > which releases are actually working out of the box.
    > I started by iterating through the release versions. It's working up
    > through 2.6.28, then 2.6.29 has the out of memory error in my init script.
    > Bisecting now...
    > Rob

    And the commit that broke it bisects to:

    085219f79cad89291699bd2bfb21c9fdabafe65f is first bad commit
    commit 085219f79cad89291699bd2bfb21c9fdabafe65f
    Author: Sam Ravnborg <>
    Date: Fri Jan 2 18:47:34 2009 -0800

    sparc32: use proper types in struct stat

    Like sparc64 use proper types in struct stat

    Signed-off-by: Sam Ravnborg <>
    Signed-off-by: David S. Miller <>

    This commit breaks stat and makes sparc32 essentially unusable. It changes
    the size of the various types in stat.h, and means that if you "mount -t tmpfs
    /tmp /tmp" and then try to ls /tmp, ls dies with a memory allocation error.

    I've confirmed that reverting it fixes the problem.

    Looking at the actual diff, here's the hunk that causes problems:

    --- a/arch/sparc/include/asm/stat_32.h
    +++ b/arch/sparc/include/asm/stat_32.h
    short st_nlink;
    - unsigned short st_uid;
    - unsigned short st_gid;
    + uid_t st_uid;
    + gid_t st_gid;

    The symptom (in my uClibc+busybox root filesystem) is:

    / # mount -t tmpfs /tmp /tmp
    / # ls -l /tmp
    ls: can't open '/tmp': Cannot allocate memory
    total 0

    The problem is that both uid_t and gid_t are "int" instead of "short". This
    patch changes the size of those types. (I note that this is apparently a
    known issue, there's __compat_uid_t and friends in the sparc asm directory...)

    Latency is more important than throughput. It's that simple. - Linus Torvalds

     \ /
      Last update: 2010-02-21 17:39    [W:0.023 / U:2.468 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site