Genode 17.05 dde_rump ISO filesystem

[Steven Harp]

Hi:
  While evaluating file system alternatives, I ran some tests
of the dde_rump file system code (Genode 17.05 master/HEAD
on Ubuntu 16.04 / x86_64).

The EXT2 and FAT file system tests work as expected (although the
latter benefited from a ).

The ISO file system however left me a puzzle (trace below; default
caps line added to run file.) The same results appear under builds
x86_{32,64} x KERNEL={linux,nova}.

Any ideas regarding what might be going wrong?  The prepared test
image fs.iso appears to have the intended file "test.txt" on it.

Best,
  Steve

> 
> make run/rump_iso
> ...
> [init] child "rom_blk" announces service "Block"
> [init] child "timer" announces service "Timer"
> [init -> rom_blk] Using file=fs.iso as device with block size 2048.
> [init -> rump_fs] Using cd9660 as file system
> [init -> rump_fs] RUMP ver: 17
> [init -> rump_fs] RUMP_THREADS
> [init -> rump_fs] RUMP_VERBOSE
> [init -> rump_fs] _RUMPUSER_NCPU
> [init -> rump_fs] RUMP_MEMLIMIT
> [init -> rump_fs] asserting rump kernel 4064 KB of RAM
> [init -> rump_fs] BOOTSTRAP
> [init -> rump_fs] RUMP_NVNODES
> [init -> rump_fs] RUMP_BLKFAIL
> [init -> rump_fs] RUMP_BLKSECTSHIFT
> [init -> rump_fs] RUMP_MODULEBASE
> [init -> rump_fs] _RUMPUSER_HOSTNAME
> [init] child "rump_fs" announces service "File_system"
> [init] child "fs_rom" announces service "ROM"
> [init -> fs_rom] request for test-iso
> [init -> fs_rom] Error: /test-iso: lookup_failed
> [init -> fs_rom] request for ld.lib.so
> [init -> fs_rom] Error: /ld.lib.so: lookup_failed
> [init -> fs_rom] Error: /ld.lib.so: lookup_failed
> [init -> fs_rom] Error: /ld.lib.so: lookup_failed
> [init -> fs_rom] Error: /test-iso: lookup_failed
> [init -> fs_rom] Error: /test-iso: lookup_failed
> ...
> (timeout)


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Networking Support in VirtualBox

[Chris Rothrock]

The top entry from git log:

commit 5e3e8073467628cd2a88fc1025be9a157f976e57
Author: Christian Helmuth 
Date:   Wed May 31 16:05:53 2017 +0200

version: 17.05

This is the version pulled when I started with a fresh environment with the
command:

git clone https://github.com/genodelabs/genode

When I do a fresh pull, should this pull the latest commit, of just to the
base version (17.05 in this case)?


On Tue, Jul 25, 2017 at 10:44 AM, Christian Helmuth <
christian.helm...@genode-labs.com> wrote:

> Chris,
>
> On Tue, Jul 25, 2017 at 09:46:52AM -0400, Chris Rothrock wrote:
> > The run recipe I am using is virtualbox.run.  In this recipe there is no
> > indications that the ACPI has any configurable components.  These
> > capabilities must be set in another file that this recipe is calling -
> > please tell me where these would be found so that I can adjust the caps
> on
> > acpi.
>
> The capability configuration is factored out into
> repos/base/run/platform_drv.inc. You may change the acpi_drv caps in
> line 133
>
>   
>
> Which Genode branch/version/commit hash are you using? I never
> experienced a log like yours where one and the same log contents
> appear three times pasted over each other.
>
> --
> Christian Helmuth
> Genode Labs
>
> https://www.genode-labs.com/ · https://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
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> genode-main mailing list
> genode-main@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>



-- 


Thank You,

Chris Rothrock
Senior System Administrator
(315) 308-1637
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Networking Support in VirtualBox

[Christian Helmuth]

Chris,

On Tue, Jul 25, 2017 at 09:46:52AM -0400, Chris Rothrock wrote:
> The run recipe I am using is virtualbox.run.  In this recipe there is no
> indications that the ACPI has any configurable components.  These
> capabilities must be set in another file that this recipe is calling -
> please tell me where these would be found so that I can adjust the caps on
> acpi.

The capability configuration is factored out into
repos/base/run/platform_drv.inc. You may change the acpi_drv caps in
line 133

  

Which Genode branch/version/commit hash are you using? I never
experienced a log like yours where one and the same log contents
appear three times pasted over each other.

-- 
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Networking Support in VirtualBox

[Chris Rothrock]

There was no arbitrary concatenation at all - this was the entirety of the
log as it was transmitted across the serial port from the moment the Genode
boot started with the NOVA kernel.  If any concat was done, it was due to
the unmodified code provided with the source.

The 32 bit scenario was intended but next time around I will also try on
the 64 bit just to compare logs.

I am unclear as to why this would be even attempting to use more than 4
GB.  Yes, the PC has more than 4 and I have made no modifications to even
attempt to use more than 4 GB.  Again, if this is unintentional, it was not
by my design and how can we force it to use only up to the 4 GB boundary?

The run recipe I am using is virtualbox.run.  In this recipe there is no
indications that the ACPI has any configurable components.  These
capabilities must be set in another file that this recipe is calling -
please tell me where these would be found so that I can adjust the caps on
acpi.



On Tue, Jul 25, 2017 at 5:55 AM, Christian Helmuth <
christian.helm...@genode-labs.com> wrote:

> Hello Chris,
>
> your log is very hard to read as it seems to arbitrarily concatenate
> several logs or multiple copies of the same log. I suggest you store
> one log file per boot of the test machine and attach the resulting
> file to your email in the future.
>
> I'll add some comments about what I read in your log in the following
> (interleaved with the original/cleaned up log text).
>
> On Mon, Jul 24, 2017 at 08:43:51PM -0400, Chris Rothrock wrote:
> > NOVA Microhypervisor v7-8bcd6fc (x86_32): Jul 21 2017 10:14:19 [gcc
> 6.3.0]
>
> You seem to run a 32-bit build of NOVA, which may not interfere with
> your scenario but may not be what you intended to do.
>
> > [ 0] TSC:3408373 kHz BUS:0 kHz
> > [ 0] CORE:0:0:0 6:9e:9:1 [48] Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
> > [ 1] CORE:0:1:0 6:9e:9:1 [48] Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
> > [ 3] CORE:0:3:0 6:9e:9:1 [48] Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
> > [ 2] CORE:0:2:0 6:9e:9:1 [48] Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
> > [ 0] disabling super pages for DMAR
> > Hypervisor features VMX
> > Hypervisor reports 4x1 CPUs
> > CPU ID (genode->kernel:package:core:thread) remapping
> >  remap (0->0:0:0:0) boot cpu
> >  remap (1->1:0:1:0)
> >  remap (2->2:0:2:0)
> >  remap (3->3:0:3:0)
> > Hypervisor info page contains 24 memory descriptors:
> > core image  [0010,029b9000)
> > binaries region [00228000,029b9000) free for reuse
> > detected physical memory: 0x - size: 0x0008ec00
> > use  physical memory: 0x - size: 0x0008e000
> > detected physical memory: 0x0010 - size: 0xb2bfb000
> > use  physical memory: 0x0010 - size: 0xb2bfb000
> > detected physical memory: 0xb3aff000 - size: 0x1000
> > use  physical memory: 0xb3aff000 - size: 0x1000
> > detected physical memory: 0x - size: 0x3f80
>
> NOVA detects some unusable RAM above 4 GiB.
>
> > :virt_alloc: Allocator 0x1f5f84 dump:
> >  Block: [2000,3000) size=4K avail=0 max_avail=0
> >  Block: [3000,4000) size=4K avail=0 max_avail=0
> >  Block: [4000,5000) size=4K avail=0 max_avail=0
> >  Block: [5000,6000) size=4K avail=0 max_avail=0
> >  Block: [6000,7000) size=4K avail=0 max_avail=0
> >  Block: [7000,8000) size=4K avail=0 max_avail=0
> >  Block: [8000,9000) size=4K avail=0 max_avail=0
> >  Block: [9000,a000) size=4K avail=0 max_avail=0
> >  Block: [a000,b000) size=4K avail=0 max_avail=0
> >  Block: [b000,c000) size=4K avail=0 max_avail=0
> >  Block: [c000,d000) size=4K avail=0 max_avail=0
> >  Block: [d000,e000) size=4K avail=0 max_avail=0
> >  Block: [e000,f000) size=4K avail=0 max_avail=0
> >  Block: [f000,0001) size=4K avail=0 max_avail=0
> >  Block: [0001,00011000) size=4K avail=0 max_avail=0
> >  Block: [00011000,00012000) size=4K avail=0 max_avail=0
> >  Block: [00012000,00013000) size=4K avail=0 max_avail=0
> >  Block: [00013000,00014000) size=4K avail=0 max_avail=2619220K
> >  Block: [00014000,00015000) size=4K avail=0 max_avail=0
> >  Block: [00015000,00016000) size=4K avail=0 max_avail=0
> >  Block: [00016000,00017000) size=4K avail=0 max_avail=0
> >  Block: [00017000,00018000) size=4K avail=0 max_avail=0
> >  Block: [00018000,00019000) size=4K avail=0 max_avail=0
> >  Block: [00019000,0001a000) size=4K avail=0 max_avail=908K
> >  Block: [0001a000,0001b000) size=4K avail=0 max_avail=0
> >  Block: [0001b000,0001c000) size=4K avail=0 max_avail=908K
> >  Block: [0001c000,0001d000) size=4K avail=0 max_avail=0
> >  Block: [0001d000,0010) size=908K avail=908K max_avail=908K
> >  Block: [00228000,00229000) size=4K avail=0 max_avail=0
> >  Block: [00229000,0022a000) size=4K avail=0 max_avail=2619220K
> >  Block: [0022a000,0022b000) size=4K avail=0 max_avail=0
> >  Block: [0022b000,a000) size=2619220K avail=2619220K
> max_avail=2619220K
> >  Block: [b000,bfeff000) 

