From: Jeff D. <jd...@ka...> - 2000-11-18 01:13:57
|
xi...@bo... said: > I succesfully applied the reiserfs patch to uml and it just works. The > only problem is, that it hangs on umount. That's cool. That's something I've been meaning to do, but haven't got around to. Did you need to install any usermode stuff, like a new mount or anything? Run it with 'debug' on the command line. This will fire up the kernel debugger. When it hangs, ^C the debugger and get a backtrace. See http://user-mode-linux.sourceforge.net/debugging.html for details on using the debugger if necessary. > Furthermore I've configured uml to be present on my LAN. I run the > daemon like this 'um_eth_net_util eth0 100', but I can only reach my > gateway from inside uml. The host machine and the other machines on > the LAN are not reachable. /me summons wstearns Jeff |
From: Jeff D. <jd...@ka...> - 2000-11-18 03:16:30
|
xi...@bo... said: > The debugger fires up allright, and I can break it with ^C. > However, after I hang the kernel, I can no longer break it. Try attaching to the tracing thread to see if it's in some kind of infinite loop. That's the only thing I can think of offhand which would cause gdb to hang. Jeff |
From: Christian L. <xi...@bo...> - 2000-11-18 12:50:43
|
Jeff Dike <jd...@ka...> writes: > xi...@bo... said: > > The debugger fires up allright, and I can break it with ^C. > > However, after I hang the kernel, I can no longer break it. > > Try attaching to the tracing thread to see if it's in some kind of infinite > loop. > > That's the only thing I can think of offhand which would cause gdb to hang. It looks like it's stuck in __wait4() for some reason. This is the backtrace: Program received signal SIGINT, Interrupt. 0x100cb8c9 in __wait4 () (gdb) bt #0 0x100cb8c9 in __wait4 () #1 0xbffff8fc in ?? () #2 0x100be3ad in signals (init_proc=0x100be858 <start_kernel_proc>, sp=0x10147ffc) at trap_user.c:100 #3 0x100bed48 in linux_main (argc=7, argv=0xbffffa04) at um_arch.c:191 #4 0x10001277 in main (argc=7, argv=0xbffffa04, envp=0xbffffa24) at /usr/src/linux-2.4.0-test10uml/arch/um/main.c:66 (gdb) -- Best regards Christian Laursen |
From: Jeff D. <jd...@ka...> - 2000-11-19 04:01:25
|
xi...@bo... said: > It looks like it's stuck in __wait4() for some reason. That's where it's supposed to be. You could try getting a backtrace the old way. Look at current_task.thread.extern_pid, and kill -STOP it. With gdb attached to the tracing thread 'call detach(that_pid)'. If it segfaults, do it again. Detach from the tracing thread and attach to the other pid. If the attach hangs, kill -CONT it. Then get a backtrace. You might see that the UML debugger is a huge improvement over what preceded it :-) Tonight, I did get a situation where the kernel debugger hung. It turned out that it was getting an infinite stream of segfaults for some reason. If I can reproduce it, I'll see what was going on and fix it. Jeff |
From: Christian L. <xi...@bo...> - 2000-11-19 22:08:13
|
Jeff Dike <jd...@ka...> writes: > xi...@bo... said: > > It looks like it's stuck in __wait4() for some reason. > > That's where it's supposed to be. Okay. > You could try getting a backtrace the old way. Look at > current_task.thread.extern_pid, and kill -STOP it. (gdb) inspect current_task.thread.extern_pid $1 = 909 [xi@x ~]$ kill -STOP 909 909: No such process Isn't there supposed to be a process with pid 909 on the host? (Or am I just clueless?) > You might see that the UML debugger is a huge improvement over what preceded > it :-) Indeed. :) -- Best regards Christian Laursen |
From: Jeff D. <jd...@ka...> - 2000-11-20 00:43:21
|
xi...@bo... said: > No, the last messages are the reiserfs initialization stuff: Well, something happened to that process. Can you print current_task.comm and current_task.thread? Jeff |
From: Christian L. <xi...@bo...> - 2000-11-20 21:16:44
|
Jeff Dike <jd...@ka...> writes: > xi...@bo... said: > > No, the last messages are the reiserfs initialization stuff: > > Well, something happened to that process. > > Can you print current_task.comm and current_task.thread? Yes: (gdb) inspect current_task.comm $1 = "kreiserfsd\000\000\000\000\000" (gdb) inspect current_task.thread $2 = {extern_pid = 1581, tracing = 0, forking = 0, kernel_stack = 1387667456, real_mm = 0x53dc3180, starting_exec = 0, signal = {signal = 0, sp = 0, handler = 0}, npending = 0, saved_sigs = {sig = {0, 0}}, nsyscalls = 0, process_regs = {regs = {0 <repeats 17 times>}}, syscall_regs = {regs = {0 <repeats 17 times>}}, syscall_stack = 0x0, syscall_stack_size = 0, altstack_regs = {regs = {0 <repeats 17 times>}}, altstack = 0x0, altstack_size = 0, cr2 = 0, err = 0, check_sigs = 0, restore_state = 0, mm_changes = 0, fault_addr = 0x0, syscall = {id = -1, args = {4294967295, 4294967295, 4294967295, 4294967295, 4294967295, 4294967295}, have_result = 0, result = -1, again = 0}, request = {op = 0, u = {exec = {ip = 269762560, sp = 1363378176}, fork = {task = 0x10144000, tramp_stack = 1363378176, sp = 0}, cswitch = {to = 0x10144000, from = 0x51438000}, thread = {proc = 0x10144000 <init_task_union>, arg = 0x51438000, flags = 0, new_pid = 0, new_task = 0x0, cpu = 0}, fork_finish = {stack = 269762560, regs = {regs = {1363378176, 0 <repeats 16 times>}}, from = 0x0}, cb = {proc = 0x10144000 <init_task_union>, arg = 0x51438000}}}} -- Best regards Christian Laursen |
From: Jeff D. <jd...@ka...> - 2000-11-21 18:19:16
|
xi...@bo... said: > (gdb) inspect current_task.comm > $1 = "kreiserfsd\000\000\000\000\000" That's a kernel thread, and I bet it's exiting, which is something that I never expected a kernel thread to do. It should just work, since there isn't much difference between a kernel thread and a user process, but I guess I messed something up. I'm going to grab the reiserfs sources and see exactly what that nasty little thread is doing. Jeff |
From: Christian L. <xi...@bo...> - 2000-11-18 01:27:40
|
Jeff Dike <jd...@ka...> writes: > xi...@bo... said: > > I succesfully applied the reiserfs patch to uml and it just works. The > > only problem is, that it hangs on umount. > > That's cool. That's something I've been meaning to do, but haven't got around > to. Did you need to install any usermode stuff, like a new mount or anything? No, not at all. You need the reiserfs tools of course to build the filesystem, but I had already done that on the host. > Run it with 'debug' on the command line. This will fire up the kernel > debugger. When it hangs, ^C the debugger and get a backtrace. See > http://user-mode-linux.sourceforge.net/debugging.html for details on using the > debugger if necessary. Thank you, I'll try that. -- Best regards Christian Laursen |
From: Christian L. <xi...@bo...> - 2000-11-18 01:59:57
|
Christian Laursen <xi...@bo...> writes: > Jeff Dike <jd...@ka...> writes: > > > Run it with 'debug' on the command line. This will fire up the kernel > > debugger. When it hangs, ^C the debugger and get a backtrace. See > > http://user-mode-linux.sourceforge.net/debugging.html for details on using the > > debugger if necessary. > > Thank you, I'll try that. Well, things seem to be a little complicated here. The debugger fires up allright, and I can break it with ^C. However, after I hang the kernel, I can no longer break it. It dies on a SIGTERM, but that's about it. Any suggestions? -- Best regards Christian Laursen |