[lkml]   [2005]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: + UML/x86_64 (2.6.12-rc3+) = oops
    On Sun, May 08, 2005 at 07:10:44AM +0100, Al Viro wrote:
    > r) when built static, kernel dies ugly death with
    > #0 0x00000000601e4178 in ptmalloc_init () at swab.h:134
    > #1 0x00000000601e4034 in malloc_hook_ini () at swab.h:134
    > #2 0x00000000601e1698 in malloc () at swab.h:134
    > #3 0x00000000602068ee in _dl_init_paths () at swab.h:134
    > #4 0x00000000601eba45 in _dl_non_dynamic_init () at swab.h:134
    > #5 0x00000000601ebc60 in __libc_init_first () at swab.h:134
    > #6 0x00000000601cfa4f in __libc_start_main () at swab.h:134
    > #7 0x000000006001202a in _start () at proc_fs.h:183
    > as stack trace. Buggered offsets in, perhaps?

    Apparently solved by adding .tdata and .tbss to That change does
    not give any visible regression on i386.

    s) i386 TT-only won't compile, due to mispaced include in
    sysdep/ptrace.h (under ifdef for skas). Trivial fix apparently gets it
    to work correctly. Which is surprising - when running that sucker on
    amd64 we get zero from
    *host_size_out = ROUND_4M((unsigned long) &arg);
    Of course, the real size rounded up to 4M is 4Gb there - 32bit tasks do not
    have to share the lower 4Gb of address space with the kernel. Looks like
    we survive, though - it boots and apparently works both on i386 and (as
    32bit process) on amd64.
    t) amd64 TT-only builds just fine, but gets buggered due to
    mismatch between CONFIG_TOP_ADDR and start address - we get *both* set
    to 0x60000000, which is obviously b0rken and doesn't match the old
    code, while we are at it. We want TOP_ADDR at 0x80000000 to match start
    u) amd64 TT is _still_ buggered due to unmap_fin.o attempts at
    magic. errno sits in TLS for amd64, so unmap_fin.o gets very interesting
    stuff leaking from libc and messing the link. IMO that should be dealt
    with by brute force; namely, unmap-$(SUBARCH).S instead of trying to
    play games with pulling stuff from libc.a. For fsck sake, we are just
    making 3 syscalls there and switcheroo() is as low-level as it gets...
    Will post once that's done...
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-05-09 23:12    [W:0.020 / U:1.420 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site