From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
To: Jeff Dike <jdike@addtoit.com>
Cc: Alexander Nyberg <alexn@telia.com>,
Antoine Martin <antoine@nagafix.co.uk>,
linux-kernel@vger.kernel.org
Subject: Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops
Date: Mon, 9 May 2005 22:07:53 +0100 [thread overview]
Message-ID: <20050509210753.GA1150@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <20050508061044.GB32143@parcelfarce.linux.theplanet.co.uk>
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 uml.lds, perhaps?
Apparently solved by adding .tdata and .tbss to uml.lds.S. 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
address.
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...
next prev parent reply other threads:[~2005-05-09 21:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050504191828.620C812EE7@sc8-sf-spam2.sourceforge.net>
[not found] ` <1115248927.12088.52.camel@cobra>
[not found] ` <1115392141.12197.3.camel@cobra>
2005-05-07 16:31 ` Antoine Martin
2005-05-07 15:57 ` Alexander Nyberg
2005-05-07 18:03 ` Jeff Dike
2005-05-08 0:18 ` Al Viro
2005-05-08 6:10 ` Al Viro
2005-05-09 21:07 ` Al Viro [this message]
2005-05-10 2:26 ` Al Viro
2005-05-10 3:50 ` Jeff Dike
2005-05-10 10:02 ` Al Viro
2005-05-08 16:28 ` Jeff Dike
2005-05-07 18:06 ` Antoine Martin
2005-05-08 14:12 ` Andi Kleen
2005-05-08 16:35 ` Antoine Martin
2005-05-08 15:15 ` Andi Kleen
2005-05-08 16:42 ` Jeff Dike
2005-05-08 17:38 ` Antoine Martin
2005-05-08 16:45 ` Jeff Dike
2005-05-08 19:51 ` Antoine Martin
2005-05-08 16:38 ` Jeff Dike
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050509210753.GA1150@parcelfarce.linux.theplanet.co.uk \
--to=viro@parcelfarce.linux.theplanet.co.uk \
--cc=alexn@telia.com \
--cc=antoine@nagafix.co.uk \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome