From: D. B. <db...@en...> - 2004-08-18 20:23:11
|
I withdraw this error report against 2.4.26-3um against any plain vanilla UML kernel for that matter. I've launched 2.4.26-3um about 200 times (50 at once even, with the script attached its easy to stress test!) and never seen this in a kernel that we haven't modified ourselves... still if anyone has any ideas.... Thanks for your patience. D. Bahi wrote: > launching UMLs with nice seems to aggravate this problem -- > but it also has been seen w/o adding that irritant. > > status is 0x1c7f - which maps to 0x1c (SIGWINCH 28 right?) > > here it is trying to panic and generates a segfault > > #4 0x08051270 in main (argc=11, argv=0xbfffd3e4, envp=0xbfffd414) at > arch/um/main.c:148 > #3 0x080dd2f4 in linux_main (argc=11, argv=0xbfffd3e4) at um_arch.c:332 > #2 0x080d9154 in can_do_skas () at process.c:255 > #1 0x080d9058 in stop_ptraced_child (pid=21301, stack=0x40001000, > exitcode=1) at process.c:182 > #0 0x0805628c in panic (fmt=0x81c8080 "check_ptrace : child exited with > status 0x%x") at panic.c:67 > > values for locals and parameters in stop_ptraced_child are: > > (gdb) print errno > $1 = 0 > (gdb) print n > $2 = -1073774592 > (gdb) print pid > $3 = 21301 > (gdb) print status > $4 = 7295 > (gdb) print exitcode > $5 = 1 > (gdb) set radix 16 > (gdb) print status > $6 = 0x1c7f > (gdb) print n > $7 = 0xbfff8000 > > also have seen: > > 2.4.24-1um + reboot-signals > > Checking for the skas3 patch in the host...found > Checking for /proc/mm...found > CONFIG_HIGHMEM not enabled - physical memory shrunk to 499122176 bytes > Kernel virtual memory size shrunk to 32505856 bytes > capture_stack : Expected SIGSTOP, got status = 0x1c7f > > > 2.4.26-3um > > Checking for the skas3 patch in the host...found > Checking for /proc/mm...found > capture_stack : Expected SIGSTOP, got status = 0x1c7f > > -- Damn it! Morons don't learn until they die! -- Faye Valentine, _Cowboy Bebop, The Movie_. |