From: D. B. <db...@en...> - 2004-07-28 20:05:55
Attachments:
signature.asc
|
seems like there is a race condition around this sometimes i get this printout - sometimes i don't and sometimes it's fine - gets worse with higher system load here's the console output: 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 best backtrace i could get: #4 0xa000a2b0 in main (argc=12, argv=0xbfffdb24, envp=0xbfffdb58) at arch/um/main.c:146 #3 0xa009c2e2 in linux_main (argc=12, argv=0xbfffdb24) at um_arch.c:351 #2 0xa0097124 in can_do_skas () at process.c:265 #1 0xa0097028 in stop_ptraced_child (pid=32285, stack=0x40001000, exitcode=1) at process.c:192 #0 0xa000f387 in panic (fmt=0xa018db00 "check_ptrace : child exited with status 0x%x") at panic.c:111 -- db |
From: D. B. <db...@en...> - 2004-08-06 19:17:13
Attachments:
signature.asc
|
ok - i have skas hosts - and i'm tired of this occasional hang. BEGIN HACK ALERT -- i have 'can_do_skas()' return 1 -- END HACK ALERT and now the kernel fails to pass control to init ? why ? (run_init_process is called with /sbin/init - but it just hangs...) any ideas? D. Bahi wrote: > seems like there is a race condition around this > sometimes i get this printout - sometimes i don't > and sometimes it's fine - gets worse with higher > system load here's the console output: > > 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 > > best backtrace i could get: > > #4 0xa000a2b0 in main (argc=12, argv=0xbfffdb24, envp=0xbfffdb58) at > arch/um/main.c:146 > #3 0xa009c2e2 in linux_main (argc=12, argv=0xbfffdb24) at um_arch.c:351 > #2 0xa0097124 in can_do_skas () at process.c:265 > #1 0xa0097028 in stop_ptraced_child (pid=32285, stack=0x40001000, > exitcode=1) at process.c:192 > #0 0xa000f387 in panic (fmt=0xa018db00 "check_ptrace : child exited > with status 0x%x") at panic.c:111 > > -- > db -- There are two kinds of people in this world: Those that enter a room and turn the television set on, and those that enter a room and turn the television set off. -- Raymond Shaw, The Manchurian Candidate (1962). |
From: Jeff D. <jd...@ad...> - 2004-08-06 21:46:35
|
db...@en... said: > ok - i have skas hosts - and i'm tired of this occasional hang. Have you tried the reboot-signals patch? Jeff |
From: D. B. <db...@en...> - 2004-08-06 22:48:51
Attachments:
signature.asc
|
reboot-signals is only listed in the 2.6 series patches; i didn't think to try it. hey, THANKS! _it applies_ and almost solves the problem completely!!! of my 20 simultaneous UMLs only one failed to launch: Checking for the skas3 patch in the host...found is all it does - and it just sits there.... also on reboot - do you expect the deactivate_all_fds to fail? umount: /dev: device is busy Please stand by while rebooting the system. Restarting system. deactivate_all_fds failed, errno = 9 Checking for the skas3 patch in the host...found Checking for /proc/mm...found Jeff Dike wrote: > db...@en... said: > >>ok - i have skas hosts - and i'm tired of this occasional hang. > > > Have you tried the reboot-signals patch? > > Jeff > -- There are two kinds of people in this world: Those that enter a room and turn the television set on, and those that enter a room and turn the television set off. -- Raymond Shaw, The Manchurian Candidate (1962). |
From: Jeff D. <jd...@ad...> - 2004-08-06 23:59:57
|
On Fri, Aug 06, 2004 at 06:48:29PM -0400, D. Bahi wrote: > reboot-signals is only listed in the 2.6 series patches; > i didn't think to try it. > > hey, THANKS! _it applies_ and almost solves the problem completely!!! It applies because you're running an old 2.4. That patch is in the current 2.4 UML. > of my 20 simultaneous UMLs only one failed to launch: > > Checking for the skas3 patch in the host...found This is a different UML ... > Restarting system. > > deactivate_all_fds failed, errno = 9 > Checking for the skas3 patch in the host...found > Checking for /proc/mm...found from this one, right? If so, did the second one boot OK, and the only problem was the errno=9 thing? Try attaching gdb to an example of the failed launch, and get a stack trace from it. Jeff |
From: D. B. <db...@en...> - 2004-08-07 00:15:33
Attachments:
signature.asc
|
> It applies because you're running an old 2.4. That patch is in the current > 2.4 UML. > right 2.4.24 - 2.4.26 um deltas. got it. >> Checking for the skas3 patch in the host...found > > > This is a different UML ... > > >>Restarting system. >> >>deactivate_all_fds failed, errno = 9 >>Checking for the skas3 patch in the host...found >>Checking for /proc/mm...found > > > from this one, right? > yes. the hung one stayed hung. next time i see it i'll attach gdb. > If so, did the second one boot OK, and the only problem was the errno=9 > thing? yes. just so. again, many thanks. |