users

users@lists.genode.org

7 participants
2332 discussions

thread cancel_blocking usage, kernels
by Steven Harp 18 Oct '17

18 Oct '17

The Genode book suggests that an RPC caller can protect itself from blocking in a stalled server by creating a watchdog thread to monitor the process of the call, and cancel it if it takes too long. Is there a robust/canonical example of using cancel_blocking in this way? My experiment with this (Genode 17.08, x86_32) seems to work as expected--but, only with the OKL4 kernel!? With nova, hw, and seL4, the cancel_blocking() method executes but seemingly to no effect: the thread continues to wait on the (contrived) very slow RPC call, which eventually completes. Suggestions? // Steve Harp

2 3

additional base linux core
by Johannes Kliemann 18 Oct '17

18 Oct '17

Hi, I want to create a base-linux core that is able to run on a bare linux kernel to use it such as any other microkernel in Genode. Since base-linux already implements some of the required interfaces I'd like to reuse the already existing components as much as possible. Yet I'm not sure what the way to go is: - Copying the contents of base-linux into a new repository would probably make an easy start but lead to code duplication (and I would probably have to port all updates of base-linux). - I already tried to reinclude the contents of base-linux (my repository currently only consists of Makefile fragments). Even though it builds it's often quite hacky to relocate some of the $(REP_DIR) entries to base-linux without breaking $(REP_DIR) itself. Also external libs sometimes don't seem to find the correct headers. - Directly extending base-linux would avoid these problems but this would require either a switch to choose between the original and the new functionality of this core or even better a "hybrid" core that is able to run in both environments. Also this change would probably need to get upstream (I don't know if this kind of change would be a problem generally). What is the recommended way to do this? Regards, Johannes

2 1

vbox4_ubuntu_16_04_64.run recipe
by Chris Rothrock 16 Oct '17

16 Oct '17

I am trying to get a working virtual machine in Genode with the recipe vbox4_ubuntu_16_04_64.run but I am unsure where the virtual disk image file (.vdi) should reside so that the VirtualBox module loads it properly. I am able to get a good compile and it seems to boot to Genode just fine and I even see the CPU status meter but I don't get the virtual machine booting up. I created a VirtualBox VM with this same name with a VDI and completed a full install of Ubuntu 16.04 64 bit and am trying to use this image file. As far as I can tell, the VDI meets all the parameters and works fine with using both Linux and Windows VirtualBox to run. Any instructions on getting this (and possibly Windows VMs to work) would be greatly appreciated. Thanks in advance, Chris Rothrock

3 2

Provide session from libc code
by Johannes Kliemann 16 Oct '17

16 Oct '17

Hi, I tried to create a provide an input session from a libc (in this case an Qt application). If I just run it from the Main struct it will correctly announce the session but since Main never returns, no client will be able to use it. I tried to circumvent this by putting the application into a separate thread but this led to the following error: > Error: void Libc::Kernel::run(Libc::Application_code&) called from non-kernel context Running this Qt application without wrapping it into with_libc makes it segfault on initialization. What is the correct way to do this? My current main is at [1]. Regards, Johannes [1]: https://github.com/jklmnn/componolit/blob/478490f05f23ce4c64b4a386377a1212c…

2 1

default-route config
by Johannes Kliemann 13 Oct '17

13 Oct '17

Hi, I tried to completely remove the default-route with any-service/any-child from my runfile and only explicitly allow services to components. I have created a minimal example with only the timer driver [1] but I wasn't able to explicitly grant service access to the timer driver. When I prepend <any-service> with an explicit > <service name="PD">> <child name="timer"/> > </service> the timer driver fails with a denied PD environment session. What is the correct approach to do this? Regards, Johannes

2 2

[FWD] FOSDEM 2018 - Microkernels developer room - CfP
by Josef Söntgen 09 Oct '17

09 Oct '17

----- Forwarded message from Jakub Jermář <jakub@...85...> ----- FOSDEM 2018 - Microkernels developer room CALL FOR PARTICIPATION The developers of several free and open-source microkernel-based operating systems will meet at FOSDEM 2018 [1] in Brussels, Belgium and will share a developer room on Saturday of February 3, 2018 [2]. The devroom is currently looking for content in the form of talks and activities related to the area of microkernel-based operating systems. Possible topics include, but are not limited to: * Introduction of a specific OS or framework * Design of subsystems and the general architecture of an OS * Enabling support for hardware (architectures, device drivers) * Used languages and tools * Maintenance and testing * Security and robustness * Trends and challenges * Use cases, experiences, lessons learned and demos Please use the Pentabarf [3] system to submit your proposals and file it under the track “Microkernels devroom”. You do not need to create a new account if you already have one. When in doubt, please use the devroom mailing list [4]. If you do not want to give a talk yourself, you may still send suggestions for what else you would like to see, or do in the devroom. Please send your suggestions to the mailing list. The deadline for your proposal is on December 8. Make sure to include the following in your proposal: * Title of your talk (will be printed in the FOSDEM booklet) * Your full name (will be printed in the FOSDEM booklet) * A short abstract (one or two paragraphs) * Duration of your talk (please, at least 25 and no longer than 45 min) The official devroom schedule (along with the accepted talks) will be announced on December the 15th on the devroom's mailing list and the speakers will be notified via e-mail. The schedule will also be published on the FOSDEM website. About FOSDEM FOSDEM is a two-day event organised by volunteers to promote the widespread use of free and open source software. Taking place in the beautiful city of Brussels (Belgium), FOSDEM is widely recognised as the best such conference in Europe. FOSDEM covers a wide spectrum of free and open source software projects, and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) with network/internet connectivity and projectors where teams can meet and showcase their projects. Devrooms are a place for teams to discuss, hack and publicly present latest directions, lightning talks, news and discussions. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. Every year, FOSDEM hosts more than 5000 developers at the ULB Solbosch campus. Participation and attendance is totally free, though the organisers gratefully accept donations and sponsorship. No registration necessary. About the devroom Since the first Microkernel devroom in 2012 this devroom has been part of each following FOSDEM. By now it has become a somewhat institutionalized tradition for the microkernel community to meet there; to this date over a dozen projects have participated in one way or another. Each of the projects face similar challenges but come up with partially different solutions. Therefore, the goal of the Microkernel devroom is to bring the various projects together, let them exchange ideas, cross-pollinate and socialize. Social events It also has become a habit that the microkernel projects dine together somewhere in downtown Brussels after the devroom closes. The year 2018 will not be any different, so there is going to be a microkernel family dinner on Saturday night. The exact location and time will be specified later. Consult the FOSDEM web and other projects for additional social events such as the famous FOSDEM-organized Friday Beer Event and the FOSDEM-arranged free sightseeing tours for spouses. Important dates recap * 08.12.2017: Deadline for submissions * 15.12.2017: Schedule published and speakers notified of acceptance * 03.02.2018: The devroom takes places Links [1] http://fosdem.org/ [2] https://fosdem.org/2018/practical/transportation/ [3] https://penta.fosdem.org/submission/FOSDEM18 [4] https://lists.fosdem.org/listinfo/microkernel-devroom See you all at FOSDEM! _______________________________________________ microkernel-devroom mailing list microkernel-devroom@...86... https://lists.fosdem.org/listinfo/microkernel-devroom ----- End forwarded message -----

1 0

run/demo in VirtualBox
by Thomas Dundon 05 Oct '17

05 Oct '17

Hi, I cannot get the basic demo to work inside my VM. Here's my setup: - x86_64 machine running - Windows 7 running - VirtualBox 5.1.28 running - Ubuntu 16.04 My process within the Ubuntu VM was: - Installed the various tools to build (genode-toolchain-17.05, libsdl2-dev, etc) - Ran git clone to get Genode 17.08 - Ran *./tool/create_builddir linux BUILD_DIR=../build* - Changed *build.conf* to enable MAKE += -j4 - Ran *make run/demo* Everything builds fine but nothing significant happens. Here's the console output (post build): using 'core-linux' as 'core' using 'ld-linux.lib.so' as 'ld.lib.so' using 'linux_timer_drv' as 'timer' spawn ./core Genode 17.08 <local changes> 17592186044415 MiB RAM and 8997 caps assigned to init Warning: blocking canceled in entrypoint constructor <Demo just sits here until I press Ctrl-C> If I check the process list (before the Ctrl-C) I don't see anything other than *make*, *expect*, and *core*. After attaching gdb to the (unstripped) *core *process I see that one thread is sleeping in* _sig_rec->block_for_signal()* and another thread is sleeping in *_wait_for_exit_sem.down()*. The huge RAM allocation for init seems unreasonable, but I saw some similar output in other posts. Is the "blocking canceled" warning to be expected? Should I see the other processes listed in *launchpad.config* running? Just to be safe I've redone all these steps multiple times and even built the genode toolchain from source. What should I check next? Thanks, Tom

2 2

catching Socketfs Inaccessible exceptions
by Steven Harp 04 Oct '17

04 Oct '17

Experimenting with the VFS socket plugin, I'm tripping over an exception that I'm not sure how to handle. This is demonstrated in the "netty_tcp" test, which launches two echo servers, one listening on port 80, and another on port 8080. Both servers launch and become operational on about 25% of runs (under x86_64, nova kernel, QEMU, user network); on the remaining starts, one of the servers succeeds, but the other fails like this: #+BEGIN_EXAMPLE [init -> netty-server-8080] initialize server [init -> netty-server-80] initialize server [init -> netty-server-8080] sd=0 [init -> netty-server-8080] config: port=8080 read_write=0 nonblock=0 [init -> netty-server-8080] setsockopt: SO_REUSEADDR not yet implemented - always true [init -> netty-server-80] sd=0 [init -> netty-server-80] config: port=80 read_write=0 nonblock=1 [init -> netty-server-80] setsockopt: SO_REUSEADDR not yet implemented - always true [init -> netty-server-80] Error: plugin()->open("/socket/tcp/2/listen") failed [init -> netty-server-80] Error: _fd_for_type: listen file not accessible [init -> netty-server-8080] test in blocking mode [init -> netty-server-80] Error: Uncaught exception of type 'Socket_fs::Context::Inaccessible' [init -> netty-server-80] Warning: abort called - thread: ep [init] child "netty-server-80" exited with exit value 1 #+END_EXAMPLE Empirically, it appears that the server that gets past "setsockopt:..." first will become operational--the other server usually will not. The order seems to be non-deterministic. Its not clear how to catch the 'Socket_fs::Context::Inaccessible' exception in the netty server code, or even if that is an appropriate response. Suggestions? - Steve Harp

2 1

UEFI support for x86
by Edward Sandberg 02 Oct '17

02 Oct '17

Hello, I sent the following email to the sel4 mailing list but this may be a better fit. I built Genode 17.08 with run option "image/uefi" and platform option "sel4_x86_32". I have tried booting the resulting image on a variety of machines but am not getting the behavior I expect. The machines I have tried are: * Up board (a Windows compatible Atom-based system) * Dell M3800 laptop * Dell Latitude 7280 laptop * HP ProLiant DL380 Gen9 Server * Dell Optoplex 990 * Asus P9X79 WS Motherboard with Intel Core i7-3930K The furthest I have gotten was on the UP board, which only supports UEFI boot: https://www.intel.com/content/www/us/en/support/emerging-technologies/intel… I saw serial output but no graphical output (see below). The other machines I tried to boot on didn't even give me serial output. The serial output seems to indicate that an attempt to create a framebuffer failed. Is this the correct build procedure? What hardware have you used to test UEFI boot? Does the trace below suggest any experiments to try? ***************************************************************** WARNING: no console will be available to OS Bender: Hello World. Boot config: parsing cmdline '' Boot config: console_port = 0x3f8 Boot config: debug_port = 0x3f8 Boot config: disable_iommu = false Boot config: parsing cmdline 'sel4 disable_iommu' Boot config: console_port = 0x3f8 Boot config: debug_port = 0x3f8 Boot config: disable_iommu = true module #0: start=0xeaba000 end=0xf0ff968 size=0x645968 name='image.elf' Physical Memory Region from 0 size 8f000 type 1 Physical Memory Region from 8f000 size 1000 type 4 Physical Memory Region from 90000 size e000 type 1 Physical Memory Region from 9e000 size 2000 type 2 Physical Memory Region from 100000 size 1ef00000 type 1 Adding physical memory region 0x100000-0x1f000000 Physical Memory Region from 1f000000 size 1200000 type 2 Physical Memory Region from 20200000 size 3af29000 type 1 Physical Memory Region from 5b129000 size 30000 type 2 Physical Memory Region from 5b159000 size 25000 type 3 Physical Memory Region from 5b17e000 size 5d2000 type 4 Physical Memory Region from 5b750000 size 2b9000 type 2 Physical Memory Region from 5ba09000 size 79000 type 20 Physical Memory Region from 5ba82000 size 57e000 type 1 Physical Memory Region from e0000000 size 4000000 type 2 Physical Memory Region from fea00000 size 100000 type 2 Physical Memory Region from fec00000 size 1000 type 2 Physical Memory Region from fed01000 size 1000 type 2 Physical Memory Region from fed03000 size 1000 type 2 Physical Memory Region from fed06000 size 1000 type 2 Physical Memory Region from fed08000 size 2000 type 2 Physical Memory Region from fed1c000 size 1000 type 2 Physical Memory Region from fed80000 size 40000 type 2 Physical Memory Region from fee00000 size 1000 type 2 Physical Memory Region from ffc00000 size 400000 type 2 Kernel loaded to: start=0x200000 end=0x281000 size=0x81000 entry=0x20007e ACPI: RSDP paddr=0x3c490 ACPI: RSDP vaddr=0xdfc3c490 ACPI: RSDT paddr=0x5b161028 ACPI: RSDT vaddr=0xdfd61028 ACPI: FADT paddr=0x5b1611a8 ACPI: FADT vaddr=0xdfd611a8 ACPI: FADT flags=0x421 ACPI: MADT paddr=0x5b177380 ACPI: MADT vaddr=0xdfd77380 ACPI: MADT apic_addr=0xfee00000 ACPI: MADT flags=0x1 ACPI: MADT_APIC apic_id=0x0 ACPI: MADT_APIC apic_id=0x2 ACPI: MADT_APIC apic_id=0x4 ACPI: MADT_APIC apic_id=0x6 ACPI: MADT_IOAPIC ioapic_id=1 ioapic_addr=0xfec00000 gsib=0 ACPI: MADT_ISO bus=0 source=0 gsi=2 flags=0x0 ACPI: MADT_ISO bus=0 source=9 gsi=9 flags=0xd ACPI: 4 CPU(s) detected Detected 1 boot module(s): ELF-loading userland images from boot modules: size=0xd87000 v_entry=0x2000000 v_start=0x2000000 v_end=0x2d87000 p_start=0xf100000 p_end=0xfe87000 Moving loaded userland images to final location: from=0xf100000 to=0x281000 size=0xd87000 Starting node #0 with APIC ID 0 Starting node #1 with APIC ID 2 Starting node #2 with APIC ID 4 Starting node #3 with APIC ID 6 Booting all finished, dropped to user space virtual address layout of core: overall [00002000,c0000000) core image [02000000,02d87000) ipc buffer [02d87000,02d88000) boot_info [02d88000,02d8a000) stack area [40000000,50000000) Warning: need physical memory, but Platform object not constructed yet Warning: need physical memory, but Platform object not constructed yet Warning: need physical memory, but Platform object not constructed yet Warning: need physical memory, but Platform object not constructed yet :phys_alloc: Allocator 0x2800df8 dump: Block: [00200000,00201000) size=4K avail=0 max_avail=0 Block: [00201000,00202000) size=4K avail=0 max_avail=0 Block: [00202000,00203000) size=4K avail=0 max_avail=0 Block: [00203000,00204000) size=4K avail=0 max_avail=0 Block: [00204000,00205000) size=4K avail=0 max_avail=0 Block: [00205000,00206000) size=4K avail=0 max_avail=0 Block: [00206000,00207000) size=4K avail=0 max_avail=0 Block: [00207000,00208000) size=4K avail=0 max_avail=0 Block: [00208000,00209000) size=4K avail=0 max_avail=0 Block: [00209000,0020a000) size=4K avail=0 max_avail=0 Block: [0020a000,0020b000) size=4K avail=0 max_avail=0 Block: [0020b000,0020c000) size=4K avail=0 max_avail=0 Block: [0020c000,0020d000) size=4K avail=0 max_avail=0 Block: [01008000,01009000) size=4K avail=0 max_avail=0 Block: [01009000,0100a000) size=4K avail=0 max_avail=0 Block: [0100a000,0100b000) size=4K avail=0 max_avail=0 Block: [0100b000,0100c000) size=4K avail=0 max_avail=0 Block: [0100c000,0100d000) size=4K avail=0 max_avail=0 Block: [0100d000,0100e000) size=4K avail=0 max_avail=0 Block: [0100e000,0100f000) size=4K avail=0 max_avail=0 Block: [0100f000,01010000) size=4K avail=0 max_avail=0 Block: [01010000,01011000) size=4K avail=0 max_avail=0 Block: [01011000,01012000) size=4K avail=0 max_avail=0 Block: [01012000,01013000) size=4K avail=0 max_avail=0 Block: [01013000,01014000) size=4K avail=0 max_avail=0 Block: [01014000,01015000) size=4K avail=0 max_avail=0 Block: [01015000,01016000) size=4K avail=0 max_avail=0 Block: [01016000,01017000) size=4K avail=0 max_avail=0 Block: [01017000,01018000) size=4K avail=0 max_avail=0 Block: [01018000,01019000) size=4K avail=0 max_avail=0 Block: [01019000,0101a000) size=4K avail=0 max_avail=0 Block: [0101a000,0101b000) size=4K avail=0 max_avail=0 Block: [0101b000,0101c000) size=4K avail=0 max_avail=0 Block: [0101c000,0101d000) size=4K avail=0 max_avail=0 Block: [0101d000,0101e000) size=4K avail=0 max_avail=0 Block: [0101e000,0101f000) size=4K avail=0 max_avail=0 Block: [0101f000,01020000) size=4K avail=0 max_avail=0 Block: [01020000,01021000) size=4K avail=0 max_avail=0 Block: [01021000,01022000) size=4K avail=0 max_avail=0 Block: [01022000,01023000) size=4K avail=0 max_avail=0 Block: [01023000,01024000) size=4K avail=0 max_avail=0 Block: [01024000,01025000) size=4K avail=0 max_avail=0 Block: [01025000,01026000) size=4K avail=0 max_avail=0 Block: [01026000,01027000) size=4K avail=0 max_avail=0 Block: [01027000,01028000) size=4K avail=0 max_avail=0 Block: [01028000,01029000) size=4K avail=0 max_avail=0 Block: [01029000,0102a000) size=4K avail=0 max_avail=0 Block: [0102a000,0102b000) size=4K avail=0 max_avail=0 Block: [0102b000,0102c000) size=4K avail=0 max_avail=0 Block: [0102c000,0102d000) size=4K avail=0 max_avail=400M Block: [0102d000,0102e000) size=4K avail=0 max_avail=0 Block: [0102e000,0102f000) size=4K avail=0 max_avail=0 Block: [0102f000,01030000) size=4K avail=0 max_avail=0 Block: [01030000,01031000) size=4K avail=0 max_avail=0 Block: [01031000,01032000) size=4K avail=0 max_avail=0 Block: [01032000,01033000) size=4K avail=0 max_avail=0 Block: [01033000,01034000) size=4K avail=0 max_avail=0 Block: [01034000,01035000) size=4K avail=0 max_avail=0 Block: [01035000,01036000) size=4K avail=0 max_avail=0 Block: [01036000,01037000) size=4K avail=0 max_avail=0 Block: [01037000,01038000) size=4K avail=0 max_avail=0 Block: [01038000,01039000) size=4K avail=0 max_avail=0 Block: [01039000,0103a000) size=4K avail=0 max_avail=0 Block: [0103a000,0103b000) size=4K avail=0 max_avail=0 Block: [0103b000,0103c000) size=4K avail=0 max_avail=0 Block: [0103c000,0103d000) size=4K avail=0 max_avail=0 Block: [0103d000,0103e000) size=4K avail=0 max_avail=0 Block: [0103e000,0103f000) size=4K avail=0 max_avail=0 Block: [0103f000,01040000) size=4K avail=0 max_avail=0 Block: [01040000,01041000) size=4K avail=0 max_avail=0 Block: [01041000,01042000) size=4K avail=0 max_avail=0 Block: [01042000,01043000) size=4K avail=0 max_avail=0 Block: [01043000,01044000) size=4K avail=0 max_avail=0 Block: [01044000,01045000) size=4K avail=0 max_avail=400M Block: [01045000,01046000) size=4K avail=0 max_avail=0 Block: [01046000,01047000) size=4K avail=0 max_avail=0 Block: [01047000,01048000) size=4K avail=0 max_avail=0 Block: [01048000,01049000) size=4K avail=0 max_avail=0 Block: [01049000,0104a000) size=4K avail=0 max_avail=0 Block: [0104a000,0104b000) size=4K avail=0 max_avail=0 Block: [0104b000,0104c000) size=4K avail=0 max_avail=0 Block: [0104c000,0104d000) size=4K avail=0 max_avail=0 Block: [0104d000,0104e000) size=4K avail=0 max_avail=0 Block: [0104e000,0104f000) size=4K avail=0 max_avail=0 Block: [0104f000,01050000) size=4K avail=0 max_avail=0 Block: [01050000,01051000) size=4K avail=0 max_avail=400M Block: [01051000,01052000) size=4K avail=0 max_avail=0 Block: [01052000,01053000) size=4K avail=0 max_avail=3756K Block: [01053000,01054000) size=4K avail=0 max_avail=0 Block: [01054000,01055000) size=4K avail=0 max_avail=3756K Block: [01055000,01400000) size=3756K avail=3756K max_avail=3756K Block: [01800000,01801000) size=4K avail=0 max_avail=400M Block: [01801000,02000000) size=8188K avail=8188K max_avail=8188K Block: [03000000,1c000000) size=400M avail=400M max_avail=400M Block: [1e000000,1ebe0000) size=12160K avail=12160K max_avail=12160K => mem_size=444485632 (423 MB) / mem_avail=444112896 (423 MB) :unused_phys_alloc:Allocator 0x28063b8 dump: Block: [00100000,00200000) size=1M avail=1M max_avail=1M Block: [0020d000,01008000) size=14316K avail=14316K max_avail=14316K Block: [01400000,01800000) size=4M avail=4M max_avail=4M Block: [02000000,03000000) size=16M avail=16M max_avail=32M Block: [1c000000,1e000000) size=32M avail=32M max_avail=32M Block: [1ebe0000,1f000000) size=4224K avail=4224K max_avail=32M Block: [fec00000,fec01000) size=4K avail=4K max_avail=4K Block: [fee00000,fee01000) size=4K avail=4K max_avail=64K Block: [ffff0000,ffffffff] size=64K avail=64K max_avail=64K => mem_size=74633216 (71 MB) / mem_avail=74633216 (71 MB) :unused_virt_alloc:Allocator 0x2807424 dump: Block: [00002000,02000000) size=32760K avail=32760K max_avail=32760K Block: [02d8a000,04d8a000) size=32M avail=0 max_avail=0 Block: [04d8a000,40000000) size=969176K avail=969176K max_avail=1792M Block: [50000000,c0000000) size=1792M avail=1792M max_avail=1792M => mem_size=2938585088 (2802 MB) / mem_avail=2905030656 (2770 MB) :virt_alloc: Allocator 0x2801e64 dump: Block: [0283e000,0283f000) size=4K avail=0 max_avail=0 Block: [0283f000,02840000) size=4K avail=0 max_avail=0 Block: [02840000,02841000) size=4K avail=0 max_avail=32M Block: [02841000,02842000) size=4K avail=0 max_avail=0 Block: [02842000,02d87000) size=5396K avail=5396K max_avail=32M Block: [02d8a000,04d8a000) size=32M avail=32M max_avail=32M => mem_size=39096320 (37 MB) / mem_avail=39079936 (37 MB) :io_mem_alloc: Allocator 0x2802edc dump: Block: [00000000,00100000) size=1M avail=1M max_avail=1M Block: [1f000000,fec00000) size=3580M avail=3580M max_avail=3580M Block: [fec01000,fee00000) size=2044K avail=2044K max_avail=18364K Block: [fee01000,ffff0000) size=18364K avail=18364K max_avail=18364K => mem_size=3775848448 (3600 MB) / mem_avail=3775848448 (3600 MB) boot module 'acpi_drv' (96740 bytes) boot module 'fb_drv' (305596 bytes) boot module 'status_bar' (114120 bytes) boot module 'init' (254488 bytes) boot module 'platform_drv' (289772 bytes) boot module 'ps2_drv' (110324 bytes) boot module 'testnit' (84060 bytes) boot module 'config' (6549 bytes) boot module 'launchpad.config' (594 bytes) boot module 'ld.lib.so' (702684 bytes) boot module 'rom_filter' (86348 bytes) boot module 'timer' (89704 bytes) boot module 'xray_trigger' (112640 bytes) boot module 'pointer' (71144 bytes) boot module 'report_rom' (101328 bytes) boot module 'nitpicker' (265900 bytes) boot module 'scout' (1703896 bytes) boot module 'liquid_fb' (248988 bytes) boot module 'launchpad' (740624 bytes) boot module 'nitlog' (124736 bytes) Warning: need physical memory, but Platform object not constructed yet Warning: need physical memory, but Platform object not constructed yet Genode 17.08 423 MiB RAM and 261142 caps assigned to init Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x1 Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x2 Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x4 Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x8 Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x10 [init] child "nitpicker_config" announces service "ROM" [init] child "acpi_report_rom" announces service "Report" [init] child "report_rom" announces service "Report" [init] child "acpi_report_rom" announces service "ROM" [init] child "report_rom" announces service "ROM" [init] child "timer" announces service "Timer" Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x20 [init -> nitpicker_config] Warning: top-level node <xray> missing in input ROM xray [init -> nitpicker_config] Warning: could not obtain input value for input xray_enabled [init -> acpi_drv] Found MADT [init -> acpi_drv] MADT IRQ 0 -> GSI 2 flags: 0 [init -> acpi_drv] MADT IRQ 9 -> GSI 9 flags: 13 [init -> acpi_drv] Found MCFG [init -> acpi_drv] MCFG BASE 0xe0000000 seg 0x0 bus 0x0-0xff Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x40 Warning: unmapping of managed dataspaces not yet supported Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x80 [init] child "platform_drv" announces service "Platform" [init -> fb_drv] Found PCI VGA at 00:02.0 [init -> fb_drv] fb mapped to 0x2000 [init] child "fb_drv" announces service "Framebuffer" [init -> fb_drv] Warning: VBE Bios not present [init -> fb_drv] Warning: Could not set vesa mode 0x0@...64... [init -> ps2_drv] Error: no data available [init -> nitpicker] Error: Framebuffer-session creation failed (ram_quota=8192, cap_quota=3) [init -> nitpicker] Error: __cxa_guard_abort called Kernel: Thread 'ep' died because of an uncaught exception [init -> nitpicker] Error: Uncaught exception of type 'Genode::Service_denied' [init -> nitpicker] Warning: abort called - thread: ep [init] child "nitpicker" exited with exit value 1 [init -> ps2_drv] Error: no data available [init -> ps2_drv] i8042: self test failed (0x23) [init -> ps2_drv] Error: failed to read from port [init -> ps2_drv] Warning: scan code setting not supported [init -> ps2_drv] Using keyboard with scan code set 1 [init -> ps2_drv] Error: failed to read from port [init -> ps2_drv] Warning: could not reset mouse (missing ack) [init -> ps2_drv] Error: failed to read from port [init -> ps2_drv] Warning: could not reset mouse (unexpected response) [init -> ps2_drv] Error: failed to read from port [init -> ps2_drv] Error: failed to read from port [init -> ps2_drv] Warning: could not enable stream [init -> ps2_drv] Error: failed to read from port [init -> ps2_drv] Error: failed to read from port [init -> ps2_drv] Error: failed to read from port [init -> platform_drv] PS2 uses IRQ, vector 0x1 [init -> platform_drv] PS2 uses IRQ, vector 0xc [init] child "ps2_drv" announces service "Input"

2 1

ahci_drv default writeable?
by Steven Harp 27 Sep '17

27 Sep '17

Noticed that in 17.08 (and 17.05) these examples failed w. x86/nova - run/libc_vfs_fs_fat - run/libc_vfs_fat apparently because: [init -> ahci_drv] read-only session opened at device 0 for 'test-libc_vfs -> 0' so e.g., mkdir fails with EPERM. Hacking libports/run/libc_vfs_filesystem_test.inc to add writeable="yes" to the "ahci_drv" component configuration: <config> <policy label_prefix="test-libc_vfs" device="0" writeable="yes"/> <policy label_prefix="vfs" device="0" writeable="yes" /> </config> suffices, but maybe this is not appropriate. Was the default policy intended to be writeable="yes" for this driver? // Steve Harp

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users