On Wed, Nov 16, 2005 at 05:18:48PM +0100, Grzegorz Nosek wrote:
> 2005/11/14, Björn Steinbrink <B.Steinbrink@gmx.de>:
> > ~ $ gcc --version
> > gcc (GCC) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)
> > Copyright (C) 2004 Free Software Foundation, Inc.
> > Kernel config is attached (for the vs2.1 kernel, the others were the same
> > except for options not available in earlier version).
> > Network setup is like this:
> > 1: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
> > link/ether 00:e0:81:55:09:b0 brd ff:ff:ff:ff:ff:ff
> > inet 192.168.0.101/24 brd 192.168.0.255 scope global eth0
> > inet 192.168.100.100/24 brd 192.168.100.255 scope global eth0
> > 2: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
> > 192.168.0.101 is the host's address, 192.168.100.100 is the guests
> > address.
> > HTH
> > Björn
> I took the plunge and changed:
> - mainline from 220.127.116.11 to 18.104.22.168
> - vserver from 2.1.0-rc4 to 2.1.0-rc7
> - gcc from 3.3.5 to 3.4.4
> - cpu from athlon-xp to amd64 (still i386 arch though)
> So far, so good. It doesn't seem to crash anymore (though it'll need a
> few more days before declaring success), no weird HTB issues, but
> (again... :) ) I found a strange behaviour with /proc/loadavg within
> v831: 766247.51 5805.21 96888.33 -8215/41 5845
> d829: 222347.93 348850.89 612445.29 -7206/25 5857
> v830: 116343.68 992898.43 661824.04 -65902/77 5869
> It seems that nr_running has gone weird (it can be seen in
> /proc/virtual/*/cvirt too).
> Have there been any patches regarding this feature?
not really, but it was reported once or twice and
we know of this issue, we just cannot reproduce it
right now (i.e. simple test case)
> While on the host, I get quite normal numbers:
> 0.95 1.03 1.32 3/250 5904
> On a brighter note, the machine is rock stable and is humming along
so we can probably consider the previous issues a
hardware failure/incompatibility and not linux-vserver
related at all, right?
> Another box (dual Xeon) just can't be overloaded (whatever we'd throw
> on it, it'd just ask for more), available disk space became the
> limiting factor before CPU power (for the first time here AFAIK).
yes, interesting report ...
> I'd like to thank the VServer team for doing such a fine job. My
> respect and appreciation.
in behalf of the Linux-VServer team, I thank you for
providing feedback, as we appreciate that very much.
> Best regards,
> Grzegorz Nosek
> Vserver mailing list
Vserver mailing list
Received on Thu Nov 17 05:59:41 2005