user-mode-linux-user Mailing List for User-mode Linux kernel port (Page 791)

 Thanks, Jeff. I have no idea what modify_ldt does, but I straced
 a run of the JVM under the normal kernel and found it was returning
 0 (at least in these two cases) so I implemented a one-line modify_ldt
 in UML that returns 0. The result was that Java hung. I did not strace
 that run so I don't know what was up. At that point I sent the mail.

 stewart


On Wed, 6 Dec 2000, Jeff Dike wrote:

> st...@ne... said:
> > modify_ldt(0x11, 0xbf7ffa24, 0x10)      = -1 ENOSYS (Function not
> > implemented) 
> 
> This says it all, as far as running this particular jvm.  UML doesn't 
> implement the i386-specific system calls.  It shouldn't crash the kernel 
> though.  I'll look into that.
> 
> >  any ideas what I can do to get this working? 
> 
> Tell me what modify_ldt is supposed to do (or point me at some docs) and I'll 
> see if it can be implemented.
> 
> 				Jeff
> 
> 

Hi

i have had uml running for most of the night and got the networking sorted
but every now an again i get the following error

Kernel panic: wait_for_stop failed to wait for 7930 to stop with 19
in interrupt handler - not syncing
and also the linux (tracing thread) starts using 100% cpu time

does anyone know what would be causing this ?

thanks
	James

-- 
---------------------------------------------
Check Out: http://stev.org
E-Mail: mi...@st...
  3:00am  up 9 days, 11:34,  7 users,  load average: 0.42, 0.54, 0.54

ma...@co... said:
> Kernel panic: kernel mode fault at addr 0x0, ip 0x10079fc0 in
> interrupt handler - not syncing
> What can I/should I do to track this problem down? 

The first thing is to run it under the debugger (i.e. 'debug' on the command 
line) and get a backtrace when it panics.

But ultimately we probably need to figure out why MySQL is segfaulting, since 
that's happening first.

				Jeff

While running MySQL/PHP/Apache under UML everything seems to run fine
under light load.  When I use Siege to increase the load on the server,
MySQL eventually segfaults and then I get a kernel panic.

This happens on the binaries from your site (both test10 and test11).  I
also tried the latest CVS patch, and used the "ubd=sync" option, same
problem.

Here's what I get on the console after MySQL segfaults:

Kernel panic: kernel mode fault at addr 0x0, ip 0x10079fc0
in interrupt handler - not syncing

What can I/should I do to track this problem down?

Thanks.

-- 

 - Matt Clay
 - Cowboyz.com
 - (503) 241-1990

st...@ne... said:
> modify_ldt(0x11, 0xbf7ffa24, 0x10)      = -1 ENOSYS (Function not
> implemented) 

This says it all, as far as running this particular jvm.  UML doesn't 
implement the i386-specific system calls.  It shouldn't crash the kernel 
though.  I'll look into that.

>  any ideas what I can do to get this working? 

Tell me what modify_ldt is supposed to do (or point me at some docs) and I'll 
see if it can be implemented.

				Jeff

 I'm trying to run IBM's Java JDK 1.1.8 under a user-mode-linux kernel
 without success. Typing "java" at the command line returns the normal
 help message, but running a simple 2 line "hello world" program causes
 the kernel to double fault. Here's the tail of "strace java hello" from
 inside the user-mode kernel:

brk(0x804d000)                          = 0x804d000
modify_ldt(0x11, 0xbf7ffa30, 0x10)      = -1 ENOSYS (Function not
implemented)
write(2, "ldt_clear: modify_ldt: Function "..., 48ldt_clear: modify_ldt:
Function not implemented
) = 48
rt_sigaction(SIGUSR1, {0x4003a490, ~[], 0x4000000}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGSEGV, {0x4003a490, ~[USR1], SA_STACK|0x4000000}, {SIG_DFL},
8) = 0
rt_sigaction(SIGILL, {0x4003a490, ~[USR1], 0x4000000}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGFPE, {0x4003a490, ~[USR1], 0x4000000}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGBUS, {0x4003a490, ~[USR1], 0x4000000}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGABRT, {0x4003a490, ~[USR1], 0x4000000}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {0x4003a490, ~[USR1], 0x4000000}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [USR1], NULL, 8) = 0
brk(0x8052000)                          = 0x8052000
modify_ldt(0x11, 0xbf7ffa24, 0x10)      = -1 ENOSYS (Function not
implemented)
write(2, "ldt_setup: modify_ldt: Function "..., 48ldt_setup: modify_ldt:
Function not implemented
) = 48
Kernel panic: Double fault on 0x804d000 - panicing because it wasn't fixed
the first time

 any ideas what I can do to get this working?

 thanks,

 stewart

Well, here is the patch I promissed.

It's actualy much better then the last one (please, destroy it if you still
have a copy :-)).

Lemme tell you a little about it.
First, we now have 3 situations instead of 2.

1st: The debuging code is not compiled in
2nd: The debuging code is compiled in and is deactivated
3rd: The debuging code is compiled in and is activated

In any of the 3 situations, I have noticed an improvement of at least 20%
on the network performance compared to the original code (with debuging).

Do, what we did to make the debuging hit much smaller ?
Well, we use threads :-) The main process just takes care of the
routing. When it wants to write debug, it doesn't do it itself, but 
instead calls a function debug().

While all the routing is happening, we have a thread running in 
paralel (of course :-), with low priority (nice(2)), taking care of
the debug output job (which is farly slow). The funcion debug() just
write to a pipe (nonblocking, or else we would not have any performance
gain), and the debug thread reads from there.

Also we introduced the concept of the UMLNETDEBUG environment variable.
That it does is to instruct the um_eth_net_tool application to start or
not the debugging facility. Quite simples. If the variable is defined,
we start debugging. If not, we don't.

