Messages in this thread | | | Date | Sun, 8 May 2005 01:18:32 +0100 | From | Al Viro <> | Subject | Re: 2.6.11.8 + UML/x86_64 (2.6.12-rc3+) = oops |
| |
On Sat, May 07, 2005 at 02:03:56PM -0400, Jeff Dike wrote: > On Sat, May 07, 2005 at 05:57:48PM +0200, Alexander Nyberg wrote: > > I never get uml to compile around here, 2.6.12-rc3 + that patchkit from > > the link you sent blows up with defconfig any my minimal config. Please > > attach your guest .config and if you can you might aswell put your guest > > vmlinux somewhere where i can download it too. > > Start with -rc3, and all the patches from > http://user-mode-linux.sf.net/patches.html > up to and including skas0. You'll see a note to x86_64 users on that patch.
Hrm... a) stub.S handling breaks on O= builds. Actually, your unprofile breaks there - it's bypassing the machinery that deals with include path. b) stub_segv.c on amd64 includes <signal.h>. Not a good idea... c) sysdep-x86_64/checksum.h in -rc4 has csum_partial_copy_from_user() that needs updating (AFAICS, you have that in your patchset, but it hadn't reached Linus) d) ip_compute_csum() prototype is missing (same file) e) #define UPT_SYSCALL_RET(r) UPT_RAX(r) is needed in amd64 ptrace.h f) take a good look at UPT_SET() in the same file ;-) g) CFLAGS_csum-partial.o := -Dcsum_partial=arch_csum_partial in sys-x86_64/Makefile needs to be removed. h) Makefile.rules should be included _after_ SYMLINKS = in the same file. i) sys-x86_64/delay.c needs exports of __udelay() and __const_udelay(), include of linux/module.h and barriers in your delay loop bodies (or games with volatile - anything that would guarantee that gcc won't decide to optimize the entire loop away). The last part applies to i386 as well. j) ip_compute_csum should be exported on amd64. k) sys-x86_64/syscalls.c needs include "kern.h" l) elf-i386.h should include <asm/user.h>, not "user.h" m) elf-x86_64.h lacks R_X86_64_... definitions n) WTF _is_ that #ifdef TIF_IA32 in there? Aside of the trailing \, we could as well put #error there - free-floating clear_thread_flag(TIF_IA32); outside of any function body will have that effect anyway. o) in drivers/chan_kern.c we have several printf(KERN_ERR "..."); these should become printk, as they clearly had been intended. As it is, they give instant panic if we ever call them. p) TOP_ADDR in Kconfig_x86_64 got lost in transmission - your patchset has it, but same patch in Linus' tree does not.
I've got patches for everything except (a); that one is really nasty. I hope to sort it out by tonight; if not, I'll just send what I've got by now. - 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/
| |