Re: Using Genode 17.05 with Fiasco.OC

[Norman Feske]

Hi Jörg,

thank you for introducing yourself and for your interest in Genode!

> I started a month ago with Gnode hello tutorial and play around with them.
> Therefore, I call myself a newbie :-)
> But at the end, I will use Genode on my laptop (like turmvilla example) and
> start to develop some application on it :-). But first, I think about to
> start with a small server. The host provider that I use, use a QEMU with
> KVM enable as virtual server. So it is not possilbe to use NOVA on it
> because of the KVM enabled featuer (I think) but
> Fiasco.OC works.

We added the -no-kvm option in '/etc/build.conf' by default a
few years ago when Qemu/KVM did not implement all the features required
by NOVA. There should be a good chance that NOVA works with recent Qemu
versions. Could you give NOVA on Qemu/KVM another spin and report the
specific problem you encountered?

In general, I warmly recommend using NOVA over Fiasco.OC as NOVA is the
most commonly used (and thoroughly tested) Genode base platform on x86.

> The problem:
> So I try to build/create a image from the lighttpd example with Fiasco.OC
> kernel. The image started but the lighttpd does not work. Also the
> hello tutorial with Fiasco.OC does not work anymore.
> 
> I checked the issue tracker on github but I didn't find any issue about
> that.
> 
> 
> What I figure out:
> - Hello tutorial
>  When I increase in the hello tutorial the "default caps" from 50 to 54
> in  the config, then the tutorial is working with Fiasco.OC kernel.

I think that this issue is fixed in the current master branch,
specifically by commit [1]. Prior this change, Genode's core consumed
one additional (dataspace) capability per RPC object when running on
Fiasco.OC, which remained undetected until we added the capability
accounting in 17.05.

[1]
https://github.com/genodelabs/genode/commit/ba9ef7fdee07c42bc772c8b515bc9d808c401112

> - lighttpd
>  Here I must first "move" the timer service in the config (see my commit
>  on github [1]) then it works with the NOVA kernel.

The position of the timer  node within the config should not make
any difference.

I just tried out the lighttpd.run script with KERNEL=foc on x86_32. It
works when adding the '' declaration. Opening
'http://localhost:/' in the web browser shows the "Hello Genode" page.

>  With Fiasco.OC I get
>  following error:
>  Error: nic_drv -> : environment ROM session denied (label="device_pd",
> ram_quota=6144, cap_quota=3, diag=0)
>  I try to add "device_pd" in the boot modules because it is missing in the
>  rom fs but device_pd is not compile for the Fiasco.OC, only for NOVA.
>  I found out following in:
>  genode-src/repos/os/src/drivers/platform/spec/x86/device_pd/target.mk
>  It looks like device_pd is only build for NOVA.

Admittedly, the log messages look a bit scary but this output is normal
on Fiasco.OC where the platform driver does not support device PDs
(IOMMU). We should probably dim the noise a bit. ;-)

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Blocking wait for interrupt

[Sebastian Sumpf]

Hi Johannes,

On 07/25/2017 08:54 AM, Johannes Kliemann wrote:
> Hi,
> 
> I'm currently writing a dde_linux driver that requires to wait for an
> interrupt to be handled.
> It basically initializes the hardware and then waits for an event to
> occur. This event is usually triggered by the interrupt (respectively
> its handler) which occurs after hardware initialization.
> My problem is that this interrupt doesn't appear while the function
> triggering it didn't return. So when this function blocks to wait for
> the interrupt, a deadlock is created. Besides using the timer I tried to
> block the execution with a semaphore creating the same problem.
> Creating an async version is no option due to the architecture of the
> Linux driver.
> 
> How are interrupts handled in this case? What causes them to block and
> how can I work around this?
> 

If I gather your description correctly, you are executing Linux code
from the entrypoint context. If this code somehow blocks, lets say by
calling 'wait_event_interruptible' or something else, the EP cannot
receive signals, and therefore no interrupts. The solution to this
problem are 'Lx::Task'(s). All Linux code should be executed by these
tasks, which are able to block and can be unblocked by the EP upon
signal reception. A small example can be found under
'dde_linux/src/drivers/framebuffer/intel/main.cc', there the Linux code
is executed by a task in 'run_linux', which is woken up by the
'Policy_agent' signal handler.

Regards,

Sebastian

P.S. I hope you are porting a driver and not writing one from scratch ;)



-- 
Sebastian Sumpf
Genode Labs

http://www.genode-labs.com · http://genode.org

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




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Networking Support in VirtualBox

[Christian Helmuth]

Hello Chris,

your log is very hard to read as it seems to arbitrarily concatenate
several logs or multiple copies of the same log. I suggest you store
one log file per boot of the test machine and attach the resulting
file to your email in the future.

I'll add some comments about what I read in your log in the following
(interleaved with the original/cleaned up log text).

On Mon, Jul 24, 2017 at 08:43:51PM -0400, Chris Rothrock wrote:
> NOVA Microhypervisor v7-8bcd6fc (x86_32): Jul 21 2017 10:14:19 [gcc 6.3.0]

You seem to run a 32-bit build of NOVA, which may not interfere with
your scenario but may not be what you intended to do.

> [ 0] TSC:3408373 kHz BUS:0 kHz
> [ 0] CORE:0:0:0 6:9e:9:1 [48] Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
> [ 1] CORE:0:1:0 6:9e:9:1 [48] Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
> [ 3] CORE:0:3:0 6:9e:9:1 [48] Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
> [ 2] CORE:0:2:0 6:9e:9:1 [48] Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
> [ 0] disabling super pages for DMAR
> Hypervisor features VMX
> Hypervisor reports 4x1 CPUs
> CPU ID (genode->kernel:package:core:thread) remapping
>  remap (0->0:0:0:0) boot cpu
>  remap (1->1:0:1:0)
>  remap (2->2:0:2:0)
>  remap (3->3:0:3:0)
> Hypervisor info page contains 24 memory descriptors:
> core image  [0010,029b9000)
> binaries region [00228000,029b9000) free for reuse
> detected physical memory: 0x - size: 0x0008ec00
> use  physical memory: 0x - size: 0x0008e000
> detected physical memory: 0x0010 - size: 0xb2bfb000
> use  physical memory: 0x0010 - size: 0xb2bfb000
> detected physical memory: 0xb3aff000 - size: 0x1000
> use  physical memory: 0xb3aff000 - size: 0x1000
> detected physical memory: 0x - size: 0x3f80

NOVA detects some unusable RAM above 4 GiB.