Anyway, the patch is attached bellow.

-- 
 Rodrigo Barbosa (morcego)  - rod...@co...
 Conectiva R&D Team         - http://distro.conectiva.com.br
 "Quis custodiet custodes?" - http://www.conectiva.com

On Tue, Dec 05, 2000 at 02:56:18PM -0800, Mooneer Salem wrote:
> [sent to user-mode-linux-devel as well]
>=20
> I'm messing with the network code at the moment. I noticed that
> the virtual ethernet driver makes a TCP connection to localhost.
> How much less overhead would be incurred if this was changed to
> use Unix sockets instead (e.g. like /tmp/mysql.sock for MySQL)?
>=20
> Right now I made a few hacks to both the user-mode utilities and
> the test11 kernel to use Unix sockets instead of TCP/IP.
> Basically the kernel opens /tmp/tapx for each virtual ethernet device
> it detects, instead of opening a connection to localhost. The user-mode
> utilities make sockets on /tmp/tapx and use those instead of TCP/IP. This
> should cut down on overhead. Once I see how stable or unstable it
> is I'll make the diffs and send them to Jeff and/or the list.

Well, I may be wrong, but I think UNIX Socket handling is actualy
slower then network socket handling (expecialy when conserning the
lo interface).
Have you benckmarked it ?

[]s

--=20
 Rodrigo Barbosa (morcego)  - rod...@co...
 Conectiva R&D Team         - http://distro.conectiva.com.br
 "Quis custodiet custodes?" - http://www.conectiva.com

On Tue, Dec 05, 2000 at 06:36:52PM -0500, Jeff Dike wrote:
> rod...@co... said:
> > I wonder is this "doesn't take great pains to count every clock tick"
> > is not what messing with other points on the network code.=20
>=20
> I wonder too.  But you turned off the rate-limiter that seems relevant an=
d=20
> only got a small improvement.  So, unless you can find other time-sensiti=
ve=20
> things which are causing packet loss, I'd say that this isn't the real pr=
oblem.

I said small couse that only affect ICMP. If you take ICMP alone, the
improvement was a big one. Sorry if I didn't make myself clear about this
point.

> > But if you add to that other small delays, we can get a big delay on
> > the end.=20
>=20
> Maybe, but this seems like one big bug more than a bunch of little cooper=
ating=20
> ones.

I don't say we don't have a big bug. Bug I really think we have more then
one point slowing down performance.
The new patch I'll be sending next to uml-net-tools is a good one this time,
that gives some performance improvements.
Try it an you will notice it yourself.

--=20
 Rodrigo Barbosa (morcego)  - rod...@co...
 Conectiva R&D Team         - http://distro.conectiva.com.br
 "Quis custodiet custodes?" - http://www.conectiva.com

[sent to user-mode-linux-devel as well]

I'm messing with the network code at the moment. I noticed that
the virtual ethernet driver makes a TCP connection to localhost.
How much less overhead would be incurred if this was changed to
use Unix sockets instead (e.g. like /tmp/mysql.sock for MySQL)?

Right now I made a few hacks to both the user-mode utilities and
the test11 kernel to use Unix sockets instead of TCP/IP.
Basically the kernel opens /tmp/tapx for each virtual ethernet device
it detects, instead of opening a connection to localhost. The user-mode
utilities make sockets on /tmp/tapx and use those instead of TCP/IP. This
should cut down on overhead. Once I see how stable or unstable it
is I'll make the diffs and send them to Jeff and/or the list.

-----Original Message-----
From: use...@li...
[mailto:use...@li...]On Behalf Of
Rodrigo Barbosa (aka morcego)
Sent: Tuesday, December 05, 2000 12:32 PM
To: Jeff Dike
Cc: use...@li...
Subject: Re: [uml-user] [PATCH net-tools] debug improvements


On Tue, Dec 05, 2000 at 01:19:20AM -0500, Jeff Dike wrote:
> It's up to Jim Leu, but I would be inclined not to take this patch.  The
> reason is that you're chasing a big problem, and big problems have big
fixes
> (in the sense that you fix it and it makes a big difference).  So, if I
were
> you, I'd ignore all this little stuff until you find the real bug.  Also,
by
> fixing little things, you run the risk of getting enough small
improvements to
> add up to something that's barely acceptable.  Then you stop chasing the
real
> problem because things are now sort of OK.

I don't necessarily agree with you. I have seen big problems that only
needed small fixes.
But in this particular case, we only think that it's just one big problem.
But we can have a series of small problems that looks just like a big one.

> I think this particular patch is also a bad idea because it's good to be
able
> to turn on debugging in the standard executable with a command line
option,
> and not have to recompile it.  And if debugging is the default, as you
have
> it, then hardly anyone is going to turn it off, so the ifdefs aren't doing
> anything except cluttering the code.

Well, my proposal was to minimize changes. The code didn't have suport
for a debug flag, the debug option was hardcoded and turned on by default.
What I'm planning to the future (don't scream or cluebat me, please), is to
use multithreading to have debugging with very small performance hits.
I keep the main thread for routing, and another one for debugging, so I can
have async debug, causing minimal performance hit.

> I also have a hard time believing that those tests make any kind of
> performance difference.  And if it is measurable, then we're back to my
> argument above.

They have an effect, yes. Very small. But I'm not yet sure that we are
dealing
with just one big problem here.

> Cleaning up excessive output might be a good idea, but all of the
fprintf's
> that you've ifdefed look like fairly rare occurrences.

Not so rare. And fprintf is a samewhat costy instruction.

> In the interest of not being totally negative, I have to say that moving
that
> fork does look like a good idea.

Thanks.
And no, I don't think you are being totaly negative. Totaly negative is like
some people that simply refuses a patch, without telling why they did.
Once you explained your reason, I can work to improve it, remove problematic
points, and maybe come up with something better.

