From owner-freebsd-emulation@FreeBSD.ORG Mon Jul 23 11:07:03 2012 Return-Path: Delivered-To: emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FB641065731 for ; Mon, 23 Jul 2012 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 595D48FC1D for ; Mon, 23 Jul 2012 11:07:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6NB73Ou089862 for ; Mon, 23 Jul 2012 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6NB72En089860 for emulation@FreeBSD.org; Mon, 23 Jul 2012 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Jul 2012 11:07:02 GMT Message-Id: <201207231107.q6NB72En089860@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: emulation@FreeBSD.org Cc: Subject: Current problem reports assigned to emulation@FreeBSD.org X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 11:07:03 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o ports/169988 emulation [PATCH] Update sysutils/linux-procps to 3.2.7; also up o ports/169896 emulation [patch] audio/linux-f10-alsa-lib: use OSS plugin by de o ports/169702 emulation [patch] graphics/linux-f10-tiff: fix packing list 3 problems total. From owner-freebsd-emulation@FreeBSD.ORG Mon Jul 23 11:07:13 2012 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20230106566C for ; Mon, 23 Jul 2012 11:07:13 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E4D098FC17 for ; Mon, 23 Jul 2012 11:07:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6NB7CMC089990 for ; Mon, 23 Jul 2012 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6NB7C53089988 for freebsd-emulation@FreeBSD.org; Mon, 23 Jul 2012 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Jul 2012 11:07:12 GMT Message-Id: <201207231107.q6NB7C53089988@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-emulation@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 11:07:13 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/169814 emulation [linux] ptrace is broken in Linux emulation o kern/169805 emulation [linux] utime() syscall does not work in linuxulator o kern/159646 emulation [linux] [patch] bump Linux version in linuxulator f kern/156691 emulation [vmware] [panic] panic when using hard disks as RAW de o kern/156353 emulation [ibcs2] ibcs2 binaries that execute on 4.x not working o kern/155577 emulation [boot] BTX halted after install. Reboot during install o kern/155040 emulation [linux] [patch] Linux recvfrom doesn't handle proto fa o kern/153990 emulation [hyper-v]: Will not install into Hyper-V on Server 200 o kern/153887 emulation [linux] Linux emulator not understand STB_GNU_UNIQUE b o kern/153243 emulation [ibcs2] Seg fault whne running COFF binary using iBCS2 o kern/151714 emulation [linux] print/acroread9 not usable due to lack of supp a bin/150262 emulation [patch] truss(1) -f doesn't follow descendants of the a kern/150186 emulation [parallels] [panic] Parallels Desktop: CDROM disconnec o ports/148097 emulation [patch] suggested addition to linux_base-* packages to o ports/148096 emulation emulators/linux_base-* can not be built from ports on o kern/147793 emulation [vmware] [panic] cdrom handling, panic, possible race o kern/146237 emulation [linux] Linux binaries not reading directories mounted p kern/144584 emulation [linprocfs][patch] bogus values in linprocfs o ports/142837 emulation [patch] emulators/linux_base-* packages fails to insta o kern/140156 emulation [linux] cdparanoia fails to read drive data f kern/138944 emulation [parallels] [regression] Parallels no longer works in o kern/138880 emulation [linux] munmap segfaults after linux_mmap2 stresstest o ports/135337 emulation [PATCH] emulators/linux_base-f10: incorrect bash usage s kern/133144 emulation [linux] linuxulator 2.6 crashes with nvidias libGL.so. o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o kern/86619 emulation [linux] linux emulator interacts oddly with cp a kern/72920 emulation [linux] path "prefixing" is not done on unix domain so o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/36952 emulation [patch] [linux] ldd(1) command of linux does not work o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 32 problems total. From owner-freebsd-emulation@FreeBSD.ORG Tue Jul 24 11:34:05 2012 Return-Path: Delivered-To: emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45576106564A for ; Tue, 24 Jul 2012 11:34:05 +0000 (UTC) (envelope-from rdespres@indolore.net) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id B69428FC17 for ; Tue, 24 Jul 2012 11:34:03 +0000 (UTC) Received: by lbon10 with SMTP id n10so11140119lbo.13 for ; Tue, 24 Jul 2012 04:34:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type:x-gm-message-state; bh=1c7KVB/cofwSY1VlkV6XntRINFx7hIaVv0GSwSF+EcU=; b=bfStqauxCMopL0V6i3o9/hXgDSJODhiF51o+YMpiox45TqY1BHG0Fptwkke5fJ5pwd NvXHYQ4tKr+pYTmAwQdxvG50KYio1Ze17yif+Ecy1mg1WNvUqwncCKuALMHifeQwUnaQ QHLVcgnluPi0isoSIUpzPFHE4+4Q8qxUEfHrFb3IJd7AeG/xn4SxIFIuUm/dmd2qeCEj hYmP3PACtdzcn8etPAc7uHENDyTyX0EJFMbrfnfUU5HLmRuL5qsg+4aZ5aOflV05iaWj THFWmwNKOtuJWuy08HN9zfqhWTiJywZDifS7NOA27jzJCUbQvYouZL8/y6+Zmk8/Xq8I uMpA== MIME-Version: 1.0 Received: by 10.152.135.200 with SMTP id pu8mr21037986lab.8.1343129642591; Tue, 24 Jul 2012 04:34:02 -0700 (PDT) Sender: rdespres@indolore.net Received: by 10.112.4.226 with HTTP; Tue, 24 Jul 2012 04:34:02 -0700 (PDT) X-Originating-IP: [81.200.189.1] Date: Tue, 24 Jul 2012 13:34:02 +0200 X-Google-Sender-Auth: 6v-Wr0CBAJJqfEkeGQzIqu--OWc Message-ID: From: "Regis A. Despres" To: emulation@FreeBSD.org X-Gm-Message-State: ALoCoQkl40qnqb90BOTww9ie15OBKwNYj8jGi5SFSSMUJcxC5eM4DOuNG0rghmgDqM+XPO8VT65b Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Virtualbox Makefile Jail Case X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 11:34:05 -0000 Hi there, Is there any suggestion in order to officialize the compilation virtualbox inside a jail ? That is to say, today virtualbox-ose 's Makefile has a run_depends on vboxnet.ko that makes (at least with my knowledge) tricky to install in a jail. Any help to make it officially simplier for everyone would be appreciated =) -- Regis A. Despres From owner-freebsd-emulation@FreeBSD.ORG Tue Jul 24 12:00:22 2012 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89DB1106566B for ; Tue, 24 Jul 2012 12:00:22 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A7E118FC0C for ; Tue, 24 Jul 2012 12:00:09 +0000 (UTC) Received: by weyx56 with SMTP id x56so6021193wey.13 for ; Tue, 24 Jul 2012 05:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluelife.at; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PkbwYEQ+cjgtxkUuXaKOq0IYdD1brItGCmyJyYIKANM=; b=dGtt3KcXVgutNm3VzFyp/77rY+UZMvf7dLWQewUYXTJcesDwGXYLcp63jz12dlcwN1 sq18BifVm3ZFx9oFhhpOz9wexL+nw4obhuMxXN2Hw35S277mfFUQf7W1IL3sRRC9ot3s 7kCl0X9EZeDFitb1GA3BsL0J9Xi8T3LPlvy1w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=PkbwYEQ+cjgtxkUuXaKOq0IYdD1brItGCmyJyYIKANM=; b=f0g2VSaXMz4ke4yqLn9RgYndNJNt6a3PwPIqw9P07DCO6ar+QhXj579mWDIEWjA+Fz ETwCmfYEXljzCxDmQzhxoSWTMil/dlpEeefx+zfPC8oclUSTBYdcR1n+P9OJ8jCaEmL6 Z6tFxkCptVlCVPheoL6Pyuin6cIttl0jFe0lvmdxFoJTT6WuSwHDOHUQlDEfmQPfJt10 3yau7afRPdxzV4WZkMdQnumXSOkYYHOsivHBc3pKI8wqZ59rmD6kI7QBWyArvz0kNmiR xIzPpdynf+9PvmNLzDvtpMhwoG2pbnnub8DqhBrc19nV9Qi8TR4ujTAfSdQXjBP6EegZ Rq+Q== MIME-Version: 1.0 Received: by 10.180.90.207 with SMTP id by15mr6299374wib.22.1343131208568; Tue, 24 Jul 2012 05:00:08 -0700 (PDT) Sender: decke@bluelife.at Received: by 10.180.106.71 with HTTP; Tue, 24 Jul 2012 05:00:08 -0700 (PDT) X-Originating-IP: [2001:470:9bf5:200:21c:23ff:fe94:8591] In-Reply-To: References: Date: Tue, 24 Jul 2012 14:00:08 +0200 X-Google-Sender-Auth: Q6NnS5MJ4YoctBOJNJ-1SLxUU0w Message-ID: From: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= To: "Regis A. Despres" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlq6iykI0ZhtRPB3w6ETFSZMyLGiIEnbqZ1DyVVBpN94s+o3hfWRnkXP8vQJIjhpO0pjVbz Cc: emulation@freebsd.org Subject: Re: Virtualbox Makefile Jail Case X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 12:00:22 -0000 On Tue, Jul 24, 2012 at 1:34 PM, Regis A. Despres wrote: > Hi there, > > > Is there any suggestion in order to officialize the compilation virtualbox > inside a jail ? > That is to say, today virtualbox-ose 's Makefile has a run_depends on > vboxnet.ko that makes (at least with my knowledge) tricky to install in a > jail. > Any help to make it officially simplier for everyone would be appreciated =) I don't understand what the problem is. Compiling and installing virtualbox within a jail should not be a problem as long as you have kernel sources available. Once you have installed everything and loaded the kernel module you have to solve a few tricky things (passing vbox devices to jail). -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-emulation@FreeBSD.ORG Sat Jul 28 02:05:29 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0BAB106564A for ; Sat, 28 Jul 2012 02:05:29 +0000 (UTC) (envelope-from yiz5hwi@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0005E8FC08 for ; Sat, 28 Jul 2012 02:05:28 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3149900wgb.31 for ; Fri, 27 Jul 2012 19:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7Nzapz5UKeRjbD/HRPV6zyIFkOvyKgwIYPAtDyr42as=; b=AI8JBfzO8WsqN/IjUWahjsykP5wO/gY0WoUwHaQ9n4R5Gv3wwRZc3VfmH1Mlkk5U2E lLLYZlwatAfkiQBjINCSI44xP9blQOEHwKulGGPK3S42JK/OGEnb990ss6ZmEsvntPJ8 Kwa842tQKwBwPupEs6afkCivh7itOtcCU2TpZbm8Xth8iU9HaijdHKnGCogcQOvOy6Sw V8O+Rfbs5rE86JIPyFe7dp67OM0HAgh/StZtmMgVN40ONltJ6IFMUQFVq7BdyEJDIH1m 8pybSN67gDfMIsgMHGNsy0NwnIF1k4z82uyOalNPeFxH6Kdgk4njGPNawZrvlbDgkUWg GXdA== MIME-Version: 1.0 Received: by 10.216.123.69 with SMTP id u47mr2281599weh.89.1343441127610; Fri, 27 Jul 2012 19:05:27 -0700 (PDT) Received: by 10.216.245.140 with HTTP; Fri, 27 Jul 2012 19:05:27 -0700 (PDT) Date: Fri, 27 Jul 2012 22:05:27 -0400 Message-ID: From: Steve Tuts To: freebsd-emulation@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: become worse now - Re: one virtualbox vm disrupts all vms and entire network - finally fixed now X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 02:05:29 -0000 finally fixed now, see fully reply in the end. On Fri, Jul 13, 2012 at 4:34 PM, Steve Tuts wrote: > > > On Mon, Jul 9, 2012 at 9:11 AM, Steve Tuts wrote: > >> >> >> On Tue, Jun 12, 2012 at 6:24 PM, Gary Palmer wrote: >> >>> On Thu, Jun 07, 2012 at 03:56:22PM -0400, Steve Tuts wrote: >>> > On Thu, Jun 7, 2012 at 3:54 AM, Steve Tuts wrote: >>> > >>> > > >>> > > >>> > > On Thu, Jun 7, 2012 at 2:58 AM, Bernhard Fr?hlich >> >wrote: >>> > > >>> > >> On Do., 7. Jun. 2012 01:07:52 CEST, Kevin Oberman < >>> kob6558@gmail.com> >>> > >> wrote: >>> > >> >>> > >> > On Wed, Jun 6, 2012 at 3:46 PM, Steve Tuts >>> wrote: >>> > >> > > On Wed, Jun 6, 2012 at 3:50 AM, Bernhard Froehlich >>> > >> > > wrote: >>> > >> > > >>> > >> > > > On 05.06.2012 20:16, Bernhard Froehlich wrote: >>> > >> > > > >>> > >> > > > > On 05.06.2012 19:05, Steve Tuts wrote: >>> > >> > > > > >>> > >> > > > > > On Mon, Jun 4, 2012 at 4:11 PM, Rusty Nejdl >>> > >> > > > > > wrote: >>> > >> > > > > > >>> > >> > > > > > On 2012-06-02 12:16, Steve Tuts wrote: >>> > >> > > > > > > >>> > >> > > > > > > Hi, we have a Dell poweredge server with a dozen >>> interfaces. >>> > >> > > > > > > It hosts >>> > >> > > > > > > > a >>> > >> > > > > > > > few guests of web app and email servers with >>> > >> > > > > > > > VirtualBox-4.0.14. The host >>> > >> > > > > > > > and all guests are FreeBSD 9.0 64bit. Each guest is >>> bridged >>> > >> > > > > > > > to a distinct >>> > >> > > > > > > > interface. The host and all guests are set to >>> 10.0.0.0 >>> > >> > > > > > > > network NAT'ed to >>> > >> > > > > > > > a >>> > >> > > > > > > > cicso router. >>> > >> > > > > > > > >>> > >> > > > > > > > This runs well for a couple months, until we added a >>> new >>> > >> > > > > > > > guest recently. >>> > >> > > > > > > > Every few hours, none of the guests can be connected. >>> We >>> > >> > > > > > > > can only connect >>> > >> > > > > > > > to the host from outside the router. We can also go >>> to the >>> > >> > > > > > > > console of the >>> > >> > > > > > > > guests (except the new guest), but from there we >>> can't ping >>> > >> > > > > > > > the gateway 10.0.0.1 any more. The new guest just >>> froze. >>> > >> > > > > > > > >>> > >> > > > > > > > Furthermore, on the host we can see a vboxheadless >>> process >>> > >> > > > > > > > for each guest, >>> > >> > > > > > > > including the new guest. But we can not kill it, not >>> even >>> > >> > > > > > > > with "kill -9". >>> > >> > > > > > > > We looked around the web and someone suggested we >>> should use >>> > >> > > > > > > > "kill -SIGCONT" first since the "ps" output has the >>> "T" flag >>> > >> > > > > > > > for that vboxheadless process for that new guest, but >>> that >>> > >> > > > > > > > doesn't help. We also >>> > >> > > > > > > > tried all the VBoxManager commands to poweroff/reset >>> etc >>> > >> > > > > > > > that new guest, >>> > >> > > > > > > > but they all failed complaining that vm is in Aborted >>> state. >>> > >> > > > > > > > We also tried >>> > >> > > > > > > > VBoxManager commands to disconnect the network cable >>> for >>> > >> > > > > > > > that new guest, >>> > >> > > > > > > > it >>> > >> > > > > > > > didn't complain, but there was no effect. >>> > >> > > > > > > > >>> > >> > > > > > > > For a couple times, on the host we disabled the >>> interface >>> > >> > > > > > > > bridging that new >>> > >> > > > > > > > guest, then that vboxheadless process for that new >>> guest >>> > >> > > > > > > > disappeared (we >>> > >> > > > > > > > attempted to kill it before that). And immediately >>> all >>> > >> > > > > > > > other vms regained >>> > >> > > > > > > > connection back to normal. >>> > >> > > > > > > > >>> > >> > > > > > > > But there is one time even the above didn't help - the >>> > >> > > > > > > > vboxheadless process >>> > >> > > > > > > > for that new guest stubbonly remains, and we had to >>> reboot >>> > >> > > > > > > > the host. >>> > >> > > > > > > > >>> > >> > > > > > > > This is already a production server, so we can't >>> upgrade >>> > >> > > > > > > > virtualbox to the >>> > >> > > > > > > > latest version until we obtain a test server. >>> > >> > > > > > > > >>> > >> > > > > > > > Would you advise: >>> > >> > > > > > > > >>> > >> > > > > > > > 1. is there any other way to kill that new guest >>> instead of >>> > >> > > > > > > > rebooting? 2. what might cause the problem? >>> > >> > > > > > > > 3. what setting and test I can do to analyze this >>> problem? >>> > >> > > > > > > > ______________________________****_________________ >>> > >> > > > > > > > >>> > >> > > > > > > > >>> > >> > > > > > > I haven't seen any comments on this and don't want you >>> to >>> > >> > > > > > > think you are being ignored but I haven't seen this but >>> also, >>> > >> > > > > > > the 4.0 branch was buggier >>> > >> > > > > > > for me than the 4.1 releases so yeah, upgrading is >>> probably >>> > >> > > > > > > what you are looking at. >>> > >> > > > > > > >>> > >> > > > > > > Rusty Nejdl >>> > >> > > > > > > ______________________________****_________________ >>> > >> > > > > > > >>> > >> > > > > > > >>> > >> > > > > > > sorry, just realize my reply yesterday didn't go to >>> the list, >>> > >> > > > > > > so am >>> > >> > > > > > re-sending with some updates. >>> > >> > > > > > >>> > >> > > > > > Yes, we upgraded all ports and fortunately everything >>> went back >>> > >> > > > > > and especially all vms has run peacefully for two days >>> now. So >>> > >> > > > > > upgrading to the latest virtualbox 4.1.16 solved that >>> problem. >>> > >> > > > > > >>> > >> > > > > > But now we got a new problem with this new version of >>> > >> virtualbox: >>> > >> > > > > > whenever >>> > >> > > > > > we try to vnc to any vm, that vm will go to Aborted state >>> > >> > > > > > immediately. Actually, merely telnet from within the host >>> to the >>> > >> > > > > > vnc port of that vm will immediately Abort that vm. This >>> > >> > > > > > prevents us from adding new vms. Also, when starting vm >>> with vnc >>> > >> > > > > > port, we got this message: >>> > >> > > > > > >>> > >> > > > > > rfbListenOnTCP6Port: error in bind IPv6 socket: Address >>> already >>> > >> > > > > > in use >>> > >> > > > > > >>> > >> > > > > > , which we found someone else provided a patch at >>> > >> > > > > > >>> > >> >>> http://permalink.gmane.org/**gmane.os.freebsd.devel.**emulation/10237< >>> > >> http://permalink.gmane.org/gmane.os.freebsd.devel.emulation/10237> >>> > >> > > > > > >>> > >> > > > > > So looks like when there are multiple vms on a ipv6 >>> system (we >>> > >> > > > > > have 64bit FreeBSD 9.0) will get this problem. >>> > >> > > > > > >>> > >> > > > > >>> > >> > > > > Glad to hear that 4.1.16 helps for the networking problem. >>> The VNC >>> > >> > > > > problem is also a known one but the mentioned patch does >>> not work >>> > >> > > > > at least for a few people. It seems the bug is somewhere in >>> > >> > > > > libvncserver so downgrading net/libvncserver to an earlier >>> version >>> > >> > > > > (and rebuilding virtualbox) should help until we come up >>> with a >>> > >> > > > > proper fix. >>> > >> > > > > >>> > >> > > > >>> > >> > > > You are right about the "Address already in use" problem and >>> the >>> > >> > > > patch for it so I will commit the fix in a few moments. >>> > >> > > > >>> > >> > > > I have also tried to reproduce the VNC crash but I couldn't. >>> > >> Probably >>> > >> > > > because >>> > >> > > > my system is IPv6 enabled. flo@ has seen the same crash and >>> has no >>> > >> > > > IPv6 in his kernel which lead him to find this commit in >>> > >> > > > libvncserver: >>> > >> > > > >>> > >> > > > >>> > >> > > > commit 66282f58000c8863e104666c30cb67**b1d5cbdee3 >>> > >> > > > Author: Kyle J. McKay >>> > >> > > > Date: Fri May 18 00:30:11 2012 -0700 >>> > >> > > > libvncserver/sockets.c: do not segfault when >>> > >> > > > listenSock/listen6Sock == -1 >>> > >> > > > >>> > >> > > > http://libvncserver.git.** >>> > >> sourceforge.net/git/gitweb.**cgi?p=libvncserver/ >>> > >> > > > **libvncserver;a=commit;h=**66282f5< >>> > >> >>> http://libvncserver.git.sourceforge.net/git/gitweb.cgi?p=libvncserver/libvncserver;a=commit;h=66282f5 >>> > >> > >>> > >> > > > >>> > >> > > > >>> > >> > > > It looks promising so please test this patch if you can >>> reproduce >>> > >> the >>> > >> > > > crash. >>> > >> > > > >>> > >> > > > >>> > >> > > > -- >>> > >> > > > Bernhard Froehlich >>> > >> > > > http://www.bluelife.at/ >>> > >> > > > >>> > >> > > >>> > >> > > Sorry, I tried to try this patch, but couldn't figure out how >>> to do >>> > >> > > that. I use ports to compile everything, and can see the file >>> is at >>> > >> > > >>> > >> >>> /usr/ports/net/libvncserver/work/LibVNCServer-0.9.9/libvncserver/sockets.c >>> > >> > > . However, if I edit this file and do make clean, this patch >>> is wiped >>> > >> > > out before I can do "make" out of it. How to apply this patch >>> in the >>> > >> > > ports? >>> > >> > >>> > >> > To apply patches to ports: >>> > >> > # make clean >>> > >> > # make patch >>> > >> > >>> > >> > # make >>> > >> > # make deinstall >>> > >> > # make reinstall >>> > >> > >>> > >> > Note that the final two steps assume a version of the port is >>> already >>> > >> > installed. If not: 'make install' >>> > >> > I you use portmaster, after applying the patch: 'portmaster -C >>> > >> > net/libvncserver' -- >>> > >> >>> > >> flo has already committed the patch to net/libvncserver so I guess >>> it >>> > >> fixes the problem. Please update your portstree and verify that it >>> works >>> > >> fine. >>> > >> >>> > > >>> > > I confirmed after upgrading all ports and noticing libvncserver >>> upgraded >>> > > to 0.99_1 and reboot, then I can vnc to the vms now. Also, starting >>> vms >>> > > with vnc doesn't have that error now, instead it issues the >>> following info, >>> > > so all problem are solved. >>> > > >>> > > 07/06/2012 03:49:14 Listening for VNC connections on TCP port 5903 >>> > > 07/06/2012 03:49:14 Listening for VNC connections on TCP6 port 5903 >>> > > >>> > > Thanks everyone for your great help! >>> > > >>> > >>> > Unfortunately, seems that the original problem of one vm disrupts all >>> vms >>> > and entire network appears to remain, albeit to less scope. After >>> running >>> > on virtualbox-ose-4.1.16_1 and libvncserver-0.9.9_1 for 12 hours, all >>> vms >>> > lost connection again. Also, phpvirtualbox stopped responding, and >>> > attempts to restart vboxwebsrv hanged. And trying to kill (-9) the >>> > vboxwebsrv process won't work. The following was the output of "ps >>> > aux|grep -i box" at that time: >>> > >>> > root 3322 78.7 16.9 4482936 4248180 ?? Is 3:42AM 126:00.53 >>> > /usr/local/bin/VBoxHeadless --startvm vm1 >>> > root 3377 0.2 4.3 1286200 1078728 ?? Is 3:42AM 15:39.40 >>> > /usr/local/bin/VBoxHeadless --startvm vm2 >>> > root 3388 0.1 4.3 1297592 1084676 ?? Is 3:42AM 15:06.97 >>> > /usr/local/bin/VBoxHeadless --startvm vm7 -n -m 5907 -o >>> jtlgjkrfyh9tpgjklfds >>> > root 2453 0.0 0.0 141684 7156 ?? Ts 3:38AM 4:14.09 >>> > /usr/local/bin/vboxwebsrv >>> > root 2478 0.0 0.0 45288 2528 ?? S 3:38AM 1:29.99 >>> > /usr/local/lib/virtualbox/VBoxXPCOMIPCD >>> > root 2494 0.0 0.0 121848 5380 ?? S 3:38AM 3:13.96 >>> > /usr/local/lib/virtualbox/VBoxSVC --auto-shutdown >>> > root 3333 0.0 4.3 1294712 1079608 ?? Is 3:42AM 19:35.09 >>> > /usr/local/bin/VBoxHeadless --startvm vm3 >>> > root 3355 0.0 4.3 1290424 1079332 ?? Is 3:42AM 16:43.05 >>> > /usr/local/bin/VBoxHeadless --startvm vm5 >>> > root 3366 0.0 8.5 2351436 2140076 ?? Is 3:42AM 17:32.35 >>> > /usr/local/bin/VBoxHeadless --startvm vm6 >>> > root 3598 0.0 4.3 1294520 1078664 ?? Ds 3:50AM 15:01.04 >>> > /usr/local/bin/VBoxHeadless --startvm vm4 -n -m 5904 -o >>> > u679y0uojlkdfsgkjtfds >>> > >>> > You can see the vboxwebsrv process has the "T" flag there, and the >>> > vboxheadless process for vm4 has "D" flag there. Both of such >>> processes I >>> > can never kill them, not even with "kill -9". So on the host I >>> disabled >>> > the interface bridged to vm4 and restarted network, and fortunately >>> both >>> > the vm4 and the vboxwebsrv processed disappeared. And at that point >>> all >>> > other vms regained network. >>> > >>> > There may be one hope that the "troublemaker" may be limited to one of >>> the >>> > vms that started with vnc, although there was no vnc connection at that >>> > time, and the other vm with vnc was fine. And this is just a hopeful >>> guess. >>> > >>> > Also I found no log or error message related to virtualbox in any log >>> > file. The VBoxSVC.log only had some information when started but never >>> > since. >>> >>> If this is still a problem then >>> >>> ps alxww | grep -i box >>> >>> may be more helpful as it will show the wait channel of processes stuck >>> in the kernel. >>> >>> Gary >>> >> >> We avoided this problem by running all vms without vnc. But forgot this >> problem and left one vm on with vnc, together with the other few running >> vms yesterday, and hit this problem again on virtualbox 4.1.16. Only the >> old trick of turning off the host interface corresponding to the vm with >> vnc and then restarting host network got us out of the problem. >> >> We then upgraded virtualbox to 4.1.18, turning off all vms, wait until >> "ps aux|grep -i box" reported nothing, then started all vms. And let no vm >> with vnc running. >> >> Still the problem hit us again. Here is the output of " ps alxww | grep >> -i box" as you suggested: >> >> 1011 42725 1 0 20 0 1289796 1081064 IPRT S >> Is ?? 30:53.24 VBoxHeadless --startvm vm5 >> >> after "kill -9 42725", the line changed to >> >> 1011 42725 1 0 20 0 1289796 1081064 keglim >> Ts ?? 30:53.24 VBoxHeadless --startvm vm5 >> >> after "kill -9" for another vm, the line changed to something like >> >> 1011 42754 1 0 20 0 1289796 1081064 - Ts >> ?? 30:53.24 VBoxHeadless --startvm vm7 >> >> and controlvm command don't work, and these command stuck there >> themselves. The following are their outputs: >> >> 0 89572 79180 0 21 0 44708 1644 select I+ >> v6 0:00.01 VBoxManage controlvm projects_outside acpipowerbutton >> 0 89605 89586 0 21 0 44708 2196 select I+ >> v7 0:00.01 VBoxManage controlvm projects_outside poweroff >> >> We now rebooted the host, and left no vm with vnc running. >> > > The problem has become more rampant now. After rebooting and running > virtualbox-ose-4.1.18, and no vm was started with console, the around 10 > vms, bridged to each of its own dedicated interface, get no network > connection a couple times a day. Most times it would recover itself after > about 10 minutes, sometimes we have to restart host network which > immediately restore all connections. > It turned out this might not be a virtualbox problem, as searching "freebsd network problem" has quite some problem, especially this page shows theBroadcom bce card problem (which is what we have) and the solution. After adding kern.ipc.nmbclusters="131072" hw.bce.tso_enable=0 hw.pci.enable_msix=0 to /boot/loader.conf.local and reboot, no network problem has occured for 3.5 days, while there were 3-7 occurrance of the network problem every day. So consider this problem finally solved. So it appears to be a Broadcom driver issue and probably system tuning issue. From owner-freebsd-emulation@FreeBSD.ORG Sat Jul 28 02:07:22 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 203961065670 for ; Sat, 28 Jul 2012 02:07:22 +0000 (UTC) (envelope-from yiz5hwi@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6C5228FC16 for ; Sat, 28 Jul 2012 02:07:21 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3150493wgb.31 for ; Fri, 27 Jul 2012 19:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=mBgvf8rUTifM3oRAYtWMfEvUXa01AwXT/YkLHgDxF28=; b=ntQvjj7yNNVUuM58r52+Bl9daNOPWm0kuolGN8NNMXA+UiK6DWvckUwt/VSVIRB7He ht5pbbzmPc3htHzx+l042zNHjHKKM5E1tePJoFxbFBXF0ZdrnOo+qTfTi3ZP0OuqXy/8 Rt9GrfAcMttt3MZohPFuB3leyevHAAVHSyPL8+DCHezelYx8/NKmdwt36VKsENtBg3hr HY5JPlXvQiT98vCofrbsMRZG48CSlUZDcmO8EFlAQvEWRmRt93xLYAdXHJ99yRKqqaWG 5092iHjZlZXVpti/uPJJRVx5uNj9LjoNGGZ2j+cLPC0CeHgzSsDJZY4QMqQzOvQcm+xl /LuQ== MIME-Version: 1.0 Received: by 10.180.78.2 with SMTP id x2mr10498539wiw.10.1343441240518; Fri, 27 Jul 2012 19:07:20 -0700 (PDT) Received: by 10.216.245.140 with HTTP; Fri, 27 Jul 2012 19:07:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Jul 2012 22:07:20 -0400 Message-ID: From: Steve Tuts To: freebsd-emulation@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: become worse now - Re: one virtualbox vm disrupts all vms and entire network - finally fixed now X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 02:07:22 -0000 On Fri, Jul 27, 2012 at 10:05 PM, Steve Tuts wrote: > finally fixed now, see fully reply in the end. > > On Fri, Jul 13, 2012 at 4:34 PM, Steve Tuts wrote: > >> >> >> On Mon, Jul 9, 2012 at 9:11 AM, Steve Tuts wrote: >> >>> >>> >>> On Tue, Jun 12, 2012 at 6:24 PM, Gary Palmer wrote: >>> >>>> On Thu, Jun 07, 2012 at 03:56:22PM -0400, Steve Tuts wrote: >>>> > On Thu, Jun 7, 2012 at 3:54 AM, Steve Tuts wrote: >>>> > >>>> > > >>>> > > >>>> > > On Thu, Jun 7, 2012 at 2:58 AM, Bernhard Fr?hlich < >>>> decke@bluelife.at>wrote: >>>> > > >>>> > >> On Do., 7. Jun. 2012 01:07:52 CEST, Kevin Oberman < >>>> kob6558@gmail.com> >>>> > >> wrote: >>>> > >> >>>> > >> > On Wed, Jun 6, 2012 at 3:46 PM, Steve Tuts >>>> wrote: >>>> > >> > > On Wed, Jun 6, 2012 at 3:50 AM, Bernhard Froehlich >>>> > >> > > wrote: >>>> > >> > > >>>> > >> > > > On 05.06.2012 20:16, Bernhard Froehlich wrote: >>>> > >> > > > >>>> > >> > > > > On 05.06.2012 19:05, Steve Tuts wrote: >>>> > >> > > > > >>>> > >> > > > > > On Mon, Jun 4, 2012 at 4:11 PM, Rusty Nejdl >>>> > >> > > > > > wrote: >>>> > >> > > > > > >>>> > >> > > > > > On 2012-06-02 12:16, Steve Tuts wrote: >>>> > >> > > > > > > >>>> > >> > > > > > > Hi, we have a Dell poweredge server with a dozen >>>> interfaces. >>>> > >> > > > > > > It hosts >>>> > >> > > > > > > > a >>>> > >> > > > > > > > few guests of web app and email servers with >>>> > >> > > > > > > > VirtualBox-4.0.14. The host >>>> > >> > > > > > > > and all guests are FreeBSD 9.0 64bit. Each guest is >>>> bridged >>>> > >> > > > > > > > to a distinct >>>> > >> > > > > > > > interface. The host and all guests are set to >>>> 10.0.0.0 >>>> > >> > > > > > > > network NAT'ed to >>>> > >> > > > > > > > a >>>> > >> > > > > > > > cicso router. >>>> > >> > > > > > > > >>>> > >> > > > > > > > This runs well for a couple months, until we added a >>>> new >>>> > >> > > > > > > > guest recently. >>>> > >> > > > > > > > Every few hours, none of the guests can be >>>> connected. We >>>> > >> > > > > > > > can only connect >>>> > >> > > > > > > > to the host from outside the router. We can also go >>>> to the >>>> > >> > > > > > > > console of the >>>> > >> > > > > > > > guests (except the new guest), but from there we >>>> can't ping >>>> > >> > > > > > > > the gateway 10.0.0.1 any more. The new guest just >>>> froze. >>>> > >> > > > > > > > >>>> > >> > > > > > > > Furthermore, on the host we can see a vboxheadless >>>> process >>>> > >> > > > > > > > for each guest, >>>> > >> > > > > > > > including the new guest. But we can not kill it, >>>> not even >>>> > >> > > > > > > > with "kill -9". >>>> > >> > > > > > > > We looked around the web and someone suggested we >>>> should use >>>> > >> > > > > > > > "kill -SIGCONT" first since the "ps" output has the >>>> "T" flag >>>> > >> > > > > > > > for that vboxheadless process for that new guest, >>>> but that >>>> > >> > > > > > > > doesn't help. We also >>>> > >> > > > > > > > tried all the VBoxManager commands to poweroff/reset >>>> etc >>>> > >> > > > > > > > that new guest, >>>> > >> > > > > > > > but they all failed complaining that vm is in >>>> Aborted state. >>>> > >> > > > > > > > We also tried >>>> > >> > > > > > > > VBoxManager commands to disconnect the network cable >>>> for >>>> > >> > > > > > > > that new guest, >>>> > >> > > > > > > > it >>>> > >> > > > > > > > didn't complain, but there was no effect. >>>> > >> > > > > > > > >>>> > >> > > > > > > > For a couple times, on the host we disabled the >>>> interface >>>> > >> > > > > > > > bridging that new >>>> > >> > > > > > > > guest, then that vboxheadless process for that new >>>> guest >>>> > >> > > > > > > > disappeared (we >>>> > >> > > > > > > > attempted to kill it before that). And immediately >>>> all >>>> > >> > > > > > > > other vms regained >>>> > >> > > > > > > > connection back to normal. >>>> > >> > > > > > > > >>>> > >> > > > > > > > But there is one time even the above didn't help - >>>> the >>>> > >> > > > > > > > vboxheadless process >>>> > >> > > > > > > > for that new guest stubbonly remains, and we had to >>>> reboot >>>> > >> > > > > > > > the host. >>>> > >> > > > > > > > >>>> > >> > > > > > > > This is already a production server, so we can't >>>> upgrade >>>> > >> > > > > > > > virtualbox to the >>>> > >> > > > > > > > latest version until we obtain a test server. >>>> > >> > > > > > > > >>>> > >> > > > > > > > Would you advise: >>>> > >> > > > > > > > >>>> > >> > > > > > > > 1. is there any other way to kill that new guest >>>> instead of >>>> > >> > > > > > > > rebooting? 2. what might cause the problem? >>>> > >> > > > > > > > 3. what setting and test I can do to analyze this >>>> problem? >>>> > >> > > > > > > > ______________________________****_________________ >>>> > >> > > > > > > > >>>> > >> > > > > > > > >>>> > >> > > > > > > I haven't seen any comments on this and don't want you >>>> to >>>> > >> > > > > > > think you are being ignored but I haven't seen this >>>> but also, >>>> > >> > > > > > > the 4.0 branch was buggier >>>> > >> > > > > > > for me than the 4.1 releases so yeah, upgrading is >>>> probably >>>> > >> > > > > > > what you are looking at. >>>> > >> > > > > > > >>>> > >> > > > > > > Rusty Nejdl >>>> > >> > > > > > > ______________________________****_________________ >>>> > >> > > > > > > >>>> > >> > > > > > > >>>> > >> > > > > > > sorry, just realize my reply yesterday didn't go to >>>> the list, >>>> > >> > > > > > > so am >>>> > >> > > > > > re-sending with some updates. >>>> > >> > > > > > >>>> > >> > > > > > Yes, we upgraded all ports and fortunately everything >>>> went back >>>> > >> > > > > > and especially all vms has run peacefully for two days >>>> now. So >>>> > >> > > > > > upgrading to the latest virtualbox 4.1.16 solved that >>>> problem. >>>> > >> > > > > > >>>> > >> > > > > > But now we got a new problem with this new version of >>>> > >> virtualbox: >>>> > >> > > > > > whenever >>>> > >> > > > > > we try to vnc to any vm, that vm will go to Aborted state >>>> > >> > > > > > immediately. Actually, merely telnet from within the >>>> host to the >>>> > >> > > > > > vnc port of that vm will immediately Abort that vm. This >>>> > >> > > > > > prevents us from adding new vms. Also, when starting vm >>>> with vnc >>>> > >> > > > > > port, we got this message: >>>> > >> > > > > > >>>> > >> > > > > > rfbListenOnTCP6Port: error in bind IPv6 socket: Address >>>> already >>>> > >> > > > > > in use >>>> > >> > > > > > >>>> > >> > > > > > , which we found someone else provided a patch at >>>> > >> > > > > > >>>> > >> >>>> http://permalink.gmane.org/**gmane.os.freebsd.devel.**emulation/10237< >>>> > >> http://permalink.gmane.org/gmane.os.freebsd.devel.emulation/10237> >>>> > >> > > > > > >>>> > >> > > > > > So looks like when there are multiple vms on a ipv6 >>>> system (we >>>> > >> > > > > > have 64bit FreeBSD 9.0) will get this problem. >>>> > >> > > > > > >>>> > >> > > > > >>>> > >> > > > > Glad to hear that 4.1.16 helps for the networking problem. >>>> The VNC >>>> > >> > > > > problem is also a known one but the mentioned patch does >>>> not work >>>> > >> > > > > at least for a few people. It seems the bug is somewhere in >>>> > >> > > > > libvncserver so downgrading net/libvncserver to an earlier >>>> version >>>> > >> > > > > (and rebuilding virtualbox) should help until we come up >>>> with a >>>> > >> > > > > proper fix. >>>> > >> > > > > >>>> > >> > > > >>>> > >> > > > You are right about the "Address already in use" problem and >>>> the >>>> > >> > > > patch for it so I will commit the fix in a few moments. >>>> > >> > > > >>>> > >> > > > I have also tried to reproduce the VNC crash but I couldn't. >>>> > >> Probably >>>> > >> > > > because >>>> > >> > > > my system is IPv6 enabled. flo@ has seen the same crash and >>>> has no >>>> > >> > > > IPv6 in his kernel which lead him to find this commit in >>>> > >> > > > libvncserver: >>>> > >> > > > >>>> > >> > > > >>>> > >> > > > commit 66282f58000c8863e104666c30cb67**b1d5cbdee3 >>>> > >> > > > Author: Kyle J. McKay >>>> > >> > > > Date: Fri May 18 00:30:11 2012 -0700 >>>> > >> > > > libvncserver/sockets.c: do not segfault when >>>> > >> > > > listenSock/listen6Sock == -1 >>>> > >> > > > >>>> > >> > > > http://libvncserver.git.** >>>> > >> sourceforge.net/git/gitweb.**cgi?p=libvncserver/ >>>> > >> > > > **libvncserver;a=commit;h=**66282f5< >>>> > >> >>>> http://libvncserver.git.sourceforge.net/git/gitweb.cgi?p=libvncserver/libvncserver;a=commit;h=66282f5 >>>> > >> > >>>> > >> > > > >>>> > >> > > > >>>> > >> > > > It looks promising so please test this patch if you can >>>> reproduce >>>> > >> the >>>> > >> > > > crash. >>>> > >> > > > >>>> > >> > > > >>>> > >> > > > -- >>>> > >> > > > Bernhard Froehlich >>>> > >> > > > http://www.bluelife.at/ >>>> > >> > > > >>>> > >> > > >>>> > >> > > Sorry, I tried to try this patch, but couldn't figure out how >>>> to do >>>> > >> > > that. I use ports to compile everything, and can see the file >>>> is at >>>> > >> > > >>>> > >> >>>> /usr/ports/net/libvncserver/work/LibVNCServer-0.9.9/libvncserver/sockets.c >>>> > >> > > . However, if I edit this file and do make clean, this patch >>>> is wiped >>>> > >> > > out before I can do "make" out of it. How to apply this patch >>>> in the >>>> > >> > > ports? >>>> > >> > >>>> > >> > To apply patches to ports: >>>> > >> > # make clean >>>> > >> > # make patch >>>> > >> > >>>> > >> > # make >>>> > >> > # make deinstall >>>> > >> > # make reinstall >>>> > >> > >>>> > >> > Note that the final two steps assume a version of the port is >>>> already >>>> > >> > installed. If not: 'make install' >>>> > >> > I you use portmaster, after applying the patch: 'portmaster -C >>>> > >> > net/libvncserver' -- >>>> > >> >>>> > >> flo has already committed the patch to net/libvncserver so I guess >>>> it >>>> > >> fixes the problem. Please update your portstree and verify that it >>>> works >>>> > >> fine. >>>> > >> >>>> > > >>>> > > I confirmed after upgrading all ports and noticing libvncserver >>>> upgraded >>>> > > to 0.99_1 and reboot, then I can vnc to the vms now. Also, >>>> starting vms >>>> > > with vnc doesn't have that error now, instead it issues the >>>> following info, >>>> > > so all problem are solved. >>>> > > >>>> > > 07/06/2012 03:49:14 Listening for VNC connections on TCP port 5903 >>>> > > 07/06/2012 03:49:14 Listening for VNC connections on TCP6 port 5903 >>>> > > >>>> > > Thanks everyone for your great help! >>>> > > >>>> > >>>> > Unfortunately, seems that the original problem of one vm disrupts all >>>> vms >>>> > and entire network appears to remain, albeit to less scope. After >>>> running >>>> > on virtualbox-ose-4.1.16_1 and libvncserver-0.9.9_1 for 12 hours, all >>>> vms >>>> > lost connection again. Also, phpvirtualbox stopped responding, and >>>> > attempts to restart vboxwebsrv hanged. And trying to kill (-9) the >>>> > vboxwebsrv process won't work. The following was the output of "ps >>>> > aux|grep -i box" at that time: >>>> > >>>> > root 3322 78.7 16.9 4482936 4248180 ?? Is 3:42AM 126:00.53 >>>> > /usr/local/bin/VBoxHeadless --startvm vm1 >>>> > root 3377 0.2 4.3 1286200 1078728 ?? Is 3:42AM 15:39.40 >>>> > /usr/local/bin/VBoxHeadless --startvm vm2 >>>> > root 3388 0.1 4.3 1297592 1084676 ?? Is 3:42AM 15:06.97 >>>> > /usr/local/bin/VBoxHeadless --startvm vm7 -n -m 5907 -o >>>> jtlgjkrfyh9tpgjklfds >>>> > root 2453 0.0 0.0 141684 7156 ?? Ts 3:38AM 4:14.09 >>>> > /usr/local/bin/vboxwebsrv >>>> > root 2478 0.0 0.0 45288 2528 ?? S 3:38AM 1:29.99 >>>> > /usr/local/lib/virtualbox/VBoxXPCOMIPCD >>>> > root 2494 0.0 0.0 121848 5380 ?? S 3:38AM 3:13.96 >>>> > /usr/local/lib/virtualbox/VBoxSVC --auto-shutdown >>>> > root 3333 0.0 4.3 1294712 1079608 ?? Is 3:42AM 19:35.09 >>>> > /usr/local/bin/VBoxHeadless --startvm vm3 >>>> > root 3355 0.0 4.3 1290424 1079332 ?? Is 3:42AM 16:43.05 >>>> > /usr/local/bin/VBoxHeadless --startvm vm5 >>>> > root 3366 0.0 8.5 2351436 2140076 ?? Is 3:42AM 17:32.35 >>>> > /usr/local/bin/VBoxHeadless --startvm vm6 >>>> > root 3598 0.0 4.3 1294520 1078664 ?? Ds 3:50AM 15:01.04 >>>> > /usr/local/bin/VBoxHeadless --startvm vm4 -n -m 5904 -o >>>> > u679y0uojlkdfsgkjtfds >>>> > >>>> > You can see the vboxwebsrv process has the "T" flag there, and the >>>> > vboxheadless process for vm4 has "D" flag there. Both of such >>>> processes I >>>> > can never kill them, not even with "kill -9". So on the host I >>>> disabled >>>> > the interface bridged to vm4 and restarted network, and fortunately >>>> both >>>> > the vm4 and the vboxwebsrv processed disappeared. And at that point >>>> all >>>> > other vms regained network. >>>> > >>>> > There may be one hope that the "troublemaker" may be limited to one >>>> of the >>>> > vms that started with vnc, although there was no vnc connection at >>>> that >>>> > time, and the other vm with vnc was fine. And this is just a hopeful >>>> guess. >>>> > >>>> > Also I found no log or error message related to virtualbox in any log >>>> > file. The VBoxSVC.log only had some information when started but >>>> never >>>> > since. >>>> >>>> If this is still a problem then >>>> >>>> ps alxww | grep -i box >>>> >>>> may be more helpful as it will show the wait channel of processes stuck >>>> in the kernel. >>>> >>>> Gary >>>> >>> >>> We avoided this problem by running all vms without vnc. But forgot this >>> problem and left one vm on with vnc, together with the other few running >>> vms yesterday, and hit this problem again on virtualbox 4.1.16. Only the >>> old trick of turning off the host interface corresponding to the vm with >>> vnc and then restarting host network got us out of the problem. >>> >>> We then upgraded virtualbox to 4.1.18, turning off all vms, wait until >>> "ps aux|grep -i box" reported nothing, then started all vms. And let no vm >>> with vnc running. >>> >>> Still the problem hit us again. Here is the output of " ps alxww | grep >>> -i box" as you suggested: >>> >>> 1011 42725 1 0 20 0 1289796 1081064 IPRT S >>> Is ?? 30:53.24 VBoxHeadless --startvm vm5 >>> >>> after "kill -9 42725", the line changed to >>> >>> 1011 42725 1 0 20 0 1289796 1081064 keglim >>> Ts ?? 30:53.24 VBoxHeadless --startvm vm5 >>> >>> after "kill -9" for another vm, the line changed to something like >>> >>> 1011 42754 1 0 20 0 1289796 1081064 - Ts >>> ?? 30:53.24 VBoxHeadless --startvm vm7 >>> >>> and controlvm command don't work, and these command stuck there >>> themselves. The following are their outputs: >>> >>> 0 89572 79180 0 21 0 44708 1644 select I+ >>> v6 0:00.01 VBoxManage controlvm projects_outside acpipowerbutton >>> 0 89605 89586 0 21 0 44708 2196 select I+ >>> v7 0:00.01 VBoxManage controlvm projects_outside poweroff >>> >>> We now rebooted the host, and left no vm with vnc running. >>> >> >> The problem has become more rampant now. After rebooting and running >> virtualbox-ose-4.1.18, and no vm was started with console, the around 10 >> vms, bridged to each of its own dedicated interface, get no network >> connection a couple times a day. Most times it would recover itself after >> about 10 minutes, sometimes we have to restart host network which >> immediately restore all connections. >> > > It turned out this might not be a virtualbox problem, as searching > "freebsd network problem" has quite some problem, especially this page > shows the Broadcom bce card problem (which is what we have) and the > solution. After adding > > kern.ipc.nmbclusters="131072" > hw.bce.tso_enable=0 > hw.pci.enable_msix=0 > > to /boot/loader.conf.local and reboot, no network problem has occured for 3.5 days, while there were 3-7 occurrance of the network problem every day. So consider this problem finally solved. > > So it appears to be a Broadcom driver issue and probably system tuning issue. > > > oops, forgot the link: http://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards From owner-freebsd-emulation@FreeBSD.ORG Sat Jul 28 10:37:23 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F57B1065672 for ; Sat, 28 Jul 2012 10:37:23 +0000 (UTC) (envelope-from carmel_ny@hotmail.com) Received: from blu0-omc1-s12.blu0.hotmail.com (blu0-omc1-s12.blu0.hotmail.com [65.55.116.23]) by mx1.freebsd.org (Postfix) with ESMTP id 050CF8FC08 for ; Sat, 28 Jul 2012 10:37:22 +0000 (UTC) Received: from BLU0-SMTP186 ([65.55.116.7]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 28 Jul 2012 03:36:16 -0700 X-Originating-IP: [76.182.104.150] X-Originating-Email: [carmel_ny@hotmail.com] Message-ID: Received: from scorpio.seibercom.net ([76.182.104.150]) by BLU0-SMTP186.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 28 Jul 2012 03:36:14 -0700 Received: from scorpio (localhost [127.0.0.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: carmel_ny@scorpio.seibercom.net) by scorpio.seibercom.net (Postfix) with ESMTPSA id 3Wkk3d53xqz2CG62 for ; Sat, 28 Jul 2012 06:36:13 -0400 (EDT) Date: Sat, 28 Jul 2012 06:36:13 -0400 From: Carmel To: freebsd-emulation@freebsd.org In-Reply-To: References: X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAHlBMVEUAAABYRlwJCw4FAgAIBwKprDkBAQFQLR0BAgCir7VRttp8AAACAUlEQVQ4jZWUTYvbMBCGTVl8V2hX6Gg5G5FbWQdBj0lEfE7BhN4cyzi5Wt1E5L70roWy6N92xok/skkP+5IYrMcz78xIduDWpNM3vFzuA/jX5EY1AI6KHFwW/CzFuQAwqUBbV12p+CzIh6Awq7sg33pn5D64SQXAexffeuQlA/L35RrkaB551OjGfP/cAO8mCNaDcgvfky5ijoD0pAXlCQCnljiAjsJD9Ax05Ko5sZxbnLQcmM+dZg5IjREfZrWIHK0JuwU68pAGwHvfRxBundRzTxxz3r9dNUikPsEihjz2Dc4kjp1hKsJGuot4EDxaxzMoC7XqhxhOSfZrTS6gSX1JVdjp+o1PvWfekXgw3WL0g70nDEwA0H0HQsEZc8sTmFMTkWUfYWC/vdR1zQy3xLQgLwzu90QnlnFLjeiGWBjwhb4Sa42IqOg2qqS4O1/zhKokFUb1Q8Rj4Eb69WVflXEehJ35DgChVTE5n50eaGyMLOfH8AOodoSM4PVYAQgQdBulOa+knklYks3vAuQ+uX492lTl+A+e8qBV2AKoXalVKFfyuUp0pUp1ARaUHh82lv9MN+Ig7CZtgE6FNYvjlywT2VP2dMgOG46gTIWcqdfvuwyXNz0oMJNd/N5lh1YNiJt19ADTUo3VuFSNeQwVqRSrGjSCp53fk2g+Mvfk/gfoPxHeUS8MH9vRAAAAAElFTkSuQmCC MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 28 Jul 2012 10:36:15.0167 (UTC) FILETIME=[D07D74F0:01CD6CAC] Subject: Re: become worse now - Re: one virtualbox vm disrupts all vms and entire network - finally fixed now X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Carmel List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 10:37:23 -0000 On Fri, 27 Jul 2012 22:05:27 -0400 Steve Tuts articulated: > finally fixed now, see fully reply in the end. Seriously, couldn't you have stripped out all of the redundant data before continuing? > It turned out this might not be a virtualbox problem, as searching > "freebsd network problem" has quite some problem, especially this > page shows theBroadcom bce card problem (which is what we have) and > the solution. After > adding > > kern.ipc.nmbclusters="131072" > hw.bce.tso_enable=0 > hw.pci.enable_msix=0 > > to /boot/loader.conf.local and reboot, no network problem has occured > for 3.5 days, while there were 3-7 occurrance of the network problem > every day. So consider this problem finally solved. > > So it appears to be a Broadcom driver issue and probably system > tuning issue. Have you filed a PR against it? -- Carmel ✌ carmel_ny@hotmail.com Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the "Reply-To" header.