From owner-freebsd-emulation@freebsd.org Wed Sep 23 18:18:47 2015 Return-Path: Delivered-To: freebsd-emulation@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33FCEA07AEA for ; Wed, 23 Sep 2015 18:18:47 +0000 (UTC) (envelope-from la5lbtyi@aon.at) Received: from smtpout.aon.at (smtpout.aon.at [195.3.96.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E2551DB4 for ; Wed, 23 Sep 2015 18:18:45 +0000 (UTC) (envelope-from la5lbtyi@aon.at) Received: (qmail 21082 invoked from network); 23 Sep 2015 18:18:42 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on WARSBL505.highway.telekom.at X-Spam-Level: Received: from 91-115-164-12.adsl.highway.telekom.at (HELO gandalf.xyzzy) ([91.115.164.12]) (envelope-sender ) by smarthub78.res.a1.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP; 23 Sep 2015 18:18:41 -0000 X-A1Mail-Track-Id: 1443032321:21067:smarthub78:91.115.164.12:1 Received: from mizar.xyzzy (mizar.xyzzy [192.168.1.19]) by gandalf.xyzzy (8.15.2/8.15.2) with ESMTP id t8NIIfGD006751; Wed, 23 Sep 2015 20:18:41 +0200 (CEST) (envelope-from la5lbtyi@aon.at) Subject: Re: VirtualBox mangles memory To: Michael Butler References: <55FE9662.7000406@aon.at> <1442866256.1127084.389759513.29E96282@webmail.messagingengine.com> <56017026.6040809@aon.at> <5601AB71.9000003@aon.at> <5601C0B8.4000905@protected-networks.net> Cc: =?UTF-8?Q?Bernhard_Fr=c3=b6hlich?= , "freebsd-emulation@freebsd.org" From: Martin Birgmeier Organization: MBi at home Message-ID: <5602ED01.20202@aon.at> Date: Wed, 23 Sep 2015 20:18:41 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5601C0B8.4000905@protected-networks.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.20 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: Wed, 23 Sep 2015 18:18:47 -0000 I have always recompiled the vbox modules (in fact, all of VB) after the latest kernel installation, for both machines. This behavior started after I upgraded from FBSD 9.2 to 10.1 (and persisted with 10.2). I have tried to refine the scenario where the problem appears, and the results are as follows. - I run a 3 GB VB client on an 8 GB machine - On this machine I start a dd with a blocksize of 128k to copy a 250G disk slice to standard output (the purpose being to make an image backup of the Windows partition). The difference is how I start dd: - Just running dd if=/dev/ada0s2 of=/dev/null bs=128 works. - Running dd if=/dev/ada0s2 bs=128k | cat > /dev/null works. - *On another machine*, running rsh -n "dd if=/dev/ada0s2 bs=128k" > /dev/null produces "dd: stdout: Cannot allocate memory" quite soon (but after a non-deterministic number of blocks have been transferred). If I do this using ssh, the behavior is slightly different but still erroneous: ssh -n "dd if=/dev/ada0s2 bs=128k" > /dev/null produces "Connection to closed by remote host." without a message from dd. I could not note any anomalies in memory usage as monitored by "top" and "systat -vm 1". If, after the tests above, I shut down the VB client while keeping everything else the same, issuing the rsh command runs to completion correctly. Note that in that other scenario where I was using "zfs send", "zfs send" was also invoked via "rsh -n". So it seems that sending data via rsh while a VB client is running leads to the problem. Could anyone try to reproduce this test case and tell me about the results? Thank you in advance for your efforts. -- Martin On 09/22/15 22:57, Michael Butler wrote: > On 09/22/15 16:20, Adam Vande More wrote: >> On Tue, Sep 22, 2015 at 2:26 PM, Martin Birgmeier wrote: >>> I am quite sure that the >>> cause is to be found there >>> >> I don't see any cause for surety in the info you have given us. Have you >> tried any basic steps like monitoring usage during these events or running >> it under truss/valgrind etc to find out what is going on? >> > Another data point .. > > I run it on -CURRENT and there have been a number of VM-related changes > of late but I don't have any problems with it. > > However, you *must* recompile (at least) the modules whenever the kernel > is rebuilt as they depend heavily on the underlying kernel structures, > > imb > > >