From: Jeff D. <jd...@ka...> - 2000-10-23 04:11:39
|
> I didn't change any of the configuration settings from the way they > came out of the box. I'm running with 2 processors, if that helps. Does this mean you are running it on a 2 processor SMP box or you turned on SMP in UML, got it to compile, and it panics when you run it? That first sentence seems to say that you didn't, but "running with 2 processors" is how I describe running a 2 processor SMP UML. If you turned on SMP, then I need to see the changes you made to get it to compile. If you didn't, then I need stack traces from the panics. Jeff |
From: Jeff D. <jd...@ka...> - 2000-10-23 15:05:24
|
em...@mi... said: > (gdb) bt > #0 0x100ab9f1 in __libc_nanosleep () > #1 0x100ab9b1 in __sleep (seconds=10) at > ../sysdeps/unix/sysv/linux/sleep.c:78 > #2 0x100a0edb in do_idle () at process_kern.c:431 > #3 0x100a0f76 in cpu_idle () at process_kern.c:457 > #4 0x100e3307 in start_kernel () at init/main.c:591 > #5 0x1009f948 in start_kernel_proc (unused=0x0) at um_arch.c:70 > #6 0x1009f3a3 in signal_tramp (arg=0x1009f910) at trap_user.c:49 That wasn't it. That's the normal idle thread stack. Try putting a breakpoint in panic and getting the stack from there. Jeff |
From: Emil O. <em...@mi...> - 2000-10-23 15:18:02
|
Ok, sorry about that. I don't know if this helps anymore, but I did actually get the backtrace in panic(). Emil Breakpoint 2, panic (fmt=0x1010cd80 "Kernel mode fault at addr 0x%lx, ip 0x%lx") at panic.c:54 54 va_start(args, fmt); (gdb) bt #0 panic (fmt=0x1010cd80 "Kernel mode fault at addr 0x%lx, ip 0x%lx") at panic.c:54 #1 0x1009f010 in segv (address=1, ip=1, is_write=0, is_user=0) at trap_kern.c:66 #2 0x1009f89a in segv_handler (sig=11) at trap_user.c:265 #3 0x100a6198 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:125 #4 0x1e8 in ?? () #5 0x0 in ?? () On Mon, 23 Oct 2000, Jeff Dike wrote: > em...@mi... said: > > (gdb) bt > > #0 0x100ab9f1 in __libc_nanosleep () > > #1 0x100ab9b1 in __sleep (seconds=10) at > > ../sysdeps/unix/sysv/linux/sleep.c:78 > > #2 0x100a0edb in do_idle () at process_kern.c:431 > > #3 0x100a0f76 in cpu_idle () at process_kern.c:457 > > #4 0x100e3307 in start_kernel () at init/main.c:591 > > #5 0x1009f948 in start_kernel_proc (unused=0x0) at um_arch.c:70 > > #6 0x1009f3a3 in signal_tramp (arg=0x1009f910) at trap_user.c:49 > > That wasn't it. That's the normal idle thread stack. > > Try putting a breakpoint in panic and getting the stack from there. > > Jeff > > |
From: Jeff D. <jd...@ka...> - 2000-10-23 17:14:32
|
em...@mi... said: > (gdb) bt > #0 panic (fmt=0x1010cd80 "Kernel mode fault at addr 0x%lx, ip 0x%lx") > at panic.c:54 > #1 0x1009f010 in segv (address=1, ip=1, is_write=0, is_user=0) > at trap_kern.c:66 > #2 0x1009f89a in segv_handler (sig=11) at trap_user.c:265 That's the stack I wanted. And I hate these. The thing to do is figure out how it tried to branch to 1 (or 0 in your last example). Find the esp value in *sc in the segv_handler frame and look at that general area of memory. Make sure it looks kind of stack-like, and isn't all zeros. If the stack looks ok, then look at current_task.thread.process_regs and see if the values there look right (e.g. both eip and esp should be in userspace). Then look at the most recent stuff in signal_record. This is a circular buffer whose end is signal_index - 1. What I normally do is this: set $i=signal_index - 1 p signal_record[$i--] hit return until I've seen enough If this is always reproducable at the same point every time, then the last dozen or so entries probably cover the problem and you can piece together what happened from them. If this doesn't always happen the same way, then look for a SIGIO, SIGVTALRM, or SIGALRM entry (signals 29, 26, and 14). Then reproduce the bug a bunch of times and see what is always the same. Jeff |
From: Emil O. <em...@mi...> - 2000-10-23 04:36:10
|
On Mon, 23 Oct 2000, Jeff Dike wrote: > > I didn't change any of the configuration settings from the way they > > came out of the box. I'm running with 2 processors, if that helps. > > Does this mean you are running it on a 2 processor SMP box or you turned on > SMP in UML, got it to compile, and it panics when you run it? That first > sentence seems to say that you didn't, but "running with 2 processors" is how > I describe running a 2 processor SMP UML. Sorry, I meant that my machine has 2 processors and that UML is not compiled for SMP. > If you turned on SMP, then I need to see the changes you made to get it to > compile. > > If you didn't, then I need stack traces from the panics. Kernel panic: Kernel mode fault at addr 0x0, ip 0x0 (gdb) bt #0 0x100ab9f1 in __libc_nanosleep () #1 0x100ab9b1 in __sleep (seconds=10) at ../sysdeps/unix/sysv/linux/sleep.c:78 #2 0x100a0edb in do_idle () at process_kern.c:431 #3 0x100a0f76 in cpu_idle () at process_kern.c:457 #4 0x100e3307 in start_kernel () at init/main.c:591 #5 0x1009f948 in start_kernel_proc (unused=0x0) at um_arch.c:70 #6 0x1009f3a3 in signal_tramp (arg=0x1009f910) at trap_user.c:49 If you need any more info, just let me know. This is very reproducible. Thanks, Emil |