Menu
▾
▴
user-mode-linux-devel
|
From: Jeff D. <jd...@ad...> - 2004-01-13 04:44:36
|
This patch updates UML to 2.6.0 and pulls in all the changes that have accumulated in my 2.4 tree. The 2.6.0 UML patch is available at http://www.user-mode-linux.org/mirror/uml-patch-2.6.0-1.bz2 BK users can pull my 2.5 repository from http://www.user-mode-linux.org:5000/uml-2.5 For the other UML mirrors and other downloads, see http://user-mode-linux.sourceforge.net/dl-sf.html Other links of interest: The UML project home page : http://user-mode-linux.sourceforge.net The UML Community site : http://usermodelinux.org Jeff |
|
From: Jeff D. <jd...@ad...> - 2004-01-13 04:57:29
|
> This patch updates UML to 2.6.0 and pulls in all the changes that have > accumulated in my 2.4 tree. I forgot to mention that newer libcs won't boot on 2.6 UMLs until I get [gs]et_thread_area implemented. Older libcs are fine, as are new libcs on 2.4 UMLs. Jeff |
|
From: <sko...@up...> - 2004-01-13 10:30:39
|
> The 2.6.0 UML patch is available at > http://www.user-mode-linux.org/mirror/uml-patch-2.6.0-1.bz2 i get this error: gcc -Wl,-T,arch/um/uml.lds.s -static -Wl,--wrap,malloc -Wl,--wrap,free -Wl,--wra p,calloc \ -o linux arch/um/main.o vmlinux -L/usr/lib -lutil vmlinux(.text+0x5288): In function `mem_init': : undefined reference to `phys_page' vmlinux(.init.text+0x21f3): In function `kmap_init': : undefined reference to `pte_offset' collect2: ld returned 1 exit status i applied this patch to clean 2.6.0 sources from kernel.org. if you need more information just ask. i'm running gentoo 1.4 with a 2.6.1 host kernel. linux 2.4.19 headers are installed in /usr/include, just in case it matters. |
|
From: Gerd K. <kr...@by...> - 2004-01-13 19:05:07
|
Sven K=C3=B6hler <sko...@up...> writes: > > The 2.6.0 UML patch is available at > > http://www.user-mode-linux.org/mirror/uml-patch-2.6.0-1.bz2 >=20 > gcc -Wl,-T,arch/um/uml.lds.s -static -Wl,--wrap,malloc -Wl,--wrap,free > -Wl,--wra > p,calloc \ > -o linux arch/um/main.o vmlinux -L/usr/lib -lutil > vmlinux(.text+0x5288): In function `mem_init': > : undefined reference to `phys_page' > vmlinux(.init.text+0x21f3): In function `kmap_init': > : undefined reference to `pte_offset' > collect2: ld returned 1 exit status Disable CONFIG_HIGHMEM, then it does build. I have a few more questions: * what is the status of kernel modules in 2.6 kernels? It doesn't build without patching the kernel: One issue is some elf relocation defines being missing (R_386_32, R_386_PC32), making apply_relocate() fail to build. The other issue is apply_alternatives() not being defined, making the final link fail. Trying to fix that, booting and trying to load modules leads to kernel panic. * Any known issues with 2.6.1 kernels? Tried to apply the 2.6.0 patch to 2.6.1 and fixup the one reject in arch/um/kernel/irq.c manually and the fs/proc/task_mmu.c build failure with a patch fished from this list. But the resulting kernel fails to boot up the system. I see the init start banner, then it stops. Looking whats up with gdb shows that the fork syscall seems to hang in a endless loop, pagefaulting at the same address over and over ... Gerd --=20 You have a new virus in /var/mail/kraxel |
|
From: Jeff D. <jd...@ad...> - 2004-01-16 02:12:23
|
kr...@by... said: > * what is the status of kernel modules in 2.6 kernels? They still don't work. I still haven't got around to fixing it. > * Any known issues with 2.6.1 kernels? Fewer, now that I got the 2.6.1 patch out. UML lacks [gs]et_thread_area still, so 2.6 UMLs won't boot new libcs. Jeff |
|
From: M A Y. <m.a...@du...> - 2004-01-16 10:03:26
|
On Thu, 15 Jan 2004, Jeff Dike wrote: > kr...@by... said: > > * what is the status of kernel modules in 2.6 kernels? > > They still don't work. I still haven't got around to fixing it. But see the patches at http://web.tiscali.it/no-redirect-tiscali/blaisorblade/ > > * Any known issues with 2.6.1 kernels? > > Fewer, now that I got the 2.6.1 patch out. UML lacks [gs]et_thread_area > still, so 2.6 UMLs won't boot new libcs. Actually, I am no longer convinced the lack of these syscalls cause the problem directly; I think there is something else in recent glibcs that cause the kernel to hang, at least in tt mode, though it is probably related. Michael Young |
|
From: Gerd K. <kr...@by...> - 2004-01-16 12:00:14
|
On Fri, Jan 16, 2004 at 10:03:11AM +0000, M A Young wrote: > On Thu, 15 Jan 2004, Jeff Dike wrote: > > > They still don't work. I still haven't got around to fixing it. > > But see the patches at > http://web.tiscali.it/no-redirect-tiscali/blaisorblade/ At last picking just the module fixes patch doesn't work for me, it doesn't apply. There are probably some nasty patch dependencies. > > > * Any known issues with 2.6.1 kernels? > > > > Fewer, now that I got the 2.6.1 patch out. UML lacks [gs]et_thread_area > > still, so 2.6 UMLs won't boot new libcs. Great, building now ... Gerd -- You have a new virus in /var/mail/kraxel |
|
From: BlaisorBlade <bla...@ya...> - 2004-01-17 16:09:07
|
Alle 12:42, venerd=EC 16 gennaio 2004, Gerd Knorr ha scritto: > On Fri, Jan 16, 2004 at 10:03:11AM +0000, M A Young wrote: > > On Thu, 15 Jan 2004, Jeff Dike wrote: > > > They still don't work. I still haven't got around to fixing it. > > > > But see the patches at > > http://web.tiscali.it/no-redirect-tiscali/blaisorblade/ > > At last picking just the module fixes patch doesn't work for me, it > doesn't apply. There are probably some nasty patch dependencies. IIRC there's no dependency by that patch onto others; however that patch wa= s=20 onto old -test9 Jeff Dike's release, and there are some easy thing to fix (= I=20 hope to update everything today). Bye =2D-=20 cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.23/2.6.0 on an i686; Linux registered user n. 292729 EOSIGN |
|
From: Jeff D. <jd...@ad...> - 2004-01-16 17:06:04
|
m.a...@du... said: > Actually, I am no longer convinced the lack of these syscalls cause > the problem directly; I think there is something else in recent glibcs > that cause the kernel to hang, at least in tt mode, though it is > probably related. Maybe, but it's a definite problem. However, the segfaults people were seeing with 2.6.1 may be gone since that was a separate problem which is fixed in the 2.6.1 patch. Jeff |
|
From: Gerd K. <kr...@by...> - 2004-01-16 22:10:10
|
On Fri, Jan 16, 2004 at 12:27:20PM -0500, Jeff Dike wrote:
> m.a...@du... said:
> > Actually, I am no longer convinced the lack of these syscalls cause
> > the problem directly; I think there is something else in recent glibcs
> > that cause the kernel to hang, at least in tt mode, though it is
> > probably related.
>
> Maybe, but it's a definite problem. However, the segfaults people were seeing
> with 2.6.1 may be gone since that was a separate problem which is fixed in
> the 2.6.1 patch.
The segfaults are gone for me, 2.6.1 with the new uml patch boots just fine.
Gerd
PS: I've just pushed fresh-built kernel rpms, they should find their way
to ftp.suse.com + mirrors (/pub/people/kraxel) next hours.
--
"... und auch das ganze Wochenende oll" -- Wetterbericht auf RadioEins
|
|
From: M A Y. <m.a...@du...> - 2004-01-17 21:12:56
|
On Fri, 16 Jan 2004, Jeff Dike wrote: > m.a...@du... said: > > Actually, I am no longer convinced the lack of these syscalls cause > > the problem directly; I think there is something else in recent glibcs > > that cause the kernel to hang, at least in tt mode, though it is > > probably related. > > Maybe, but it's a definite problem. However, the segfaults people were seeing > with 2.6.1 may be gone since that was a separate problem which is fixed in > the 2.6.1 patch. I have been trying to debug the problem with tt mode and very recent glibcs, and what seems to be happening is that early on in the glibc start up code for /sbin/init (after 3 syscalls), there is a segv signal; handle_page_fault returns -14, probably becuase the fault address (beffe018) is bogus, but the segfault seems to repeat endlessly. I am not sure if this is a glibc or a uml issue, or something else. Michael Young |
|
From: Jeff D. <jd...@ad...> - 2004-01-18 04:26:10
|
On Sat, Jan 17, 2004 at 09:12:45PM +0000, M A Young wrote: > I have been trying to debug the problem with tt mode and very recent > glibcs, and what seems to be happening is that early on in the glibc start > up code for /sbin/init (after 3 syscalls), there is a segv signal; > handle_page_fault returns -14, probably becuase the fault address > (beffe018) is bogus, but the segfault seems to repeat endlessly. I am not > sure if this is a glibc or a uml issue, or something else. I saw something like that during a glibc upgrade going from stable to testing in tt mode. Running it in skas mode avoided the problem. I never figured out what was happening. Jeff |
|
From: <sko...@up...> - 2004-01-16 23:49:05
|
> Fewer, now that I got the 2.6.1 patch out. UML lacks [gs]et_thread_area > still, so 2.6 UMLs won't boot new libcs. What do you mean new libcs? Is there any particular version-number you can confirm to work/not work? What about NPTL? Thx Sven |
|
From: Ingo M. <mi...@el...> - 2004-01-18 16:20:45
|
* Jeff Dike <jd...@ad...> wrote: > > * Any known issues with 2.6.1 kernels? > > Fewer, now that I got the 2.6.1 patch out. UML lacks > [gs]et_thread_area still, so 2.6 UMLs won't boot new libcs. hm, are you sure this is the reason why they dont boot? At least the ones in Fedora fall back to LinuxThreads if set_thread_area is -ENOSYS. Old 2.4 kernels work just fine - UML ought to work fine too. (libcs built without compatibility wont fall back. Are there such distros?) Ingo |
|
From: Ingo M. <mi...@el...> - 2004-01-18 21:05:29
|
i've attached a few makefile simplifications/cleanups below, against your 2.6.1 UML tree. The UML build will be less verbose as well. parallel make still does not work though - doing 'make -j10' after a 'make clean' fails. Couldnt figure out a solution, the dependencies are really nasty. Ingo --- linux/arch/um/sys-i386/util/Makefile.orig2 +++ linux/arch/um/sys-i386/util/Makefile @@ -1,12 +1,9 @@ -host-progs := mk_sc -always := $(host-progs) mk_thread -targets := mk_thread_kern.o mk_thread_user.o +host-progs := mk_sc mk_thread +always := $(host-progs) -mk_sc-objs := mk_sc.o +mk_thread-objs := mk_thread_kern.o mk_thread_user.o -$(obj)/mk_thread : $(obj)/mk_thread_kern.o $(obj)/mk_thread_user.o - $(HOSTCC) $(CFLAGS) -o $@ $^ +HOSTCFLAGS_mk_thread_kern.o := $(CFLAGS) +HOSTCFLAGS_mk_thread_user.o := $(USER_CFLAGS) -$(obj)/mk_thread_user.o : $(src)/mk_thread_user.c - $(HOSTCC) $(USER_CFLAGS) -c -o $@ $< --- linux/arch/um/util/Makefile.orig2 +++ linux/arch/um/util/Makefile @@ -1,18 +1,10 @@ -always := mk_task mk_constants -targets := mk_task_user.o mk_task_kern.o \ - mk_constants_user.o mk_constants_kern.o -$(obj)/mk_task: $(obj)/mk_task_user.o $(obj)/mk_task_kern.o - $(HOSTCC) -o $@ $^ +host-progs := mk_task mk_constants +always := $(host-progs) -$(obj)/mk_task_user.o: $(src)/mk_task_user.c - $(HOSTCC) -o $@ -c $< +mk_task-objs := mk_task_user.o mk_task_kern.o +mk_constants-objs := mk_constants_user.o mk_constants_kern.o -$(obj)/mk_constants : $(obj)/mk_constants_user.o $(obj)/mk_constants_kern.o - $(HOSTCC) -o $@ $^ +HOSTCFLAGS_mk_task_kern.o := $(CFLAGS) +HOSTCFLAGS_mk_constants_kern.o := $(CFLAGS) -$(obj)/mk_constants_user.o : $(src)/mk_constants_user.c - $(HOSTCC) -c $< -o $@ - -$(obj)/mk_constants_kern.o : $(src)/mk_constants_kern.c - $(HOSTCC) $(CFLAGS) -c $< -o $@ --- linux/arch/um/Makefile.orig2 +++ linux/arch/um/Makefile @@ -157,7 +157,8 @@ MRPROPER_FILES += $(SYMLINK_HEADERS) $(A $(addprefix $(ARCH_DIR)/kernel/,$(KERN_SYMLINKS)) $(ARCH_DIR)/main.o: $(ARCH_DIR)/main.c sys_prepare - $(CC) $(USER_CFLAGS) $(EXTRA_CFLAGS) -c -o $@ $< + @ echo ' MAIN $@' + @ $(CC) $(USER_CFLAGS) $(EXTRA_CFLAGS) -c -o $@ $< archmrproper: @: @@ -169,13 +170,12 @@ archmrproper: # $(addprefix $(ARCH_DIR)/kernel/,$(KERN_SYMLINKS)) archclean: -# $(Q)for d in $(ARCH_SUBDIRS) $(ARCH_DIR)/util; \ -# do \ -# $(MAKE) $(clean)=$$d; \ -# done + $(Q)for d in $(ARCH_SUBDIRS) $(ARCH_DIR)/util; \ + do \ + $(MAKE) $(clean)=$$d; \ + done @find . \( -name '*.bb' -o -name '*.bbg' -o -name '*.da' \ -o -name '*.gcov' \) -type f -print | xargs rm -f -# rm -f $(CLEAN_FILES) $(SYMLINK_HEADERS): cd $(TOPDIR)/$(dir $@) ; \ |
|
From: Jeff D. <jd...@ad...> - 2004-01-18 23:46:07
|
On Sun, Jan 18, 2004 at 10:06:05PM +0100, Ingo Molnar wrote: > > i've attached a few makefile simplifications/cleanups below, against > your 2.6.1 UML tree. The UML build will be less verbose as well. Cool. > parallel make still does not work though - doing 'make -j10' after a > 'make clean' fails. Couldnt figure out a solution, the dependencies are > really nasty. Yeah, it's a mess. It has sort of evolved over time, with local fixes adding up to a horror show. Jeff |
|
From: Ingo M. <mi...@el...> - 2004-01-19 07:33:19
|
* Jeff Dike <jd...@ad...> wrote:
> > parallel make still does not work though - doing 'make -j10' after a
> > 'make clean' fails. Couldnt figure out a solution, the dependencies are
> > really nasty.
>
> Yeah, it's a mess. It has sort of evolved over time, with local fixes
> adding up to a horror show.
i think kbuild needs to be improved too in some cases. Eg. another
problem: lib-y could be used to clean up munmap_fin.o library linking in
arch/um/kernel/tt/Makefile, but unlike host-progs, the CFLAGS_ override
is not good enough to replace the normal flags with $(UNMAP_CFLAGS). The
dual compilation space ('user code' and 'kernel code' compilation)
within UML is not yet fully expressable via kbuild.
Ingo
|
|
From: Jeff D. <jd...@ad...> - 2004-01-20 17:18:26
|
mi...@el... said:
> The dual compilation space ('user code' and 'kernel code' compilation)
> within UML is not yet fully expressable via kbuild.
In my opinion, it doesn't need to be. BlaisorBlade and I have been having
an argument about it.
He thinks kbuild should support it.
I consider it to be an artifact of UML containing intermingled OS-dependent
and OS-independent code. With the OS-dependent code separated out into
arch/um/os, the rest of UML becomes nice, normal kernel code. The stuff
under arch/um/os is then pure userspace code, and I have no problem with
sticking some special CFLAGS mangler in the Makefile (or Makefiles) there.
Then, the code, and the special make magic that it needs are all in one
place, and we don't need to fiddle kbuild.
Jeff
|
|
From: Jeff D. <jd...@ad...> - 2004-01-18 23:36:45
|
On Sun, Jan 18, 2004 at 05:21:12PM +0100, Ingo Molnar wrote: > hm, are you sure this is the reason why they dont boot? At least the > ones in Fedora fall back to LinuxThreads if set_thread_area is -ENOSYS. > Old 2.4 kernels work just fine - UML ought to work fine too. No, I'm not. But I am seeing -ENOSYS from one of [gs]et_thread_area right before things go haywire. But I haven't looked at it closely enough to see if that's the real problem. 2.4 UMLs work fine with these libcs. I had been assuming (without any evidence) that there was some other capability check (like uname), and libc gets horribly confused when it sees a 2.6 kernel that doesn't have the thread_info stuff. If the compatibility check is -ENOSYS from one of those syscalls, then this theory goes right out the window, and something else is wrong in UML. Jeff |
|
From: Ingo M. <mi...@el...> - 2004-01-19 07:53:17
|
* Jeff Dike <jd...@ad...> wrote:
> 2.4 UMLs work fine with these libcs. I had been assuming (without any
> evidence) that there was some other capability check (like uname), and
> libc gets horribly confused when it sees a 2.6 kernel that doesn't
> have the thread_info stuff.
ok, i talked to Ulrich, and it turns out that ld.so in Fedora uses the
set_tid_address() syscall to find out whether the kernel has NPTL or not
[and thus whether to use the TLS glibc or the standard one]. In UML,
this particular syscall happens to work. So i'd suggest the patch below.
(i'll test it soon.) Once the TLS syscalls are available in UML this
syscall can be turned back on.
Ingo
--- linux/arch/um/kernel/sys_call_table.c.orig
+++ linux/arch/um/kernel/sys_call_table.c
@@ -521,7 +521,7 @@ syscall_handler_t *sys_call_table[] = {
[ __NR_epoll_ctl ] = sys_epoll_ctl,
[ __NR_epoll_wait ] = sys_epoll_wait,
[ __NR_old_remap_file_pages ] = old_remap_file_pages,
- [ __NR_set_tid_address ] = sys_set_tid_address,
+ [ __NR_set_tid_address ] = sys_ni_syscall,
[ __NR_timer_create ] = sys_timer_create,
[ __NR_timer_settime ] = sys_timer_settime,
[ __NR_timer_gettime ] = sys_timer_gettime,
|
|
From: Ingo M. <mi...@el...> - 2004-01-19 08:27:41
|
* Ingo Molnar <mi...@el...> wrote: > > 2.4 UMLs work fine with these libcs. I had been assuming (without any > > evidence) that there was some other capability check (like uname), and > > libc gets horribly confused when it sees a 2.6 kernel that doesn't > > have the thread_info stuff. > > ok, i talked to Ulrich, and it turns out that ld.so in Fedora uses the > set_tid_address() syscall to find out whether the kernel has NPTL or > not [and thus whether to use the TLS glibc or the standard one]. [...] unfortunately, this is only the case if the kernel is below 2.5.69 and has 'nptl' in the uname. Otherwise ld.so assumes full NPTL support. so the only compatible solution seems to be to implement set/get_thread_area() within UML. Since UML itself is linked statically, which causes the non-TLS glibc to be linked, i think it should be safe to just shadow the TLS descriptors in the UML process and call set_thread_area() for every new thread that has TLS descriptors not equal to the previous thread's TLS descriptors. but wrt. LinuxThreads - it doesnt seem UML skas mode implements LDT state properly - does it? Ingo |
|
From: M A Y. <m.a...@du...> - 2004-01-20 00:20:00
|
On Mon, 19 Jan 2004, Ingo Molnar wrote: > > * Ingo Molnar <mi...@el...> wrote: > > > > 2.4 UMLs work fine with these libcs. I had been assuming (without any > > > evidence) that there was some other capability check (like uname), and > > > libc gets horribly confused when it sees a 2.6 kernel that doesn't > > > have the thread_info stuff. > > > > ok, i talked to Ulrich, and it turns out that ld.so in Fedora uses the > > set_tid_address() syscall to find out whether the kernel has NPTL or > > not [and thus whether to use the TLS glibc or the standard one]. [...] > > unfortunately, this is only the case if the kernel is below 2.5.69 and > has 'nptl' in the uname. Otherwise ld.so assumes full NPTL support. > > so the only compatible solution seems to be to implement > set/get_thread_area() within UML. Since UML itself is linked statically, > which causes the non-TLS glibc to be linked, i think it should be safe > to just shadow the TLS descriptors in the UML process and call > set_thread_area() for every new thread that has TLS descriptors not > equal to the previous thread's TLS descriptors. I have found in tt mode with an FC1 image the system hangs after 3 syscalls (uname, brk, open), before any set/get_thread_area calls, so I suspect there is another problem. The hang consists of repeated segfault signals with fault address (beffe018) which returns -EFAULT. Is there any setup for tls/nptl normally done by the kernel that might be missing in UML, such as allocating some high up memory? Michael Young |
|
From: Ingo M. <mi...@el...> - 2004-01-20 00:22:26
|
* M A Young <m.a...@du...> wrote: > I have found in tt mode with an FC1 image the system hangs after 3 > syscalls (uname, brk, open), before any set/get_thread_area calls, so > I suspect there is another problem. The hang consists of repeated > segfault signals with fault address (beffe018) which returns -EFAULT. > Is there any setup for tls/nptl normally done by the kernel that might > be missing in UML, such as allocating some high up memory? hm, beffe018 - shouldnt that be the stack? Ingo |
|
From: M A Y. <m.a...@du...> - 2004-01-20 00:42:11
|
On Tue, 20 Jan 2004, Ingo Molnar wrote: > > * M A Young <m.a...@du...> wrote: > > > I have found in tt mode with an FC1 image the system hangs after 3 > > syscalls (uname, brk, open), before any set/get_thread_area calls, so > > I suspect there is another problem. The hang consists of repeated > > segfault signals with fault address (beffe018) which returns -EFAULT. > > Is there any setup for tls/nptl normally done by the kernel that might > > be missing in UML, such as allocating some high up memory? > > hm, beffe018 - shouldnt that be the stack? /proc/????/maps showed one region in this area, but it was higher up. Interestingly if I try this with a RedHat 9 glibc with tls, the address it hangs on is very low (0x000000c3 from memory). Michael Young |
|
From: M A Y. <m.a...@du...> - 2004-01-26 05:59:18
|
On Tue, 20 Jan 2004, Ingo Molnar wrote:
>
> * M A Young <m.a...@du...> wrote:
>
> > I have found in tt mode with an FC1 image the system hangs after 3
> > syscalls (uname, brk, open), before any set/get_thread_area calls, so
> > I suspect there is another problem. The hang consists of repeated
> > segfault signals with fault address (beffe018) which returns -EFAULT.
> > Is there any setup for tls/nptl normally done by the kernel that might
> > be missing in UML, such as allocating some high up memory?
>
> hm, beffe018 - shouldnt that be the stack?
I now know where 0xbeffe018 comes from. The endless segfault is triggered
from line 1256 of elf/rtld.c in the glibc code (1252-1258 are shown from
RedHat's glibc-2.3.2-101.4.i686.rpm package)
#ifdef NEED_DL_SYSINFO
if (GL(dl_sysinfo_dso) != NULL)
{
/* We have a prelinked DSO preloaded by the system. */
GL(dl_sysinfo) = GL(dl_sysinfo_dso)->e_entry;
/* Do an abridged version of the work _dl_map_object_from_fd would do
GL(dl_sysinfo_dso) is _dl_sysinfo_dso, _rtld_local._dl_sysinfo_dso or
_rtld_global._dl_sysinfo_dso according to context
_dl_sysinfo_dso=0 is at 0xa0603f50
_rtld_local._dl_sysinfo_dso=0xbeffe000 is at 0x40015454
_rtld_global._dl_sysinfo_dso=0xbeffe000 is at 0x40015454
so I am guessing that _rtld_{local,global}._dl_sysinfo_dso should have
been initialized from _dl_sysinfo_dso but wasn't. This could be a glibc
bug, though I haven't looked closely enough to be sure.
Michael Young
|
Thanks for helping keep SourceForge clean.
X