From: S A <sag...@ho...> - 2006-04-07 19:26:13
|
Hi I am having a problem getting an initial login prompt on my UML and it's related to CONFIG_FRAME_POINTER (my host system is a x86_64 machine running 2.6.16). With a 2.6.16 codebase (and it has the x86_64 patch referenced in http://www.ussg.iu.edu/hypermail/linux/kernel/0510.1/0185.html), I observe: 1. With CONFIG_FRAME_POINTER enabled in .config, bootup stops after "VFS: Mounted root (ext2 filesystem) readonly" and stderr shows the message unable to open console. 2. With CONFIG_FRAME_POINTER disabled, it works! (I get a login prompt and get a bash shell). I am using a gentoo x86_64 stage 3 tarball as the base for my root_fs. Just curious why this is and if I am supposed to have frame pointers omitted. Some other observations (if they help): 1. I went to a 2.6.13 codebase for my UML, and it all works regardless of the FRAME_POINTER config. 2. I removed the patch above, and as expected the UML crashes when CONFIG_FRAME_POINTER is disabled. It boots up fine with CONFIG_FRAME_POINTER enabled. Please let me know if I can provide any other information. thanks. shalb |
From: Jeff D. <jd...@ad...> - 2006-04-07 20:41:12
|
On Fri, Apr 07, 2006 at 07:25:46PM +0000, S A wrote: > 1. With CONFIG_FRAME_POINTER enabled in .config, bootup stops after > "VFS: Mounted root (ext2 filesystem) readonly" and stderr > shows the message unable to open console. Can you strace the thing and see where it's looping? Jeff |
From: S A <sag...@ho...> - 2006-04-07 21:40:47
|
Hi Is there a way to make strace work with threads? When i run uml under strace, it always exits (and it exits doing something innocuos like a fcntl or socketpair). I also tried this under gdb and when I interrupt the UML, the backtrace just shows a signal handler (included below). Another data point is mconsole does work. Sorry for not being able to provide some more data. thanks. Program received signal SIGINT, Interrupt. 0x0000000060222909 in waitpid () at atomic.h:172 172 { (gdb) bt #0 0x0000000060222909 in waitpid () at atomic.h:172 #1 0x0000000060032f31 in wait_stub_done (pid=8892, sig=0, fname=0x602a044f "get_skas_faultinfo") at process.c:61 #2 0x0000000060033065 in get_skas_faultinfo (pid=8892, fi=0x60d0ede8) at process.c:108 #3 0x0000000060033dfa in user_signal (sig=11, regs=0x60d0eb08, pid=8892) at trap.c:67 #4 0x000000006003355b in userspace (regs=0x60d0eb08) at process.c:298 >From: Jeff Dike <jd...@ad...> >To: S A <sag...@ho...> >CC: use...@li... >Subject: Re: [uml-user] unable to get login prompt with >CONFIG_FRAME_POINTER & x86_64 >Date: Fri, 7 Apr 2006 15:41:11 -0400 > >On Fri, Apr 07, 2006 at 07:25:46PM +0000, S A wrote: > > 1. With CONFIG_FRAME_POINTER enabled in .config, bootup stops after > > "VFS: Mounted root (ext2 filesystem) readonly" and stderr > > shows the message unable to open console. > >Can you strace the thing and see where it's looping? > > Jeff |
From: Jeff D. <jd...@ad...> - 2006-04-07 22:39:38
|
On Fri, Apr 07, 2006 at 09:40:44PM +0000, S A wrote: > Is there a way to make strace work with threads? When i run > uml under strace, it always exits (and it exits doing something > innocuos like a fcntl or socketpair). UML exits? Or just strace? Seems like either a strace or ptrace bug. How about waiting until UML hangs and then attaching strace to it? > I also tried this under gdb > and when I interrupt the UML, the backtrace just shows a signal > handler (included below). This is normal. Jeff |
From: S A <sag...@ho...> - 2006-04-07 22:58:38
|
> >UML exits? Or just strace? Seems like either a strace or ptrace bug. Sorry - it was strace that exits - the UML is still running. > >How about waiting until UML hangs and then attaching strace to it? > So, there are 5 threads of UML. The main (or the first thread) shows: ================================================== --- SIGCHLD (Child exited) @ 0 (0) --- wait4(9078, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGUSR1}], WSTOPPED, NULL) = 9078 ptrace(PTRACE_SETREGS, 9078, 0, 0x60d0eb08) = 0 ptrace(PTRACE_SETFPREGS, 9078, 0, 0x60d0ebe0) = 0 ptrace(PTRACE_SYSCALL, 9078, 0, SIG_0) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- wait4(9078, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}], WSTOPPED, NULL) = 9078 ptrace(PTRACE_GETREGS, 9078, 0, 0x60d0eb08) = 0 ptrace(PTRACE_GETFPREGS, 9078, 0, 0x60d0ebe0) = 0 ptrace(PTRACE_CONT, 9078, 0, SIGSEGV) = 0 =================================================== So it seems to be waiting on process ID 9078 which also a UML thread. However strace refuses to attach to it even though I am running as root user: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted The other three child threads aren't doing much - each is waiting on a different event: Thread 1 - io_getevents(0x2b723ae76000, 0x1, 0x1, 0x6042ffb8, 0 Thread 2 - read(5, Thread 3 - poll( I will be back online in a couple of hours. Thank you for your help. shalb. >From: Jeff Dike <jd...@ad...> >To: S A <sag...@ho...> >CC: use...@li... >Subject: Re: [uml-user] unable to get login prompt with >CONFIG_FRAME_POINTER & x86_64 >Date: Fri, 7 Apr 2006 17:40:43 -0400 > >On Fri, Apr 07, 2006 at 09:40:44PM +0000, S A wrote: > > Is there a way to make strace work with threads? When i run > > uml under strace, it always exits (and it exits doing something > > innocuos like a fcntl or socketpair). > >UML exits? Or just strace? Seems like either a strace or ptrace bug. > >How about waiting until UML hangs and then attaching strace to it? > > > I also tried this under gdb > > and when I interrupt the UML, the backtrace just shows a signal > > handler (included below). > >This is normal. > > Jeff |
From: Jeff D. <jd...@ad...> - 2006-04-08 21:21:29
|
On Fri, Apr 07, 2006 at 10:58:31PM +0000, S A wrote: > So, there are 5 threads of UML. The main (or the first thread) shows: > > ================================================== > > --- SIGCHLD (Child exited) @ 0 (0) --- > wait4(9078, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGUSR1}], WSTOPPED, NULL) = > 9078 > ptrace(PTRACE_SETREGS, 9078, 0, 0x60d0eb08) = 0 > ptrace(PTRACE_SETFPREGS, 9078, 0, 0x60d0ebe0) = 0 > ptrace(PTRACE_SYSCALL, 9078, 0, SIG_0) = 0 > --- SIGCHLD (Child exited) @ 0 (0) --- > wait4(9078, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}], WSTOPPED, NULL) = > 9078 > ptrace(PTRACE_GETREGS, 9078, 0, 0x60d0eb08) = 0 > ptrace(PTRACE_GETFPREGS, 9078, 0, 0x60d0ebe0) = 0 > ptrace(PTRACE_CONT, 9078, 0, SIGSEGV) = 0 This is what I expected - it's trying and failing to fix a page fault. Can you send me the binary? Jeff |
From: Jeff D. <jd...@ad...> - 2006-04-10 21:22:45
|
On Mon, Apr 10, 2006 at 06:58:27PM +0000, S A wrote: > Sorry for the late reply. I have uploaded the linux UML binary to > the following link: Can you see if this patch helps? Index: linux-2.6.16-mm/arch/um/sys-x86_64/stub_segv.c =================================================================== --- linux-2.6.16-mm.orig/arch/um/sys-x86_64/stub_segv.c +++ linux-2.6.16-mm/arch/um/sys-x86_64/stub_segv.c @@ -33,7 +33,7 @@ stub_segv_handler(int sig) struct ucontext *uc; int pid; - __asm__("movq %%rdx, %0" : "=g" (uc) :); + __asm__ __volatile__("movq %%rdx, %0" : "=g" (uc) :); GET_FAULTINFO_FROM_SC(*((struct faultinfo *) UML_CONFIG_STUB_DATA), &uc->uc_mcontext); @@ -44,8 +44,8 @@ stub_segv_handler(int sig) * the signal frame. So, we use the ucontext pointer, which we know * already, to get the signal frame pointer, and add 8 to that. */ - __asm__("movq %0, %%rsp; movq %1, %%rax ; syscall": : - "g" ((unsigned long) container_of(uc, struct rt_sigframe, - uc) + 8), - "g" (__NR_rt_sigreturn)); + __asm__ __volatile__("movq %0, %%rsp; movq %1, %%rax ; syscall": : + "g" ((unsigned long) + container_of(uc, struct rt_sigframe, uc) + 8), + "g" (__NR_rt_sigreturn)); } Index: linux-2.6.16-mm/arch/um/sys-i386/stub_segv.c =================================================================== --- linux-2.6.16-mm.orig/arch/um/sys-i386/stub_segv.c +++ linux-2.6.16-mm/arch/um/sys-i386/stub_segv.c @@ -27,6 +27,6 @@ stub_segv_handler(int sig) * the stack in its original form when we do the sigreturn here, by * hand. */ - __asm__("mov %0,%%esp ; movl %1, %%eax ; " - "int $0x80" : : "a" (sc), "g" (__NR_sigreturn)); + __asm__ __volatile__("mov %0,%%esp ; movl %1, %%eax ; " + "int $0x80" : : "a" (sc), "g" (__NR_sigreturn)); } |
From: S A <sag...@ho...> - 2006-04-10 22:16:00
|
Jeff Yes! That fixed it. So the asm was just getting compiled out ? thanks! shalbh >From: Jeff Dike <jd...@ad...> >To: S A <sag...@ho...> >CC: use...@li... >Subject: Re: [uml-user] unable to get login prompt with >CONFIG_FRAME_POINTER & x86_64 >Date: Mon, 10 Apr 2006 16:23:55 -0400 > >On Mon, Apr 10, 2006 at 06:58:27PM +0000, S A wrote: > > Sorry for the late reply. I have uploaded the linux UML binary to > > the following link: > >Can you see if this patch helps? > >Index: linux-2.6.16-mm/arch/um/sys-x86_64/stub_segv.c >=================================================================== >--- linux-2.6.16-mm.orig/arch/um/sys-x86_64/stub_segv.c >+++ linux-2.6.16-mm/arch/um/sys-x86_64/stub_segv.c >@@ -33,7 +33,7 @@ stub_segv_handler(int sig) > struct ucontext *uc; > int pid; > >- __asm__("movq %%rdx, %0" : "=g" (uc) :); >+ __asm__ __volatile__("movq %%rdx, %0" : "=g" (uc) :); > GET_FAULTINFO_FROM_SC(*((struct faultinfo *) UML_CONFIG_STUB_DATA), > &uc->uc_mcontext); > >@@ -44,8 +44,8 @@ stub_segv_handler(int sig) > * the signal frame. So, we use the ucontext pointer, which we know > * already, to get the signal frame pointer, and add 8 to that. > */ >- __asm__("movq %0, %%rsp; movq %1, %%rax ; syscall": : >- "g" ((unsigned long) container_of(uc, struct rt_sigframe, >- uc) + 8), >- "g" (__NR_rt_sigreturn)); >+ __asm__ __volatile__("movq %0, %%rsp; movq %1, %%rax ; syscall": : >+ "g" ((unsigned long) >+ container_of(uc, struct rt_sigframe, uc) >+ 8), >+ "g" (__NR_rt_sigreturn)); > } >Index: linux-2.6.16-mm/arch/um/sys-i386/stub_segv.c >=================================================================== >--- linux-2.6.16-mm.orig/arch/um/sys-i386/stub_segv.c >+++ linux-2.6.16-mm/arch/um/sys-i386/stub_segv.c >@@ -27,6 +27,6 @@ stub_segv_handler(int sig) > * the stack in its original form when we do the sigreturn here, by > * hand. > */ >- __asm__("mov %0,%%esp ; movl %1, %%eax ; " >- "int $0x80" : : "a" (sc), "g" (__NR_sigreturn)); >+ __asm__ __volatile__("mov %0,%%esp ; movl %1, %%eax ; " >+ "int $0x80" : : "a" (sc), "g" >(__NR_sigreturn)); > } |
From: Jeff D. <jd...@ad...> - 2006-04-10 23:51:10
|
On Mon, Apr 10, 2006 at 10:15:57PM +0000, S A wrote: > Yes! That fixed it. So the asm was just getting compiled out ? It was getting rearranged. Jeff |