rod...@co... said:
> I wonder is this "doesn't take great pains to count every clock tick"
> is not what messing with other points on the network code. 

I wonder too.  But you turned off the rate-limiter that seems relevant and 
only got a small improvement.  So, unless you can find other time-sensitive 
things which are causing packet loss, I'd say that this isn't the real problem.

> But if you add to that other small delays, we can get a big delay on
> the end. 

Maybe, but this seems like one big bug more than a bunch of little cooperating 
ones.

				Jeff

On Tue, Dec 05, 2000 at 01:19:20AM -0500, Jeff Dike wrote:
> rod...@co... said:
> > Here is a patch that improved a little the debug turning on the
> > uml-net-tools package.
>=20
> It's up to Jim Leu, but I would be inclined not to take this patch.  The=
=20
> reason is that you're chasing a big problem, and big problems have big fi=
xes=20
> (in the sense that you fix it and it makes a big difference).  So, if I w=
ere=20
> you, I'd ignore all this little stuff until you find the real bug.  Also,=
 by=20
> fixing little things, you run the risk of getting enough small improvemen=
ts to=20
> add up to something that's barely acceptable.  Then you stop chasing the =
real=20
> problem because things are now sort of OK.

I don't necessarily agree with you. I have seen big problems that only
needed small fixes.
But in this particular case, we only think that it's just one big problem.
But we can have a series of small problems that looks just like a big one.

> I think this particular patch is also a bad idea because it's good to be =
able=20
> to turn on debugging in the standard executable with a command line optio=
n,=20
> and not have to recompile it.  And if debugging is the default, as you ha=
ve=20
> it, then hardly anyone is going to turn it off, so the ifdefs aren't doin=
g=20
> anything except cluttering the code.

Well, my proposal was to minimize changes. The code didn't have suport
for a debug flag, the debug option was hardcoded and turned on by default.
What I'm planning to the future (don't scream or cluebat me, please), is to
use multithreading to have debugging with very small performance hits.
I keep the main thread for routing, and another one for debugging, so I can
have async debug, causing minimal performance hit.

> I also have a hard time believing that those tests make any kind of=20
> performance difference.  And if it is measurable, then we're back to my=
=20
> argument above.

They have an effect, yes. Very small. But I'm not yet sure that we are deal=
ing
with just one big problem here.

> Cleaning up excessive output might be a good idea, but all of the fprintf=
's=20
> that you've ifdefed look like fairly rare occurrences.

Not so rare. And fprintf is a samewhat costy instruction.

> In the interest of not being totally negative, I have to say that moving =
that=20
> fork does look like a good idea.

Thanks.
And no, I don't think you are being totaly negative. Totaly negative is like
some people that simply refuses a patch, without telling why they did.
Once you explained your reason, I can work to improve it, remove problematic
points, and maybe come up with something better.

[]s


--=20
 Rodrigo Barbosa (morcego)  - rod...@co...
 Conectiva R&D Team         - http://distro.conectiva.com.br
 "Quis custodiet custodes?" - http://www.conectiva.com

On Mon, Dec 04, 2000 at 11:20:04PM -0500, Jeff Dike wrote:
> rod...@co... said:
> > Lets just say that the package has to get copied a lot of times before
> > anything is done.
> That's in the generic kernel, and that code ought to be exactly the same =
as a=20
> native kernel.  So, I don't believe that there's a problem there.

It's a problem, but not a bug. Think I didn't make myself clear on this=20
point.

> > 	Well, the kernel has a icmp_echo rate delimiter. For some unknown
> > reason, it's not working well on uml (still studing why).
> > 	The workaround is to turn it off, with the commando:
> > 	# echo 0 > /proc/sys/net/ipv4/icmp_echoreply_rate=20
> If a packet rate limiter is firing, the reason might be that uml currentl=
y=20
> doesn't take great pains to count every clock tick.  So, if it's busy, it=
 will=20
> lose time, and rate limiters might fire when they shouldn't.

I wonder is this "doesn't take great pains to count every clock tick" is
not what messing with other points on the network code.


> > One thing that just came to my mind is that kernel 2.2 (which I use on
> > my host system) networking subsystem is simply crap. So, maybe thats
> > part of the problem.
> I don't believe this either.  The 2.2 network may not be great, but pingi=
ng a=20
> little virtual machine isn't exactly hard work.

But if you add to that other small delays, we can get a big delay on the
end.

> > All in all, something is really amiss.
> Yup.  When you figure out why packets are being dropped, we might know wh=
at's=20
> wrong with uml.

Yup. I'm still tracking that ... But I still have a lot to look at. *sign*

--=20
 Rodrigo Barbosa (morcego)  - rod...@co...
 Conectiva R&D Team         - http://distro.conectiva.com.br
 "Quis custodiet custodes?" - http://www.conectiva.com

rod...@co... said:
> Here is a patch that improved a little the debug turning on the
> uml-net-tools package.

It's up to Jim Leu, but I would be inclined not to take this patch.  The 
reason is that you're chasing a big problem, and big problems have big fixes 
(in the sense that you fix it and it makes a big difference).  So, if I were 
you, I'd ignore all this little stuff until you find the real bug.  Also, by 
fixing little things, you run the risk of getting enough small improvements to 
add up to something that's barely acceptable.  Then you stop chasing the real 
problem because things are now sort of OK.

I think this particular patch is also a bad idea because it's good to be able 
to turn on debugging in the standard executable with a command line option, 
and not have to recompile it.  And if debugging is the default, as you have 
it, then hardly anyone is going to turn it off, so the ifdefs aren't doing 
anything except cluttering the code.

I also have a hard time believing that those tests make any kind of 
performance difference.  And if it is measurable, then we're back to my 
argument above.

Cleaning up excessive output might be a good idea, but all of the fprintf's 
that you've ifdefed look like fairly rare occurrences.

In the interest of not being totally negative, I have to say that moving that 
fork does look like a good idea.

				Jeff

rod...@co... said:
> Lets just say that the package has to get copied a lot of times before
> anything is done.

That's in the generic kernel, and that code ought to be exactly the same as a 
native kernel.  So, I don't believe that there's a problem there.

> 	Well, the kernel has a icmp_echo rate delimiter. For some unknown
> reason, it's not working well on uml (still studing why).
> 	The workaround is to turn it off, with the commando:
> 	# echo 0 > /proc/sys/net/ipv4/icmp_echoreply_rate 

If a packet rate limiter is firing, the reason might be that uml currently 
doesn't take great pains to count every clock tick.  So, if it's busy, it will 
lose time, and rate limiters might fire when they shouldn't.

> One thing that just came to my mind is that kernel 2.2 (which I use on
> my host system) networking subsystem is simply crap. So, maybe thats
> part of the problem.

I don't believe this either.  The 2.2 network may not be great, but pinging a 
little virtual machine isn't exactly hard work.

> All in all, something is really amiss.

Yup.  When you figure out why packets are being dropped, we might know what's 
wrong with uml.

				Jeff

mi...@li... said:
> Mounted devfs on /dev 
> Kernel panic: Unexpectedly got signal 4 in signals 

This is very bogus.  Something's wrong with the kernel.  That's an illegal 
instruction.

I take it you're running a kernel you got from my site?  If you want to give 
me enough information to figure out what's happening, you'll need to build a 
debuggable kernel from source.

Briefly, what you'll need to do is:
	gdb the tracing thread
	get the pid of what hit the illegal instruction
	detach it from the tracing thread
	gdb that thread
	get a backtrace

If you want more details on the exact procedure, let me know, and I'll be 
happy to provide them.

				Jeff

Here is a patch that improved a little the debug turning on the uml-net-too=
ls
package.
The motivation is that, once debug must be set on compilation time,
there is not need to have the debug code lying around during
execution unless we need it, and so avoid a series of costy if's.

Also, it move the fork() call a little down the code, for better error
handling. It should be only be executed just before the main loop.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3DCUT=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
diff -urN uml-net-tools-0.005.old/Makefile uml-net-tools-0.005/Makefile
--- uml-net-tools-0.005.old/Makefile	Mon Jul 24 15:45:32 2000
+++ uml-net-tools-0.005/Makefile	Tue Dec  5 00:36:30 2000
@@ -1,5 +1,6 @@
 CC =3D gcc
-CFLAGS =3D -Wall -ggdb
+# Define DEBUG=3D0 below if you don't want debugging enable
+CFLAGS =3D -Wall -ggdb -DDEBUG=3D1
 UTIL_OBJS =3D um_eth_net_util.o um_eth_net_output.o um_eth_net_phy.o um_et=
h_net_tap.o
=20
 all: um_eth_net_util um_eth_net_set
diff -urN uml-net-tools-0.005.old/um_eth_net.h uml-net-tools-0.005/um_eth_n=
et.h
--- uml-net-tools-0.005.old/um_eth_net.h	Mon Jul 24 15:42:47 2000
+++ uml-net-tools-0.005/um_eth_net.h	Tue Dec  5 00:53:25 2000
@@ -1,6 +1,10 @@
 #ifndef _UM_ETH_NET_H
 #define _UM_ETH_NET_H
=20
+#ifndef DEBUG
+#define DEBUG 1
+#endif
+
 #define UM_ETH_NET_MAX_PACKET	1544
 #define UM_ETH_NET_PORT		5299
 #define UM_ETH_NET_DEFAULT_NUM	100
diff -urN uml-net-tools-0.005.old/um_eth_net_output.c uml-net-tools-0.005/u=
m_eth_net_output.c
--- uml-net-tools-0.005.old/um_eth_net_output.c	Mon Jul 24 15:42:47 2000
+++ uml-net-tools-0.005/um_eth_net_output.c	Tue Dec  5 00:52:59 2000
@@ -9,7 +9,6 @@
 extern void dump_packet(unsigned char *buffer,int size,int term);
=20
 extern struct connection_data* uml_connection[];
