From: Bernhard S. <lin...@ac...> - 2005-06-23 11:58:26
|
Hi all! I've a nice issue with UML: after making UML with the following commands make ARCH=um mrproper make ARCH=um defconfig make ARCH=um linux I executed the resulting ./linux. After 3 lines it returns: [...]$ ./linux Checking for /proc/mm...not found Checking PROT_EXEC mmap in /tmp...OK tracing thread pid = 11264 [...]$ I then performed a strace with the following result: execve("./linux", ["./linux"], [/* 36 vars */]) = 0 uname({sys="Linux", node="FC3-bernhard-1.acousta.local", ...}) = 0 brk(0) = 0xa02eb000 brk(0xa030c000) = 0xa030c000 rt_sigprocmask(SIG_SETMASK, [IO], NULL, 8) = 0 execve("./linux", ["./linux", " "...], [/* 36 vars */]) = 0 uname({sys="Linux", node="FC3-bernhard-1.acousta.local", ...}) = 0 brk(0) = 0xa02eb000 brk(0xa030c000) = 0xa030c000 rt_sigprocmask(SIG_SETMASK, [IO], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0 setrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 rt_sigaction(SIGINT, {0xa000e7bc, [], SA_RESTORER|SA_NOMASK|SA_ONESHOT, 0xa016c5f8}, NULL, 8) = 0 rt_sigaction(SIGTERM, {0xa000e7bc, [], SA_RESTORER|SA_NOMASK|SA_ONESHOT, 0xa016c5f8}, NULL, 8) = 0 rt_sigaction(SIGHUP, {0xa000e7bc, [], SA_RESTORER|SA_NOMASK|SA_ONESHOT, 0xa016c5f8}, NULL, 8) = 0 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fff000 access("/proc/mm", W_OK) = -1 ENOENT (No such file or directory) write(1, "Checking for /proc/mm...not foun"..., 34Checking for /proc/mm...not found ) = 34 gettimeofday({1119518796, 218023}, NULL) = 0 getpid() = 11034 open("/tmp/vm_file-8pMAxo", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 unlink("/tmp/vm_file-8pMAxo") = 0 fchmod(3, 0777) = 0 _llseek(3, 4096, [4096], SEEK_SET) = 0 write(3, "\0", 1) = 1 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb7ffe000 write(1, "Checking PROT_EXEC mmap in /tmp."..., 34Checking PROT_EXEC mmap in /tmp...) = 34 write(1, "OK\n", 3OK ) = 3 munmap(0xb7ffe000, 4096) = 0 close(3) = 0 gettimeofday({1119518796, 251449}, NULL) = 0 getpid() = 11034 open("/tmp/vm_file-cPfdkF", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 unlink("/tmp/vm_file-cPfdkF") = 0 fchmod(3, 0777) = 0 _llseek(3, 507904, [507904], SEEK_SET) = 0 write(3, "\0", 1) = 1 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 old_mmap(NULL, 507904, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xb7f83000 munmap(0xa01b6000, 507904) = 0 mmap2(0xa01b6000, 507904, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED| MAP_FIXED, 3, 0) = 0xa01b6000 munmap(0xb7f83000, 507904) = 0 gettimeofday({1119518796, 274075}, NULL) = 0 getpid() = 11034 open("/tmp/vm_file-QOcE3Z", O_RDWR|O_CREAT|O_EXCL, 0600) = 4 unlink("/tmp/vm_file-QOcE3Z") = 0 fchmod(4, 0777) = 0 _llseek(4, 757760, [757760], SEEK_SET) = 0 write(4, "\0", 1) = 1 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 old_mmap(NULL, 757760, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xb7f46000 munmap(0xa0232000, 757760) = 0 mmap2(0xa0232000, 757760, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED| MAP_FIXED, 4, 0) = 0xa0232000 munmap(0xb7f46000, 757760) = 0 uname({sys="Linux", node="FC3-bernhard-1.acousta.local", ...}) = 0 gettimeofday({1119518796, 308258}, NULL) = 0 getpid() = 11034 open("/tmp/vm_file-Wqsikn", O_RDWR|O_CREAT|O_EXCL, 0600) = 5 unlink("/tmp/vm_file-Wqsikn") = 0 fchmod(5, 0777) = 0 _llseek(5, 33554432, [33554432], SEEK_SET) = 0 write(5, "\0", 1) = 1 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 mmap2(0xa0800000, 25165824, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 5, 0x800) = 0xa0800000 mkdir("/home/bernhard/.uml/", 0777) = -1 EEXIST (File exists) gettimeofday({1119518796, 328354}, NULL) = 0 getpid() = 11034 open("/home/bernhard/.uml/0hMoWL", O_RDWR|O_CREAT|O_EXCL, 0600) = 6 close(6) = 0 unlink("/home/bernhard/.uml/0hMoWL") = 0 mkdir("/home/bernhard/.uml/0hMoWL", 0777) = 0 open("/home/bernhard/.uml/0hMoWL/pid", O_RDWR|O_CREAT|O_EXCL| O_LARGEFILE, 0644) = 6 getpid() = 11034 write(6, "11034\n", 6) = 6 close(6) = 0 mprotect(0xa01fe000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0 socketpair(PF_FILE, SOCK_STREAM, 0, [6, 7]) = 0 fcntl64(6, F_SETFD, FD_CLOEXEC) = 0 fcntl64(7, F_SETFD, FD_CLOEXEC) = 0 rt_sigaction(SIGWINCH, {0xa0017394, [WINCH], SA_RESTORER|SA_RESTART, 0xa016c5f8}, {SIG_DFL}, 8) = 0 getpid() = 11034 write(1, "tracing thread pid = 11034\n", 27tracing thread pid = 11034 ) = 27 clone(child_stack=0xa01fffd4, flags=CLONE_FILES|SIGCHLD) = 11035 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(11035, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSTOP}], WSTOPPED) = 11035 ptrace(0x15 /* PTRACE_??? */, 11035, 0, 0x1) = 0 ptrace(PTRACE_CONT, 11035, 0, SIG_0) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- rt_sigaction(SIGSEGV, {0xa00174dc, [SEGV], SA_RESTORER|SA_RESTART, 0xa016c5f8}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGUSR1, {0xa0015fac, [USR1], SA_RESTORER|SA_RESTART, 0xa016c5f8}, {SIG_DFL}, 8) = 0 waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGUSR1}], WSTOPPED) = 11035 mmap2(0xa030c000, 5193728, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 5, 0x30c) = 0xa030c000 ptrace(PTRACE_CONT, 11035, 0, SIG_0) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 --- SIGCHLD (Child exited) @ 0 (0) --- ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 --- SIGCHLD (Child exited) @ 0 (0) --- ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGVTALRM}], WSTOPPED) = 11035 --- SIGCHLD (Child exited) @ 0 (0) --- ptrace(PTRACE_CONT, 11035, 0, SIGVTALRM) = 0 waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}], WSTOPPED) = 11035 --- SIGCHLD (Child exited) @ 0 (0) --- ptrace(PTRACE_CONT, 11035, 0, SIGSEGV) = 0 waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGUSR1}], WSTOPPED) = 11035 --- SIGCHLD (Child exited) @ 0 (0) --- ptrace(PTRACE_CONT, 11035, 0, SIG_0) = 0 waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}], WSTOPPED) = 11035 --- SIGCHLD (Child exited) @ 0 (0) --- ptrace(PTRACE_CONT, 11035, 0, SIGSEGV) = 0 waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGUSR1}], WSTOPPED) = 11035 --- SIGCHLD (Child exited) @ 0 (0) --- munmap(0xa030c000, 0) = -1 EINVAL (Invalid argument) kill(11035, SIGKILL) = 0 ptrace(PTRACE_KILL, 11035, 0xbffff328, 0xa000ec42) = 0 Segmentation fault As UML kernel I use a plain 2.6.12 kernel from kernel.org; The host system runs on Fedora Core 3 updated to the current Version. Yesterday I tried several source Versions since 2.6.11 cause 1 week or two ago the UML kernel (2.6.12-rc4) could be compiled and run fine. But now it do not run - irrelevant which Kernel I use. GCC : 3.4.3 20050227 Host Kernel: 2.6.11-1.27_FC3smp I do not have any Idea what happens here: absolutely not. Does anyone know in this list? Thanks in advance Bernhard Schauer |
From: Bernhard S. <lin...@ac...> - 2005-06-24 07:23:49
|
Has anyone a hint on that issue? I do not even know where I should search for that! regards |
From: Blaisorblade <bla...@ya...> - 2005-06-24 09:30:51
|
On Thursday 23 June 2005 13:58, Bernhard Schauer wrote: > Hi all! > > I've a nice issue with UML: > after making UML with the following commands > make ARCH=um mrproper > make ARCH=um defconfig > make ARCH=um linux > I executed the resulting ./linux. After 3 lines it returns: > > [...]$ ./linux > Checking for /proc/mm...not found > Checking PROT_EXEC mmap in /tmp...OK > tracing thread pid = 11264 > [...]$ Well, add stderr=1 to see the output. It will complain that you're not saying him which Linux root_fs you want to boot. If you pass a filesystem and it does not work, then post the new output with stderr=1. > Segmentation fault > As UML kernel I use a plain 2.6.12 kernel from kernel.org; > The host system runs on Fedora Core 3 updated to the current Version. > > Yesterday I tried several source Versions since 2.6.11 cause 1 week or > two ago the UML kernel (2.6.12-rc4) could be compiled and run fine. > But now it do not run - irrelevant which Kernel I use. > > GCC : 3.4.3 20050227 > Host Kernel: 2.6.11-1.27_FC3smp > > I do not have any Idea what happens here: absolutely not. Does anyone > know in this list? -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Bernhard S. <lin...@ac...> - 2005-06-24 12:02:18
|
> Well, add stderr=1 to see the output. It will complain that you're not > saying him which Linux root_fs you want to boot. > If you pass a filesystem and it does not work, then post the new > output with stderr=1. [...]$ ./linux stderr=1 ubd0=/mnt/lfs/lfs1.img Checking PROT_EXEC mmap in /tmp...OK tracing thread pid = 6098 Linux version 2.6.12-mm1-um-bs2 (root@FC3-bernhard-1.acousta.local) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)) #3 Thu Jun 23 09:11:38 CEST 2005 Built 1 zonelists Kernel command line: stderr=1 ubd0=/mnt/lfs/lfs1.img root=98:0 PID hash table entries: 256 (order: 8, 4096 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 29000k available Mount-cache hash table entries: 512 Checking for host processor cmov support...Yes Checking for host processor xmm support...No Checking that ptrace can change system call numbers...<0>Kernel panic - not syncing: Segfault with no mm EIP: 0073:[<00000000>] CPU: 0 Not tainted ESP: 007b:a01f7f40 EFLAGS: 00010207 Not tainted EAX: 000017d4 EBX: 00000000 ECX: a01f7e00 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 007b ES: 007b a01f7a30: [<a0029328>] show_regs+0xdc/0xfc a01f7a50: [<a001762f>] panic_exit+0x27/0x48 a01f7a70: [<a003c0a6>] notifier_call_chain+0x1e/0x3c a01f7aa0: [<a002d87e>] panic+0x56/0x104 a01f7ac0: [<a0016c52>] segv+0x21a/0x258 a01f7ba0: [<a0016f45>] segv_handler+0xc5/0xd0 a01f7be0: [<a001a122>] sig_handler_common_tt+0xe6/0x13c a01f7c40: [<a002600a>] sig_handler+0x12/0x14 a01f7c60: [<a0161fe8>] __restore+0x0/0x8 [...] It's the same output as if i do not pass ubd0. |
From: Jeff D. <jd...@ad...> - 2005-06-24 13:58:20
|
On Fri, Jun 24, 2005 at 02:02:24PM +0200, Bernhard Schauer wrote: > Checking for host processor xmm support...No > Checking that ptrace can change system call numbers...<0>Kernel panic - > not syncing: Segfault with no mm Revert the fork-not-clone patch: http://www.ussg.iu.edu/hypermail/linux/kernel/0506.1/0665.html The patch isn't wrong exactly - as far as I can see, the compiler is compiling it slightly differently so that it hits the tt mode vs new libc errno incompatibility. Jeff |
From: Bernhard S. <lin...@ac...> - 2005-06-27 09:11:30
|
> Revert the fork-not-clone patch: > http://www.ussg.iu.edu/hypermail/linux/kernel/0506.1/0665.html > Tried to revert the patch, but it did not succeed from 2.6.12 (Woozy Numbat). Maybe I should revert an other patch before (An other solution would be to put the changes in by hand....)? Following output: [...]$ patch -RNp1 -i ../UML_fork-instead_of_clone_patch patching file arch/um/kernel/process.c Hunk #1 succeeded at 130 with fuzz 2. Hunk #2 FAILED at 159. Hunk #3 FAILED at 180. Hunk #4 FAILED at 188. Hunk #5 FAILED at 204. Hunk #6 FAILED at 234. Hunk #7 FAILED at 257. Hunk #8 FAILED at 265. Hunk #9 FAILED at 290. Hunk #10 FAILED at 301. Hunk #11 FAILED at 339. Hunk #12 FAILED at 371. Hunk #13 FAILED at 390. 12 out of 13 hunks FAILED -- saving rejects to file arch/um/kernel/process.c.rej [...] Trying again 2.6.12.rc4 ... PS: I do not know how long it takes that I send my mails as reply to all... Sorry. |
From: Bernhard S. <lin...@ac...> - 2005-06-27 09:39:28
|
> Trying again 2.6.12.rc4 ... O.k. 2.6.12-rc4-mm2 with deleted include/asm-um/elf.h and hand edited arch/um/include/user.h (commented out kfree, in_aton and strlcpy) the resulting ./linux works as expected ;-)! Now I'm more relaxed (searching for that nearly a week!) ... best regards Bernhard Schauer |
From: Blaisorblade <bla...@ya...> - 2005-06-27 16:18:38
|
On Monday 27 June 2005 11:11, Bernhard Schauer wrote: > > Revert the fork-not-clone patch: > > http://www.ussg.iu.edu/hypermail/linux/kernel/0506.1/0665.html > > Tried to revert the patch, but it did not succeed from 2.6.12 (Woozy > Numbat). That patch is not in 2.6.12, it was in the -mm tree you were using, as seen from the output: > Linux version 2.6.12-mm1-um-bs2 (root@FC3-bernhard-1.acousta.local) (gcc > version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)) #3 Thu Jun 23 09:11:38 > CEST 2005 Have you had problems with plain 2.6.12? > Trying again 2.6.12.rc4 ... > PS: I do not know how long it takes that I send my mails as reply to > all... Sorry. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Bernhard S. <lin...@ac...> - 2005-06-28 08:47:11
|
> Have you had problems with plain 2.6.12? I tried 2.6.12, 2.6.12-mm1 and several others. With 2.6.12 plain, I've reproduced ( - unpacking plain 2.6.11 kernel, - patching to 2.6.12, - make O=../../../build/lin-uml/ ARCH=um defconfig - make O=../../../build/lin-uml/ ARCH=um linux - executing ../../../build/lin-uml/linux stderr=1 - executing ../../../build/lin-uml/linux stderr=1 \ ubd0=/mnt/lfs/lfs.img - Both times the same Error ) it again. Following output: Checking for /proc/mm...not found Checking PROT_EXEC mmap in /tmp...OK tracing thread pid = 10942 Linux version 2.6.12 (bernhard@FC3-bernhard-1.acousta.local) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22 .fc3)) #1 Tue Jun 28 10:36:41 CEST 2005 Built 1 zonelists Kernel command line: stderr=1 root=98:0 PID hash table entries: 256 (order: 8, 4096 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 29056k available Mount-cache hash table entries: 512 Checking for host processor cmov support...Yes Checking for host processor xmm support...No Checking that ptrace can change system call numbers...<0>Kernel panic - not syncing: Segfault with no mm EIP: 0073:[<00000000>] CPU: 0 Not tainted ESP: 007b:a01f3f60 EFLAGS: 00210207 Not tainted EAX: 00002ac0 EBX: 00000000 ECX: a01f3e20 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 007b ES: 007b a01f3a40: [<a002a52f>] show_regs+0x1db/0x1ec a01f3a70: [<a001512b>] panic_exit+0x27/0x48 a01f3a90: [<a003f0b2>] notifier_call_chain+0x1e/0x3c a01f3ac0: [<a002e68a>] panic+0x56/0x104 a01f3ae0: [<a00145ea>] segv+0x21a/0x258 a01f3bc0: [<a0014958>] segv_handler+0x11c/0x198 a01f3c00: [<a0017c82>] sig_handler_common_tt+0xe6/0x13c a01f3c60: [<a0025d7b>] sig_handler+0x1f/0x38 a01f3c80: [<a015fe88>] __restore+0x0/0x8 regards |
From: Peter B. <buz...@gm...> - 2005-06-28 16:11:55
|
Hello, I have the same problem with 2.6.12.1 Kernel. Almost exact the same output... With 2.6.11.12 Kernel everything works... Peter 2005/6/28, Bernhard Schauer <lin...@ac...>: > > Have you had problems with plain 2.6.12? >=20 > I tried 2.6.12, 2.6.12-mm1 and several others. With 2.6.12 plain, I've > reproduced |
From: Bernhard S. <lin...@ac...> - 2005-06-29 06:37:51
|
> I have the same problem with 2.6.12.1 Kernel. Almost exact the same > output... With 2.6.11.12 Kernel everything works... Could you please try 2.6.12-rc4-mm2? I'll try to reproduce your issue with 2.6.11.12. If that behaviour is reproducible (on my and your computer), I'll try to check which changes are the reason for that "bug". regards PS: I'm sorry, I forgot to use send all with my last mail... |
From: Peter B. <buz...@gm...> - 2005-06-29 14:52:39
|
Just tried it with 2.6.13-rc1. Same error... > Could you please try 2.6.12-rc4-mm2? I'll try to reproduce your issue > with 2.6.11.12. |
From: Bernhard S. <lin...@ac...> - 2005-06-29 15:11:56
|
> Could you please try 2.6.12-rc4-mm2? I'll try to reproduce your issue > with 2.6.11.12. Table: 2.6.11.12 works as expected 2.6.12-rc4 works as expected 2.6.12-rc4-mm2 works as expected 2.6.12-rc5 works as expected 2.6.12-rc6 works as expected 2.6.12 does not work |
From: Blaisorblade <bla...@ya...> - 2005-06-29 17:52:20
|
On Wednesday 29 June 2005 17:12, Bernhard Schauer wrote: > > Could you please try 2.6.12-rc4-mm2? I'll try to reproduce your issue > > with 2.6.11.12. > > Table: > 2.6.11.12 works as expected > 2.6.12-rc4 works as expected > 2.6.12-rc4-mm2 works as expected > 2.6.12-rc5 works as expected > 2.6.12-rc6 works as expected > 2.6.12 does not work Ok, there are only a few patches to consider at that point: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=98fdffccea6cc3fe9dba32c0fcc310bcb5d71529 (the one indicated by Jeff, it should unapply well I guess, maybe at the old URL it was ruined). http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=da00d9a5466558ccd9e7b7d04b13d7cb9160c876 http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=501cb02b431fb88c7f157c46c8b54de59d1dd463 (plus a couple trivial other ones, which I wouldn't consider as possible culprits). When I get the time I'll start investigating on this... -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Blaisorblade <bla...@ya...> - 2005-07-01 22:46:15
Attachments:
uml-revert-fork-instead-of-clone.patch
|
On Wednesday 29 June 2005 19:57, Blaisorblade wrote: > On Wednesday 29 June 2005 17:12, Bernhard Schauer wrote: > > > Could you please try 2.6.12-rc4-mm2? I'll try to reproduce your issue > > > with 2.6.11.12. > > > > Table: > > 2.6.11.12 works as expected > > 2.6.12-rc4 works as expected > > 2.6.12-rc4-mm2 works as expected > > 2.6.12-rc5 works as expected > > 2.6.12-rc6 works as expected > > 2.6.12 does not work > > Ok, there are only a few patches to consider at that point: > > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=comm >it;h=98fdffccea6cc3fe9dba32c0fcc310bcb5d71529 (the one indicated by Jeff, it > should unapply well I guess, maybe at the old URL it was ruined). > (plus a couple trivial other ones, which I wouldn't consider as possible > culprits). Ok, confirmed that the patch indicated by Jeff is the exact culprit one and that it applies. I took the patch from there with git and reversed it, so apply the attached patch to fix this problem. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade |
From: Bernhard S. <lin...@ac...> - 2005-07-04 06:45:55
|
> Ok, confirmed that the patch indicated by Jeff is the exact culprit one and > that it applies. I took the patch from there with git and reversed it, so > apply the attached patch to fix this problem. Confirmed too. Everything works as expected now. Thanks! best regards Bernhard Schauer |
From: Blaisorblade <bla...@ya...> - 2005-07-04 16:28:48
|
On Monday 04 July 2005 08:46, Bernhard Schauer wrote: > > Ok, confirmed that the patch indicated by Jeff is the exact culprit one > > and that it applies. I took the patch from there with git and reversed > > it, so apply the attached patch to fix this problem. > > Confirmed too. Everything works as expected now. > Thanks! Ok, now I'm going to include the fix within 2.6.12-bs1. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.beta.messenger.yahoo.com |
From: Blaisorblade <bla...@ya...> - 2005-07-04 16:47:20
|
On Friday 24 June 2005 15:41, Jeff Dike wrote: > On Fri, Jun 24, 2005 at 02:02:24PM +0200, Bernhard Schauer wrote: > > Checking for host processor xmm support...No > > Checking that ptrace can change system call numbers...<0>Kernel panic - > > not syncing: Segfault with no mm > > Revert the fork-not-clone patch: > http://www.ussg.iu.edu/hypermail/linux/kernel/0506.1/0665.html > > The patch isn't wrong exactly - as far as I can see, the compiler is > compiling it slightly differently so that it hits the tt mode vs new libc > errno incompatibility. Ok, can you describe it a bit more detailedly? Also, are you going to drop this patch (or allow me to do this) for now? Since it isn't getting fixed, it seems me a good idea. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Jeff D. <jd...@ad...> - 2005-07-07 13:51:17
|
> Ok, can you describe it a bit more detailedly? > > Also, are you going to drop this patch (or allow me to do this) for now? > Since it isn't getting fixed, it seems me a good idea. I still think the patch is correct. Ben LaHaise sent me a UML binary which crashes, which I can send you if you want to look at it. This thing was looking at errno after the first call to fork even if it succeeded. This leads me to believe that this is a compiler oddity rather than a compiler bug, and that this is causing UML to hit the tt-specific errno crash with recent libcs. You understand that problem more than I do. So, I would say that skas0 is more a fix for this problem than reverting the fork-not-clone patch is. Jeff |
From: Bernhard S. <lin...@ac...> - 2005-07-11 07:48:26
|
On Thu, 2005-07-07 at 07:59 -0400, Jeff Dike wrote: > So, I would say that skas0 is more a fix for this problem than > reverting the fork-not-clone patch is. No it isn't. Its an other method not a fix for anything. As long as skas0 is not in kernel mainline and enabled in main distributions, it has no relevance for corporate level (at least in my case). UML gives us the chance to build a compile and debug environment without a relevance on which distribution it runs. The image used to boot UML is a copy for each developer and each of them could compile applications having the same environment as on the target system. |
From: Blaisorblade <bla...@ya...> - 2005-07-07 18:25:18
|
(Oleg, this is about your problem, and there are some questions for you too, marked with ////////////////////////////, please ACK me about this message). On Thursday 07 July 2005 13:59, Jeff Dike wrote: > > Ok, can you describe it a bit more detailedly? > > Also, are you going to drop this patch (or allow me to do this) for now? > > Since it isn't getting fixed, it seems me a good idea. > I still think the patch is correct. ... > So, I would say that skas0 is more a fix for this problem than > reverting the fork-not-clone patch is. For the question above, and from the "stability" point of view, this does not matter, even because this patch is not a bug-fix (Valgrind users can apply it manually). > Ben LaHaise sent me a UML binary > which crashes, which I can send you if you want to look at it. Ok, thanks. > This thing was looking at errno after the first call to fork even if > it succeeded. Were you debugging it? Was it using the "errno" variable or calling, as it should have done with normal glibc's, __errno_location()? > This leads me to believe that this is a compiler oddity > rather than a compiler bug, and that this is causing UML to hit the > tt-specific errno crash with recent libcs. Mmh, I've read "[uml-user] UML at Fedora Core 4 in TT mode: something wrong with errno." from Oleg, and it describes the problem well: errno remains forever at 0. But the return values are not altered, in that case, i.e. failure is failure and success is success, just errno is not updated. > You understand that > problem more than I do. Ok, I've never seen it on my own, but I guess I understand it anyway. The problem is that: a) .thread_private is ignored by NPTL b) so, while for UML (or at least parts of it) the errno is at one place, for the libraries (which are already linked) the real, thread-specific (TLS) value of errno is used... and using clone()/fork() interferes with this. I guess that in NPTL headers, instead of using __errno_location() the faster "__thread int errno;" is used; Oleg, can you verify this? //////////////////////////////////////////////////////////////////////////////////////////////////////////////// > So, I would say that skas0 is more a fix for this problem than > reverting the fork-not-clone patch is. Wait a moment, the "errno" problem is fixable and currently it should be fixed, for what I can see, the patch is in -rc1... though I have problems with this, which could stem from a SYSEMU bug (see other thread "Please test 2.6.13-rc2 in TT mode!"): is it possible that after calling mmap2(), the value stored in EBX (i.e. the first syscall param) is altered? In fact, this is what seems to happen inside switcheroo() to the "to" param, leading to the routine errouneously failing. This does not happen anywhere else in the UML kernel, it seems. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.beta.messenger.yahoo.com |
From: Oleg G. <ol...@in...> - 2005-07-08 11:33:54
|
On Thursday 07 July 2005 21:31, Blaisorblade wrote: > I guess that in NPTL headers, instead of using __errno_location() the > faster "__thread int errno;" is used; Oleg, can you verify this? This is excerpt of <bits/errno.h> include file, which is included from <errno.h> on Fedora Core 4: [-- Begin of Excerpt --] # ifndef __ASSEMBLER__ /* Function to get address of global `errno' variable. */ extern int *__errno_location (void) __THROW __attribute__ ((__const__)); # if !defined _LIBC || defined _LIBC_REENTRANT /* When using threads, errno is a per-thread value. */ # define errno (*__errno_location ()) # endif # endif /* !__ASSEMBLER__ */ [-- End of Excerpt --] Compiling a test program with "-E" switch shows that preprocessor replaces "errno" with "(*__errno_location ())". There are several definitions of __errno_location() function inside glibc sources, but they are inside "#ifdef"s, so I can't tell which of them is effective in glibc-2.3.5-10 RPM package used in Fedora Core 4. -- Oleg Girko, http://www.infoserver.ru/~ol/ |
From: Blaisorblade <bla...@ya...> - 2005-07-09 10:11:44
|
On Friday 08 July 2005 13:33, Oleg Girko wrote: > On Thursday 07 July 2005 21:31, Blaisorblade wrote: > > I guess that in NPTL headers, instead of using __errno_location() the > > faster "__thread int errno;" is used; Oleg, can you verify this? > > This is excerpt of <bits/errno.h> include file, which is included from > <errno.h> on Fedora Core 4: > > [-- Begin of Excerpt --] > # ifndef __ASSEMBLER__ > /* Function to get address of global `errno' variable. */ > extern int *__errno_location (void) __THROW __attribute__ ((__const__)); > > # if !defined _LIBC || defined _LIBC_REENTRANT > /* When using threads, errno is a per-thread value. */ > # define errno (*__errno_location ()) > # endif > # endif /* !__ASSEMBLER__ */ > [-- End of Excerpt --] > Compiling a test program with "-E" switch shows that preprocessor replaces > "errno" with "(*__errno_location ())". Can you test on a UML file? Non urgent since my patch fixed it, but it would still be useful. (do a make ARCH=um V=1 to take the right command line, or even do make ARCH=um arch/um/<afile>.i and it will do everything by itself). Some file should be using kernel_errno and that's ok, the ones with _user.c (and the ones listed in USER_OBJS in their Makefile) should get the above def. Hmm, that's more logical but now I'm left a bit without explaination. However the existance of two "errno" is enough to confuse it somehow, probably. And since you reported the fix works, we're ok. > There are several definitions of __errno_location() function inside glibc > sources, but they are inside "#ifdef"s, so I can't tell which of them is > effective in glibc-2.3.5-10 RPM package used in Fedora Core 4. Don't worry, I've studied the question time ago on older glibc with NPTL and I've got a good understanding of that. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Oleg G. <ol...@in...> - 2005-07-11 08:49:29
|
On Saturday 09 July 2005 13:18, Blaisorblade wrote: > On Friday 08 July 2005 13:33, Oleg Girko wrote: > > On Thursday 07 July 2005 21:31, Blaisorblade wrote: > > > I guess that in NPTL headers, instead of using __errno_location() the > > > faster "__thread int errno;" is used; Oleg, can you verify this? [skipped] > > Compiling a test program with "-E" switch shows that preprocessor > > replaces "errno" with "(*__errno_location ())". > > Can you test on a UML file? Non urgent since my patch fixed it, but it > would still be useful. (do a make ARCH=um V=1 to take the right command > line, or even do make ARCH=um arch/um/<afile>.i and it will do everything > by itself). Some file should be using kernel_errno and that's ok, the ones > with _user.c (and the ones listed in USER_OBJS in their Makefile) should > get the above def. Building "file.i" fails for some reason, so I've captured command line using "make ARCH=um V=1" and replaced "-c -o FILE.o" with "-E" to get preprocessor output. I've tested two files: "arch/um/kernel/process.c" (listed in USER_OBJS) and "arch/um/kernel/signal_user.c" (not listed in USER_OBJS). The result: "errno" is substituted with "(*__errno_location ())" in both files. -- Oleg Girko, http://www.infoserver.ru/~ol/ |
From: Blaisorblade <bla...@ya...> - 2005-07-11 21:22:19
|
On Monday 11 July 2005 10:48, Oleg Girko wrote: > On Saturday 09 July 2005 13:18, Blaisorblade wrote: > > Can you test on a UML file? Non urgent since my patch fixed it, but it > > would still be useful. (do a make ARCH=um V=1 to take the right command > > line, or even do make ARCH=um arch/um/<afile>.i and it will do everything > > by itself). Some file should be using kernel_errno and that's ok, the > > ones with _user.c (and the ones listed in USER_OBJS in their Makefile) > > should get the above def. > > Building "file.i" fails for some reason, I guess because they are in USER_OBJS... > so I've captured command line > using "make ARCH=um V=1" and replaced "-c -o FILE.o" with "-E" to get > preprocessor output. I've tested two files: "arch/um/kernel/process.c" > (listed in USER_OBJS) and "arch/um/kernel/signal_user.c" (not listed in > USER_OBJS). Ok, it's not listed in USER_OBJS but it gets sucked in because it ends in _user.c (there's some magic hidden in arch/um/scripts to perform this). It's ok. > The result: "errno" is substituted with "(*__errno_location > ())" in both files. Thanks for the info. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |