Hi Vincent,

On Fri, Oct 30, 2015 at 04:50:32PM +0800, Vincent Digital wrote:

Hi,

With the previous Turmvilla scenario, I wish to setup two virtualbox sessions, one running LInux process and the other running Windows, concurrently. I created a new Win7 subsystem, emulating the LInux subsystem, with new vm_win7.vdi.

However, I could startup only one of each sessions from NOUX, either Windows or Linux, but not both sessions at the same time. From CLI monitor, I could see that RAM is allocated separately for both sessions. I suspect some concurrency issue but could not find the issue.

I've attached the log from captured from NOUX.

What puzzles me in your log is the following

342: [cli_monitor -> linux -> vbox] EMT-0 PDMR3ThreadSuspend -> rc=VERR_TIMEOUT enmState=2 suspending 'nic_thread' 343: [cli_monitor -> linux -> vbox] PDMR3ThreadSuspend -> rc=VERR_TIMEOUT enmState=2 suspending 'nic_thread'

Could you please disable networking like follows in both vbox configurations and retry?

- <Adapter slot="0" enabled="true" MACAddress="0800271D7901" cable="true" speed="0" type="82540EM"> + <Adapter slot="0" enabled="false" MACAddress="0800271D7901" cable="true" speed="0" type="82540EM">

In the log, win7 vbox appears only after the assertion in linux vbox. Currently, I've no idea why win7 gets stuck in the middle of initialization. Later in the log, there's another try to start linux vbox if I'm not mistaken, which also did not succeed.

It may also matter if the base services incl. core and NOVA log some diagnostics in the time span of the multiple vbox startup. Could you please check the serial log for suspicious messages?

Another issue I encountered is that the virtual box mouse pointer in the WIndows session and the Nitpicker mouse pointer can't seem to merge together unlike the Linux session where both pointers are merged.

I suspect your Windows installation is missing the VirtualBox guest tools. In this case, the guest draws a software mouse pointer into the framebuffer which often appears not in sync with the Nitpicker pointer. So, after the guest tools are installed the Windows pointer will disappear. Looking at

https://github.com/nfeske/genode/blob/turmvilla/repos/gems/run/turmvilla.run

I also expect the mouse-pointer integration for win7 will work out of the box and the shape will be reported from the Windows guest to vbox_pointer.

Regards

Hi, Christian,

Yes, thanks. I have resolved the mouse pointer issue after installation the guest additions.

Regards.

On Fri, Oct 30, 2015 at 6:49 PM, Christian Helmuth < christian.helmuth@...1...> wrote:

Hi Vincent,

On Fri, Oct 30, 2015 at 04:50:32PM +0800, Vincent Digital wrote:

...

Hi,

With the previous Turmvilla scenario, I wish to setup two virtualbox sessions, one running LInux process and the other running Windows, concurrently. I created a new Win7 subsystem, emulating the LInux subsystem, with new vm_win7.vdi.

However, I could startup only one of each sessions from NOUX, either Windows or Linux, but not both sessions at the same time. From CLI

monitor,

...

I could see that RAM is allocated separately for both sessions. I suspect some concurrency issue but could not find the issue.

I've attached the log from captured from NOUX.

What puzzles me in your log is the following

342: [cli_monitor -> linux -> vbox] EMT-0 PDMR3ThreadSuspend -> rc=VERR_TIMEOUT enmState=2 suspending 'nic_thread' 343: [cli_monitor -> linux -> vbox] PDMR3ThreadSuspend -> rc=VERR_TIMEOUT enmState=2 suspending 'nic_thread'

Could you please disable networking like follows in both vbox configurations and retry?

• <Adapter slot="0" enabled="true" MACAddress="0800271D7901" cable="true"

speed="0" type="82540EM">

• <Adapter slot="0" enabled="false" MACAddress="0800271D7901" cable="true"

speed="0" type="82540EM">

In the log, win7 vbox appears only after the assertion in linux vbox. Currently, I've no idea why win7 gets stuck in the middle of initialization. Later in the log, there's another try to start linux vbox if I'm not mistaken, which also did not succeed.

It may also matter if the base services incl. core and NOVA log some diagnostics in the time span of the multiple vbox startup. Could you please check the serial log for suspicious messages?

...

Another issue I encountered is that the virtual box mouse pointer in the WIndows session and the Nitpicker mouse pointer can't seem to merge together unlike the Linux session where both pointers are merged.

I suspect your Windows installation is missing the VirtualBox guest tools. In this case, the guest draws a software mouse pointer into the framebuffer which often appears not in sync with the Nitpicker pointer. So, after the guest tools are installed the Windows pointer will disappear. Looking at

https://github.com/nfeske/genode/blob/turmvilla/repos/gems/run/turmvilla.run

I also expect the mouse-pointer integration for win7 will work out of the box and the shape will be reported from the Windows guest to vbox_pointer.

Regards

Christian Helmuth Genode Labs

http://www.genode-labs.com/ · http://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

---

---

genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

Hello Vincent,

On Mon, Nov 02, 2015 at 06:30:30PM +0800, Vincent Digital wrote:

However, after adding in the "nic_bridge", I could not access the network (Internet) from either the Windows or Linux subsystem. I suspect configuration issues of the "nic_bridge". The MAC address in the log file does not change to my assigned MAC address "02:00:00:00:00:00" but my own NIC card. It seems that if I used auto assignment of VMs' IP addresses via DHCP, I would just need to configure the turmvilla.run file. Is there any other file(s) that I should change as well ?

IMO you don't need to adjust the "mac" attribute as it configures MAC address values for clients of nic_bridge. (please refer to repos/os/src/server/nic_bridge/README). The README also describes the service nic_bridge provides: It implements an ethernet bridge with proxy ARP for its clients. This way, the network packets are not mangled much and most of the time are bridged unchanged. As each nic_bridge client is seen by the LAN as dedicated network node it needs its own MAC address, which is taken from the locally administered range 02:... That's also the reason why we added the mac attribute, which allows to test several Genode hosts in the same LAN by assigning disjoint MAC address ranges.

If you are able to run a packet sniffer on your DHCP server host, you may see packets from your real NIC f0:de:... and also from the 02:... range. This is also the point where you may start to investigate if any DHCPDISCOVER packets arrive from your test machine. Maybe you could start with a more basic network scenario like

make run/netperf_lwip_bridge

from the ports repository?

Regards

Hi Vincent,

On 05.11.2015 11:18, Vincent Digital wrote:

Can I clarify with you that the nic_bridge can both support Wifi_Driver as well as the Nic_Driver. In my tests, I could only get the nic_bridge to work with the Nic_Driver to support 2 clients (Windows + Drivers).

I only use the nic_bridge + nic_drv on Turmvilla. Never tried the wifi driver + nic_bridge.

Did somebody else ? Could be that the wifi driver don't/can't cope with multiple mac addresses - generated by the nic_bridge for each client ? The nic_drv is running in promiscuous mode to handle this, maybe something has to be done also for the wifi driver - so - is just guessing from my side.

Alex.

Thanks.

On Fri, Oct 30, 2015 at 6:57 PM, Alexander Boettcher < alexander.boettcher@...1...> wrote:

...

On 30.10.2015 11:49, Christian Helmuth wrote:

...

What puzzles me in your log is the following

342: [cli_monitor -> linux -> vbox] EMT-0 PDMR3ThreadSuspend ->

rc=VERR_TIMEOUT enmState=2 suspending 'nic_thread'

...

343: [cli_monitor -> linux -> vbox] PDMR3ThreadSuspend ->

rc=VERR_TIMEOUT enmState=2 suspending 'nic_thread'

...

Could you please disable networking like follows in both vbox configurations and retry?

• <Adapter slot="0" enabled="true" MACAddress="0800271D7901"

cable="true" speed="0" type="82540EM">

...

• <Adapter slot="0" enabled="false" MACAddress="0800271D7901"

cable="true" speed="0" type="82540EM">

...

I suspect you will have to add a nic session multiplexer (nic_bridge), since you are now trying to start two nic clients (linux + windows) and the wifi driver can serve only one client.

Cheers,

Alex.

---

---

genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

---

---

genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hello,

On 11/06/2015 11:41 AM, Christian Helmuth wrote:

Hello Vincent,

On Thu, Nov 05, 2015 at 06:18:36PM +0800, Vincent Digital wrote:

...

Can I clarify with you that the nic_bridge can both support

Wifi_Driver as

...

well as the Nic_Driver. In my tests, I could only get the nic_bridge to work with the Nic_Driver to support 2 clients (Windows + Drivers).

We had a short offline discussion this morning and after that it's unclear if the ProxyARP approach could work with WiFi as it is currently used with the wifi_drv. So, if anybody on the list has some experience with bridging and Wifi, please speak up.

I have a setup where Arora and VirtualBox are connected to the nic_bridge, which is connected to the wifi_drv and both clients can load content from the Internet. But it seems to depend on the access point used (in my case a "König CMP-WNROUT40") and perhaps also on the wireless adapter (in my case an Intel Wireless 7265).

Christian

Hi Vincent,

Thanks for sharing your experiences on Wi Fi driver and NIC driver with NIC Bridge. With renewed confidence, I've persisted with a new GIT version of Genode and now I am happy to share that I'm able to get NIC Bridge working with Wi Fi driver as well for 2 x sessions of Virtualbox, one with an Ubuntu Linux guest and the other with a Windows 7 guest. The funny thing is that I used the same configuration file as previous so I am not sure why it works now while previously it could not.

great that you got it working! :-)

As I proceed to use Turmvilla as regular, I would like to share 2 issues and see if there are any suggestions to improve.

a. Shutdown of VMM - Fixes #1687. I would attempt to shutdown my Windows or Linux session and the VMM window would hang. I thought it was fixed by Fixes #1687 but it seems the problem is still there. I have checked and double-checked that Fixes #1687 is in. Any idea ? I've not manage to capture the logs for this issue.

I can confirm this issue. The mechanism should work like this:

* At the end of the shutdown procedure of the guest OS, the guest OS is expected to power off the machine.

* VirtualBox detects the attempt of the guest OS to power off the machine and responds by telling its parent that it want to exit (via the 'exit' operation on the parent interface).

* The init instance of the 'linux' subsystem looks into the <start> node of the virtualbox component. If the node is configured with <exit propagate="yes"/>, init responds to the exit of the child by exiting.

* The parent of the 'linux' init instance is the CLI monitor. It handles the exit request by killing the corresponding subsystem.

In my setup, the shutdown and automated killing of the VirtualBox subsystem works sometimes. But in most cases, the shutdown of the guest seem to remain undetected by the VMM. I guess that the power-down procedure of the guest OS is not properly recognized by VirtualBox, but the information could be lost somewhere else on the way to CLI monitor.

However, this behavior is merely an inconvenience. It is still possible to kill the subsystem manually via the CLI monitor to regain the memory resources used by the subsystem.

b. Memory leak or stability issue. I have encountered a couple of times leaving the Turmvilla scenario with both sessions running (just web browsers) for 1-2 hours. When I returned to the machine, the entire computer hanged up. I could not even access CLI terminal to terminate anything. As usual, besides the logs, any suggestions to troubleshoot the issue.

I had this issue twice since the recent update of my turmvilla branch. When it happened, the LOG messages indicated repeated attempts by rump_fs to allocate more memory until it eventually got stuck. Once rump_fs stops working, all users of the Genode partition will block forever. This includes the VMs and also CLI monitor (since it obtains the subsystem configurations from the Genode partition).

Emery recently discovered an allocation issue in rump_fs that may be related to the problem. But I haven't tried the fix yet:

https://github.com/genodelabs/genode/issues/1752#issuecomment-152488824

Cheers Norman

Hi Vincent,

...

b. Memory leak or stability issue. I have encountered a couple of times leaving the Turmvilla scenario with both sessions running (just web browsers) for 1-2 hours. When I returned to the machine, the entire computer hanged up. I could not even access CLI terminal to terminate anything. As usual, besides the logs, any suggestions to troubleshoot the issue.

I had this issue twice since the recent update of my turmvilla branch. When it happened, the LOG messages indicated repeated attempts by rump_fs to allocate more memory until it eventually got stuck. Once rump_fs stops working, all users of the Genode partition will block forever. This includes the VMs and also CLI monitor (since it obtains the subsystem configurations from the Genode partition).

Emery recently discovered an allocation issue in rump_fs that may be related to the problem. But I haven't tried the fix yet:

https://github.com/genodelabs/genode/issues/1752#issuecomment-152488824

the fix did not solve my problem. However, during the past days of intensive testing, we were able to find and fix several issues, which already entered the staging branch. Right now, I am happily using most of those fixes the following work-in-progress branch of Turmvilla:

https://github.com/nfeske/genode/commits/turmvilla_intel_fb

Cheers Norman