Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Sep 2015 20:18:41 +0200
From:      Martin Birgmeier <la5lbtyi@aon.at>
To:        Michael Butler <imb@protected-networks.net>
Cc:        =?UTF-8?Q?Bernhard_Fr=c3=b6hlich?= <decke@bluelife.at>, "freebsd-emulation@freebsd.org" <freebsd-emulation@freebsd.org>
Subject:   Re: VirtualBox mangles memory
Message-ID:  <5602ED01.20202@aon.at>
In-Reply-To: <5601C0B8.4000905@protected-networks.net>
References:  <55FE9662.7000406@aon.at> <1442866256.1127084.389759513.29E96282@webmail.messagingengine.com> <56017026.6040809@aon.at> <CAE-m3X1eZww8FGu1kTmUwn7dyQNXjXySgHO=WRsGEbJKvWL=AA@mail.gmail.com> <5601AB71.9000003@aon.at> <CA%2BtpaK1w=KM93roeecF30Gvgva_sofGCwuDGOWn44y2O2L5x9Q@mail.gmail.com> <5601C0B8.4000905@protected-networks.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <the machine running the VB client> "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 <the machine running the VB client> "dd if=/dev/ada0s2 bs=128k" > /dev/null
  produces "Connection to <the machine running the VB client> 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 <la5lbtyi@aon.at> 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
>
>
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5602ED01.20202>