-extern int debug;
=20
 int packet_output(int in,unsigned char *hbuf,int max_fd) {
   struct connection_data *conn_in,*conn_out;
@@ -21,11 +20,11 @@
=20
   conn_in =3D uml_connection[in];
=20
-  if(debug) {
+#if DEBUG
     fprintf(stderr,"%02d %02d ->",in,conn_in->net_num);
     dump_packet(buf,ntohl(hdr[1]),0);
     fprintf(stderr," ->");
-  }
+#endif
=20
   for(out=3D0;out<=3Dmax_fd;out++) {
     conn_out =3D uml_connection[out];
@@ -34,7 +33,9 @@
     if((out !=3D in) &&
       (conn_out->net_num =3D=3D conn_in->net_num)) {
=20
-      if(debug && conn_out->stype !=3D SOCKET_LISTEN) fprintf(stderr," %02=
d",out);
+#if DEBUG
+      if(conn_out->stype !=3D SOCKET_LISTEN) fprintf(stderr," %02d",out);
+#endif
       switch(conn_out->stype) {
         case SOCKET_LISTEN:
         { break; }
@@ -44,7 +45,9 @@
           retval =3D write(out,hbuf,ntohl(hdr[1]) + UM_ETH_NET_HDR_SIZE);
           if(retval <=3D 0) {
             if(errno =3D=3D EAGAIN || errno =3D=3D EINTR) {
+#if DEBUG
               fprintf(stderr,"out again1\n");
+#endif
               goto try_again1;
             }
             close(out);
@@ -58,7 +61,9 @@
           retval =3D write(out,buf,ntohl(hdr[1]));
           if(retval <=3D 0) {
             if(errno =3D=3D EAGAIN || errno =3D=3D EINTR) {
+#if DEBUG
               fprintf(stderr,"out again2\n");
+#endif
               goto try_again2;
             }
             close(out);
@@ -73,7 +78,9 @@
           retval =3D write(out,buf,ntohl(hdr[1])+2);
           if(retval <=3D 0) {
             if(errno =3D=3D EAGAIN || errno =3D=3D EINTR) {
+#if DEBUG
               fprintf(stderr,"out again3\n");
+#endif
               goto try_again3;
             }
             close(out);
@@ -84,6 +91,8 @@
       }
     }
   }
-  if(debug) fprintf(stderr,"\n");
+#if DEBUG
+  fprintf(stderr,"\n");
+#endif
   return count;
 }
diff -urN uml-net-tools-0.005.old/um_eth_net_util.c uml-net-tools-0.005/um_=
eth_net_util.c
--- uml-net-tools-0.005.old/um_eth_net_util.c	Mon Jul 24 15:42:47 2000
+++ uml-net-tools-0.005/um_eth_net_util.c	Tue Dec  5 00:53:06 2000
@@ -35,7 +35,6 @@
         FD_SET(y,&perm);
=20
 struct connection_data* uml_connection[1024];
-int debug =3D 1;
=20
 void dump_packet(unsigned char *buffer,int size,int term) {
   int i;
@@ -64,8 +63,6 @@
   int len;
   int in;
=20
-  if(!debug) if(fork()) exit(0);
-
   memset(uml_connection,0,sizeof(uml_connection));
   memset(&addr,0,sizeof(struct sockaddr));
   FD_ZERO(&perm);
@@ -131,6 +128,10 @@
     }
   }
=20
+#if !(DEBUG)
+  if(fork()) exit(0);
+#endif
+
   while(1) {
 loop:
     memcpy(&temp,&perm,sizeof(fd_set));
@@ -142,7 +143,9 @@
         switch(conn_in->stype) {
           case SOCKET_LISTEN:
           {
-            if(debug) fprintf(stderr,"connect\n");
+#if DEBUG
+            fprintf(stderr,"connect\n");
+#endif
             new_fd =3D accept(in,(struct sockaddr*)&addr,&len);
 #if 0
             if(fcntl(new_fd,F_SETFL,O_ASYNC|O_NONBLOCK) < 0){
@@ -164,14 +167,20 @@
             result =3D read(in,header,UM_ETH_NET_HDR_SIZE);
             if(result < 0) {
               if(errno =3D=3D EINTR || errno =3D=3D EAGAIN) {
+#if DEBUG
                 fprintf(stderr,"again1\n");
+#endif
                 goto try_again1;
               }
+#if DEBUG
               fprintf(stderr,"close\n");
+#endif
               CLOSE_CONNECTION(in);
               goto loop;
             } else if(result =3D=3D 0) {
+#if DEBUG
               fprintf(stderr,"close\n");
+#endif
               CLOSE_CONNECTION(in);
               goto loop;
             } else {
@@ -180,14 +189,20 @@
               result =3D read(in,buffer,ntohl(header[1]));
               if(result < 0) {
                 if(errno =3D=3D EINTR || errno =3D=3D EAGAIN) {
+#if DEBUG
                   fprintf(stderr,"again2\n");
+#endif
                   goto try_again2;
                 }
+#if DEBUG
                 fprintf(stderr,"close\n");
+#endif
                 CLOSE_CONNECTION(in);
                 goto loop;
               } else if(result =3D=3D 0) {
+#if DEBUG
                 fprintf(stderr,"close\n");
+#endif
                 CLOSE_CONNECTION(in);
                 goto loop;
               } else {
@@ -198,7 +213,9 @@
=20
                     memcpy(&temp,buffer,sizeof(temp));
                     conn_in->net_num =3D ntohl(temp);
-                    if(debug) fprintf(stderr,"mgmt: %d is now on %d\n",in,=
conn_in->net_num);
+#if DEBUG
+                    fprintf(stderr,"mgmt: %d is now on %d\n",in,conn_in->n=
et_num);
+#endif
                     break;
                   }
                   case PACKET_DATA:
@@ -217,10 +234,14 @@
             result =3D read(in,buffer,UM_ETH_NET_MAX_PACKET);
             if(result <=3D 0) {
               if(errno =3D=3D EINTR || errno =3D=3D EAGAIN) {
+#if DEBUG
                 fprintf(stderr,"again3\n");
+#endif
                 goto try_again3;
               }
-              if(debug) fprintf(stderr,"phy close\n");
+#if DEBUG
+              fprintf(stderr,"phy close\n");
+#endif
               CLOSE_CONNECTION(in);
               goto loop;
             } else {
@@ -236,10 +257,14 @@
             result =3D read(in,buffer,UM_ETH_NET_MAX_PACKET+2);
             if(result <=3D 0) {
               if(errno =3D=3D EINTR || errno =3D=3D EAGAIN) {
+#if DEBUG
                 fprintf(stderr,"again4\n");
+#endif
                 goto try_again4;
               }
-              if(debug) fprintf(stderr,"tap close\n");
+#if DEBUG
+              fprintf(stderr,"tap close\n");
+#endif
               CLOSE_CONNECTION(in);
               goto loop;
             } else {
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3DCUT=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D

--=20
 Rodrigo Barbosa (morcego)  - rod...@co...
 Conectiva R&D Team         - http://distro.conectiva.com.br
 "Quis custodiet custodes?" - http://www.conectiva.com

Well, here is a collection of things that may be useful, based on the=20
problems I had with uml.

First, I started with the most simples configuration, trying to do
networking with the slip-based interface.

That was a mess. The SLIP protocol is not good for this kind of stuff.
NFS was simply impossible to use. Hangups all around. DON'T USE IT.
I would suggest having this option removed. If all you want
is telnet/ftp, it's ok (but not good). Anything that need a little
more network resources gets messed up.

Then, my saga with the Virtual Ethernet started. Here is a little list
of the problems with the solutions (or workarounds) I gathered:

1) Networking was too slow

	One thing that helped (but not solved it) was to run um_eth_net_util
as root with priority -1. It helped (about 10-20% better).

	To do it: nice -n -1 um_eth_net_util tap0 100

2) NFS still haging, and making UML hang

	Looks like I was having problems with the kernel itself.
On my first tests, I was using a custom kernel, compiled with
gcc 2.95.2/2.95.3. If you did that, or are planing to, forget about
it. It's not worth.
	The solution (partial, you will know why on item 4) was to
use egcs 1.1.2, which is actualy the recomended compiler for the kernel.
On RedHat (6.0 and on, I'm sure), it's called kgcc. Same on Conectiva
Linux 6.0. Don't know on other distributions.

	SHORT: Don't compile the kernel with gcc. Use egcs 1.1.2

3) Something around 90% of the incoming icmp_echo (ping) packages where bei=
ng
   dropped

	Well, the kernel has a icmp_echo rate delimiter. For some unknown
reason, it's not working well on uml (still studing why).
	The workaround is to turn it off, with the commando:

	# echo 0 > /proc/sys/net/ipv4/icmp_echoreply_rate

	Then, the package lossing almost disapered. Another improvement.

	SHORT: Disable the icmp_echoreply_rate feature

4) Networking still slowwwwwww

	We have 2 separated problems here. The first is the way uml works.
It cannot be changed, so I'll not get too deep on it. Lets just say that
the package has to get copied a lot of times before anything is done.

	The second, is that something is slowing things even more. Running
both uml and um_eth_net_util with higher priority didn't give the results
it should have (although I did get better results). Something is not
working the way it should. This is something that needes to be
worked. Maybe it's the same thing that is giving problems with=20
icmp_echoreply_rate, but maybe it's something else.

	One thing that just came to my mind is that kernel 2.2 (which I
use on my host system) networking subsystem is simply crap. So, maybe
thats part of the problem. Maybe it's the tap0 driver that is not ok.
I really need to try using kernel 2.4 on the host system to see what I
get.

	Also, I'm planning to do some profiling on the um_eth_net_util
utility. Something tells me it has something to do with it. One thing
I know for sure is that writing that dump to console si not fast. I
think it wouldn't matter if it was done using a separated thread, but
it doesn't seens to be the case. I'll work on implementing a flag
to disable this output, and to make it run as a daemon (fork() is your
friend :-)), and see if it speeds things up. I have a felling it will.

	All in all, something is really amiss. I'll be working on it.
Jeff Dike is being so so so so so nice with me, answering a lot of
stupid questions I'm making without complaining, helping me every
step of the way. I'm really excited to contribute.

	As an ending note, I would like to thanks Jeff for the great
work and for stepping forward to create UML.

See ya



--=20
 Rodrigo Barbosa (morcego)  - rod...@co...
 Conectiva R&D Team         - http://distro.conectiva.com.br
 "Quis custodiet custodes?" - http://www.conectiva.com

I'll explain the procedure I use here. I'll do it using the IP address
of your setup, to make it easy for you.
Just remember I'm using the rounting tricks to make my uml machine
visible to the rest of my network, so maybe a few steps wouldn't be
needed for you.

First, on host:

host# ifconfig eth0 arp
host# ifconfig tap0 arp
host# ifconfig tap0 192.168.74.22 netmask 255.255.255.0 up
host# arp -s -i tap0 192.168.74.32 C0:A8:4A:20:00:00 pub
host# um_eth_net_util tap0 100


No, I would boot the uml machine, and login.

uml# ifconfig eth0 hw ether C0:A8:4A:20:00:00 arp
uml# ifconfig eth0 192.168.74.34 netmask 255.255.255.255 up
                                         ^^^^^^^^^^^^^^^
uml# route add -host 192.168.74.22 dev eth0
uml# route add default gw 192.168.74.22

And thats it. That should do the trick. Notice that I setted up the eth0
interface with netmask 255.255.255.255, and that I had to add 2 routes
to the routing table.

Another thing I would suggest is running um_eth_net_util as root (I
don't know if it works as running as a regular users), with high
priority. It's not such a cpu intensive process, so it should not
interfere too much with your other processes. To do it:

host# nice -n -1 um_eth_net_util tap0 100

or, as I do here (more priority yet):

host# nice -n -5 um_eth_net_util tap0 100

[]s

On Tue, Dec 05, 2000 at 12:07:42AM +0100, Christian Laursen wrote:
> Hello guys.
>=20
> I still didn't manage to get the uml networking working
> to my satisfaction. I believe I'm close now, though. :)
>=20
> I'm trying to use the virtual ethernet device through the
> ethertap device.
>=20
> This is my ifconfig on the host:
>=20
> eth0      Link encap:Ethernet  HWaddr 00:01:02:0D:E5:DD =20
>           inet addr:192.168.74.22  Bcast:192.168.74.255  Mask:255.255.255=
.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:665006 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:359896 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100=20
>           Interrupt:11 Base address:0xd400=20
>=20
> lo        Link encap:Local Loopback =20
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           UP LOOPBACK RUNNING  MTU:3924  Metric:1
>           RX packets:6601 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:6601 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0=20
>=20
> tap0      Link encap:Ethernet  HWaddr FE:FD:00:00:00:00 =20
>           inet addr:192.168.74.22  Bcast:192.168.74.255  Mask:255.255.255=
.0
>           UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:388 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0=20
>           Interrupt:5=20
>=20
>=20
> And my routing table:
>=20
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use I=
face
> uml             *               255.255.255.255 UH    0      0        0 t=
ap0
> x               *               255.255.255.255 UH    0      0        0 e=
th0
> 192.168.74.0    *               255.255.255.0   U     0      0        0 e=
th0
> 192.168.74.0    *               255.255.255.0   U     0      0        0 t=
ap0
> 127.0.0.0       *               255.0.0.0       U     0      0        0 lo
> default         server          0.0.0.0         UG    0      0        0 e=
th0
>=20
>=20
> This is ifconfig on uml:
>=20
> eth0      Link encap:Ethernet  HWaddr C0:A8:4A:20:00:00 =20
>           inet addr:192.168.74.32  Bcast:192.168.74.255  Mask:255.255.255=
.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:21 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100=20
>           Interrupt:4=20
>=20
> lo        Link encap:Local Loopback =20
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           UP LOOPBACK RUNNING  MTU:3904  Metric:1
>           RX packets:6 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0=20
>=20
>=20
> This is the routing table on uml:
>=20
> 192.168.74.0    *               255.255.255.0   U     0      0        0 e=
th0
> 127.0.0.0       *               255.0.0.0       U     0      0        0 lo
> default         x               0.0.0.0         UG    0      0        0 e=
th0
>=20
>=20
> I have started um_eth_net_util with the parameters tap0 and 100.
>=20
> I have chosen the same IP address for both tap0 and eth0 on the host acco=
rding
> to an earlier mail here by William Stearns.
>=20

--=20
 Rodrigo Barbosa (morcego)  - rod...@co...
 Conectiva R&D Team         - http://distro.conectiva.com.br
 "Quis custodiet custodes?" - http://www.conectiva.com

Hello guys.

I still didn't manage to get the uml networking working
to my satisfaction. I believe I'm close now, though. :)

I'm trying to use the virtual ethernet device through the
ethertap device.

This is my ifconfig on the host:

eth0      Link encap:Ethernet  HWaddr 00:01:02:0D:E5:DD  
          inet addr:192.168.74.22  Bcast:192.168.74.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:665006 errors:0 dropped:0 overruns:0 frame:0
          TX packets:359896 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          Interrupt:11 Base address:0xd400 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:3924  Metric:1
          RX packets:6601 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6601 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 

tap0      Link encap:Ethernet  HWaddr FE:FD:00:00:00:00  
          inet addr:192.168.74.22  Bcast:192.168.74.255  Mask:255.255.255.0
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:388 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          Interrupt:5 


And my routing table:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
uml             *               255.255.255.255 UH    0      0        0 tap0
x               *               255.255.255.255 UH    0      0        0 eth0
192.168.74.0    *               255.255.255.0   U     0      0        0 eth0
192.168.74.0    *               255.255.255.0   U     0      0        0 tap0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         server          0.0.0.0         UG    0      0        0 eth0


This is ifconfig on uml:

eth0      Link encap:Ethernet  HWaddr C0:A8:4A:20:00:00  
          inet addr:192.168.74.32  Bcast:192.168.74.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:21 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          Interrupt:4 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:3904  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 


This is the routing table on uml:

192.168.74.0    *               255.255.255.0   U     0      0        0 eth0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         x               0.0.0.0         UG    0      0        0 eth0


I have started um_eth_net_util with the parameters tap0 and 100.


I have chosen the same IP address for both tap0 and eth0 on the host according
to an earlier mail here by William Stearns.

I played around a bit with tcpdump, and I found out that packets get through
allright from the host to uml, but seem to get garbled the other way.

This is what I get from tcpdump on the host (When trying to ping uml from the host):

00:03:32.387815 > arp who-has uml tell x (fe:fd:0:0:0:0)
00:03:32.389400 > 0:0:0:0:0:0 > c0:a8:4a:20:0:0 null I (s=4,r=0,R) len=24
                         0604 0002 c0a8 4a20 0000 c0a8 4a20 fefd
                         0000 0000 c0a8 4a16
00:03:33.381472 > arp who-has uml tell x (fe:fd:0:0:0:0)
00:03:33.382872 > 0:0:0:0:0:0 > c0:a8:4a:20:0:0 null I (s=4,r=0,R) len=24
                         0604 0002 c0a8 4a20 0000 c0a8 4a20 fefd
                         0000 0000 c0a8 4a16
00:03:34.380981 > arp who-has uml tell x (fe:fd:0:0:0:0)
00:03:34.382416 > 0:0:0:0:0:0 > c0:a8:4a:20:0:0 null I (s=4,r=0,R) len=24
                         0604 0002 c0a8 4a20 0000 c0a8 4a20 fefd
                         0000 0000 c0a8 4a16
00:03:35.380698 > arp who-has uml tell x (fe:fd:0:0:0:0)
00:03:35.382710 > 0:0:0:0:0:0 > c0:a8:4a:20:0:0 null I (s=4,r=0,R) len=24
                         0604 0002 c0a8 4a20 0000 c0a8 4a20 fefd
                         0000 0000 c0a8 4a16
00:03:36.379961 > arp who-has uml tell x (fe:fd:0:0:0:0)
00:03:36.381242 > 0:0:0:0:0:0 > c0:a8:4a:20:0:0 null I (s=4,r=0,R) len=24
                         0604 0002 c0a8 4a20 0000 c0a8 4a20 fefd
                         0000 0000 c0a8 4a16
00:03:37.379466 > arp who-has uml tell x (fe:fd:0:0:0:0)
00:03:37.381427 > 0:0:0:0:0:0 > c0:a8:4a:20:0:0 null I (s=4,r=0,R) len=24
                         0604 0002 c0a8 4a20 0000 c0a8 4a20 fefd
                         0000 0000 c0a8 4a16

And this is from tcpdump on uml:

00:03:32.432299 B arp who-has uml tell x
00:03:32.432299 > arp reply uml (c0:a8:4a:20:0:0) is-at c0:a8:4a:20:0:0 (fe:fd:0:0:0:0)
00:03:33.381557 B arp who-has uml tell x
00:03:33.381557 > arp reply uml (c0:a8:4a:20:0:0) is-at c0:a8:4a:20:0:0 (fe:fd:0:0:0:0)
00:03:34.431085 B arp who-has uml tell x
00:03:34.431085 > arp reply uml (c0:a8:4a:20:0:0) is-at c0:a8:4a:20:0:0 (fe:fd:0:0:0:0)
00:03:35.430550 B arp who-has uml tell x
00:03:35.430550 > arp reply uml (c0:a8:4a:20:0:0) is-at c0:a8:4a:20:0:0 (fe:fd:0:0:0:0)
00:03:36.380081 B arp who-has uml tell x
00:03:36.380081 > arp reply uml (c0:a8:4a:20:0:0) is-at c0:a8:4a:20:0:0 (fe:fd:0:0:0:0)
00:03:37.379595 B arp who-has uml tell x
00:03:37.379595 > arp reply uml (c0:a8:4a:20:0:0) is-at c0:a8:4a:20:0:0 (fe:fd:0:0:0:0)

This is the output from um_eth_net_util:

04 100 -> ff ff ff ff ff ff fe fd 00 00 00 00 08 06 00 01 -> 05
05 100 -> fe fd 00 00 00 00 c0 a8 4a 20 00 00 08 06 00 01 -> 04
04 100 -> ff ff ff ff ff ff fe fd 00 00 00 00 08 06 00 01 -> 05
05 100 -> fe fd 00 00 00 00 c0 a8 4a 20 00 00 08 06 00 01 -> 04
04 100 -> ff ff ff ff ff ff fe fd 00 00 00 00 08 06 00 01 -> 05
05 100 -> fe fd 00 00 00 00 c0 a8 4a 20 00 00 08 06 00 01 -> 04
04 100 -> ff ff ff ff ff ff fe fd 00 00 00 00 08 06 00 01 -> 05
05 100 -> fe fd 00 00 00 00 c0 a8 4a 20 00 00 08 06 00 01 -> 04


If anyone could give me a hint to what I may be doing wrong, I would
be a happy man. :)

Thanks in advance.

-- 
Best regards
    Christian Laursen

Hi folks,

	I'm excited about the possibilities for uml, but I'm having a hard
time getting started. I've downloaded two packages - 

root_fs_redhat_7.0_big.bz2
rh-package-2.4.0-test11.tar.bz2
 
	(I hope this is right). My host system is a freshly installed
redhat 7.0 (kernel 2.2.16). I've uncompressed everything and have that
big root_fs file in the same directory with linux, then I go to
./run_linux and I get the following:

---<snip>---
serial line 0 assigned pty /dev/ptyp1
ssl receive thread is pid 1021
devfs: v0.102 (20000622) Richard Gooch (rg...@at...)
devfs: devfs_debug: 0x0
devfs: boot_options: 0x0
VFS: Mounted root (ext2 filesystem) readonly.
Mounted devfs on /dev
Kernel panic: Unexpectedly got signal 4 in signals

	Is this the right combonation of software or did I really blow
something here? I'm not on the list, if you could please CC: me in your
response, thank you....

Mike Ireton

On Mon, Dec 04, 2000 at 03:57:54PM -0500, Jeff Dike wrote:
> rod...@co... said:
> > I tried NFS, which is very sensible to this kind of stuff. And got
> > lots of hangs.=20
> So, NFS is known to be sensitive to packet loss and you'd expect it to be=
have=20
> badly when it's in a lossy environment?

I know. That was my point. Telnet, ftp, ssh et al are not so sensitive,
so it works fine.

> In that case, it looks like we need to figure out why UML is losing packe=
ts. =20
> If you (or anyone else who's more familiar with the netword code than I a=
m)=20
> wants to chase this, I would find where packets are dropped, stick a=20
> breakpoint there, and see why it's deciding to drop packets.  That ought =
to=20
> point at things that I'm doing wrong (or could do better).

I'm working on that with a few kernel hackers friends of mine ...

[]s

--=20
 Rodrigo Barbosa (morcego)  - rod...@co...
 Conectiva R&D Team         - http://distro.conectiva.com.br
 "Quis custodiet custodes?" - http://www.conectiva.com

rod...@co... said:
> I tried NFS, which is very sensible to this kind of stuff. And got
> lots of hangs. 

So, NFS is known to be sensitive to packet loss and you'd expect it to behave 
badly when it's in a lossy environment?

In that case, it looks like we need to figure out why UML is losing packets.  
If you (or anyone else who's more familiar with the netword code than I am) 
wants to chase this, I would find where packets are dropped, stick a 
breakpoint there, and see why it's deciding to drop packets.  That ought to 
point at things that I'm doing wrong (or could do better).

				Jeff

On Mon, Dec 04, 2000 at 12:24:37PM -0500, Jeff Dike wrote:
> Can you ping from the uml without packet loss?

Yup. No packet loss at all.

> Have you tried other network things (telnet, http, ftp, etc)?

There are not protocols where you would notice anything except some delay
in this scenary.
I tried NFS, which is very sensible to this kind of stuff. And got lots of
hangs.

--=20
 Rodrigo Barbosa (morcego)  - rod...@co...
 Conectiva R&D Team         - http://distro.conectiva.com.br
 "Quis custodiet custodes?" - http://www.conectiva.com

Can you ping from the uml without packet loss?

Have you tried other network things (telnet, http, ftp, etc)?

				Jeff