From: Matt Z. <md...@de...> - 2001-12-07 10:09:34
Attachments:
uml-segv.text
|
I'm seeing a strange hang. The host environment is Debian unstable, Linux 2.4.9. UML is 2.4.14-6um. I happen to be using 2.4.14 because Debian only has 2.4.14 and 2.4.16 sources, and UML only has 2.4.14 and 2.4.15 patches. A typescript is attached showing the problem. Essentially, whenever I halt or reboot, immediately after the system comes down ("Power down" or similar), I get a "Seg fault in signals" and the UML process (expectedly) hangs until killed. Naturally, I start it up under gdb (via the "debug" command-line argument) to find out what's happening, and voila, the problem vanishes. Has anyone else seen this kind of behavior? -- - mdz |
From: <pet...@ku...> - 2001-12-07 10:42:06
|
On Fri, 7 Dec 2001 05:07:58 -0500, Matt Zimmerman wrote: >I'm seeing a strange hang. The host environment is Debian unstable, = Linux >2.4.9. UML is 2.4.14-6um. I happen to be using 2.4.14 because Debian = only >has 2.4.14 and 2.4.16 sources, and UML only has 2.4.14 and 2.4.15 = patches. > >A typescript is attached showing the problem. Essentially, whenever I = halt >or reboot, immediately after the system comes down ("Power down" or >similar), I get a "Seg fault in signals" and the UML process = (expectedly) >hangs until killed. > >Naturally, I start it up under gdb (via the "debug" command-line = argument) >to find out what's happening, and voila, the problem vanishes. > >Has anyone else seen this kind of behavior? this is a problem like this what happens to me: environment: host is 2.4.4,=20 networking of uml is ethertap uml is 2.4.14-5um running debian 2.2R4 description when i shutdown the uml the runlevel-machinery runs for the final goal (to halt :-). but it hangs in the following command: swapoff -a until i doom the uml up with kill Sounds very synonym |
From: Matt Z. <md...@de...> - 2001-12-07 10:51:28
|
On Fri, Dec 07, 2001 at 10:41:24AM +0000, Peter Schmidt wrote: > On Fri, 7 Dec 2001 05:07:58 -0500, Matt Zimmerman wrote: > > description > when i shutdown the uml the runlevel-machinery runs for > the final goal (to halt :-). > but it hangs in the following command: > swapoff -a > until i doom the uml up with kill > > Sounds very synonym Hmm. In my situation, swapoff has already run (at the point "Deactivating swap... done."). That completes successfully, as does the unmounting of all filesystems afterward. It's only _after_ the "Power down" message is issued that I get the hang. -- - mdz |
From: Jeff D. <jd...@ka...> - 2001-12-07 16:50:11
|
md...@de... said: > A typescript is attached showing the problem. Essentially, whenever I > halt or reboot, immediately after the system comes down ("Power down" > or similar), I get a "Seg fault in signals" and the UML process > (expectedly) hangs until killed. When this happens, attach a gdb to the tracing thread and get a stack trace. I did fix a reboot/halt bug the other day, but it involved a normal kernel panic when UML was shut down with the mconsole. This is something different, though. Jeff |
From: Matt Z. <md...@de...> - 2001-12-07 17:04:28
|
On Fri, Dec 07, 2001 at 01:09:57PM -0500, Jeff Dike wrote: > md...@de... said: > > A typescript is attached showing the problem. Essentially, whenever I > > halt or reboot, immediately after the system comes down ("Power down" > > or similar), I get a "Seg fault in signals" and the UML process > > (expectedly) hangs until killed. > > When this happens, attach a gdb to the tracing thread and get a stack trace. Program received signal SIGSEGV, Segmentation fault. xterm_close (fd=0, d=0x0) at xterm.c:97 97 if(data->pid != -1) kill(data->pid, SIGKILL); (gdb) bt #0 xterm_close (fd=0, d=0x0) at xterm.c:97 #1 0xa00a845f in exit_debugger_cb (unused=0x0) at trap_kern.c:194 #2 0xa00aa9c8 in do_proc_op (t=0xa1ea0000, proc_id=0) at process_kern.c:356 #3 0xa00a8b00 in signals (init_proc=0xa00a92f0 <start_kernel_proc>, sp=0xa014bffc) at trap_user.c:200 #4 0xa00a966a in linux_main (argc=3, argv=0xbffff864) at um_arch.c:309 #5 0xa000a325 in main (argc=3, argv=0xbffff864, envp=0xbffff874) at arch/um/main.c:111 #6 0xa00b4b15 in __libc_start_main () at af_packet.c:1882 (gdb) I guess the immediate cause is clear, and this also explains why it didn't happen when running in debugging mode. -- - mdz |
From: Matt Z. <md...@de...> - 2001-12-07 17:09:45
|
On Fri, Dec 07, 2001 at 12:02:51PM -0500, Matt Zimmerman wrote: > Program received signal SIGSEGV, Segmentation fault. > xterm_close (fd=0, d=0x0) at xterm.c:97 > 97 if(data->pid != -1) kill(data->pid, SIGKILL); > (gdb) bt > #0 xterm_close (fd=0, d=0x0) at xterm.c:97 > #1 0xa00a845f in exit_debugger_cb (unused=0x0) at trap_kern.c:194 It looks like in 2.4.15-3 there is: static void exit_debugger(void) { if(xterm_data != NULL) tracing_cb(exit_debugger_cb, NULL); } rather than: static void exit_debugger(void) { tracing_cb(exit_debugger_cb, NULL); } So this would appear to have been fixed already. -- - mdz |