> :virt_alloc: Allocator 0x1f5f84 dump:
>  Block: [2000,3000) size=4K avail=0 max_avail=0
>  Block: [3000,4000) size=4K avail=0 max_avail=0
>  Block: [4000,5000) size=4K avail=0 max_avail=0
>  Block: [5000,6000) size=4K avail=0 max_avail=0
>  Block: [6000,7000) size=4K avail=0 max_avail=0
>  Block: [7000,8000) size=4K avail=0 max_avail=0
>  Block: [8000,9000) size=4K avail=0 max_avail=0
>  Block: [9000,a000) size=4K avail=0 max_avail=0
>  Block: [a000,b000) size=4K avail=0 max_avail=0
>  Block: [b000,c000) size=4K avail=0 max_avail=0
>  Block: [c000,d000) size=4K avail=0 max_avail=0
>  Block: [d000,e000) size=4K avail=0 max_avail=0
>  Block: [e000,f000) size=4K avail=0 max_avail=0
>  Block: [f000,0001) size=4K avail=0 max_avail=0
>  Block: [0001,00011000) size=4K avail=0 max_avail=0
>  Block: [00011000,00012000) size=4K avail=0 max_avail=0
>  Block: [00012000,00013000) size=4K avail=0 max_avail=0
>  Block: [00013000,00014000) size=4K avail=0 max_avail=2619220K
>  Block: [00014000,00015000) size=4K avail=0 max_avail=0
>  Block: [00015000,00016000) size=4K avail=0 max_avail=0
>  Block: [00016000,00017000) size=4K avail=0 max_avail=0
>  Block: [00017000,00018000) size=4K avail=0 max_avail=0
>  Block: [00018000,00019000) size=4K avail=0 max_avail=0
>  Block: [00019000,0001a000) size=4K avail=0 max_avail=908K
>  Block: [0001a000,0001b000) size=4K avail=0 max_avail=0
>  Block: [0001b000,0001c000) size=4K avail=0 max_avail=908K
>  Block: [0001c000,0001d000) size=4K avail=0 max_avail=0
>  Block: [0001d000,0010) size=908K avail=908K max_avail=908K
>  Block: [00228000,00229000) size=4K avail=0 max_avail=0
>  Block: [00229000,0022a000) size=4K avail=0 max_avail=2619220K
>  Block: [0022a000,0022b000) size=4K avail=0 max_avail=0
>  Block: [0022b000,a000) size=2619220K avail=2619220K max_avail=2619220K
>  Block: [b000,bfeff000) size=261116K avail=261116K max_avail=2619220K
>  Block: [bff04000,bfffd000) size=996K avail=996K max_avail=996K
>  => mem_size=2951536640 (2814 MB) / mem_avail=2951413760 (2814 MB)
> 
> :phys_alloc: Allocator 0x1f4f18 dump:
>  Block: [1000,2000) size=4K avail=0 max_avail=0
>  Block: [2000,3000) size=4K avail=0 max_avail=0
>  Block: [3000,4000) size=4K avail=0 max_avail=0
>  Block: [4000,5000) size=4K avail=0 max_avail=0
>  Block: [5000,6000) size=4K avail=0 max_avail=0
>  Block: [6000,7000) size=4K avail=0 max_avail=0
>  Block: [7000,8000) size=4K avail=0 max_avail=0
>  Block: [8000,9000) size=4K avail=0 max_avail=0
>  Block: [9000,a000) size=4K avail=0 max_avail=0
>  Block: [a000,b000) size=4K avail=0 max_avail=0
>  Block: [b000,c000) size=4K avail=0 max_avail=0
>  Block: [c000,d000) size=4K avail=0 max_avail=2014484K
>  Block: [d000,e000) size=4K avail=0 max_avail=0
>  Block: [e000,f000) size=4K avail=0 max_avail=0
>  Block: [f000,0001) size=4K avail=0 max_avail=0
>  Block: [0001,00011000) size=4K avail=0 max_avail=0
>  Block: [00011000,00012000) size=4K avail=0 

Blocking wait for interrupt

[Johannes Kliemann]

Hi,

I'm currently writing a dde_linux driver that requires to wait for an
interrupt to be handled.
It basically initializes the hardware and then waits for an event to
occur. This event is usually triggered by the interrupt (respectively
its handler) which occurs after hardware initialization.
My problem is that this interrupt doesn't appear while the function
triggering it didn't return. So when this function blocks to wait for
the interrupt, a deadlock is created. Besides using the timer I tried to
block the execution with a semaphore creating the same problem.
Creating an async version is no option due to the architecture of the
Linux driver.

How are interrupts handled in this case? What causes them to block and
how can I work around this?

Regards,

JK



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main