The user-mode port of 2.4.0-test6 is really available this time.
I fixed a stupid, long-standing bug and it started working a lot better.
I'll recap what went into the last two releases since this is the first
release in which they are really usable:
Jim Leu's virtual ethernet driver provides a low-level network interface for
uml. It's easier to use, more general, and more flexible than the existing
slip-based umn interface, which I am planning on eliminating at some point.
Setting up the umn device is fraught with permission problems from allocating
the pty, to setting the line discipline on it, and configuring the slip
device. If all you want is an isolated virtual network, the eth device
requires no privileges; an external daemon handles packet routing. If you
want to put the host on the virtual net or put the virtual net on a physical
ethernet, all you need is to be able to allocate and configure an ethertap
device. See http://user-mode-linux.sourceforge.net/networking.html for more
details.
Also, there's Lars Brinkhoff's ptrace proxy, which allows gdb to debug kernel
threads without attaching to them, which they can't because they are already
being syscall traced. You can invoke the debugger from kernel startup by
putting 'debug' on the command line. You will get an xterm with gdb in it
stopped at the top of start_kernel(). You can start gdb afterwards by sending
the tracing thread a SIGUSR1. You attach to the kernel and do whatever gdb
things you want.
This doesn't totally work yet. Breakpoints, examining data, and looking at
source work fine. Stepping through code works most of the time, except
sometimes, it acts like you said 'cont' instead of 'next' or 'step'. Putting
conditions or commands on breakpoints doesn't work at all. Doing that will
cause segfaults. More information is available at
http://user-mode-linux.sourceforge.net/debugging.html
The project's home page is http://user-mode-linux.sourceforge.net
The project's download page is http://sourceforge.net/project/filelist.php?grou
p_id=429
Jeff

> (gdb) i sym 0x10034f7d
> proc_pid_lookup + 353 in section .text
I've seen a bunch of strange things happen around there. I'm chasing one of
them now.
> (gdb) i line *0x10034f7d Line 64 of "/usr/src/uml-linux/
> linux-2.4.0-test6.uml/include/asm/arch/atomic.h"
> starts at address 0x10034f7d <proc_pid_lookup+353>
> and ends at 0x10034f7f <proc_pid_lookup+355>.
You can get better line info by stepping forward from the last address
(0x10034f7f) + 1 until you get a line number in a .c file. That will tell you
where atomic_inc was called from.
Jeff

wstearns@... said:
> Initializing random number generator... done.
> Recovering nvi editor sessions... done.
> INIT: Entering runlevel: 2
> Initializing random number generator... done.
> Recovering nvi editor sessions... done.
> INIT: Entering runlevel: 2
> Kernel panic: Kernel mode fault at addr 0x53409f94, ip 0x10034f7d
What root_fs was that? It's a bit strange for it to be entering runlevel 2
twice.
To see where the crash was, do 'i sym 0x10034f7d' at that gdb.
'i line *0x10034f7d' will give you line number information if it's available.
I'm not too worried about this one. test6 is a piece of cr*p. When I can
boot it up and run my stress testers on it again, I'll become concerned about
other people's problems :-)
Jeff