Just giving a small glitch while trying run/demo on Nova (x86_64).
First I am using a 2 day old master.zip file of Genode (because I had github not able finishing getting objects in 56k with git clone). However I have a new git clone of Nova that did work fine.
Note 1: Genode seems to get latest version of Nova by a simple git clone without mentioning the revision that it seems to be done for: genode-master/base-nova/Makefile: GIT_URL = git://github.com/IntelLabs/NOVA.git GIT_REV = 16dd65c15dac298dc5b36d636d79fa0110bd5736 ... $(CONTRIB_DIR)/.git: $(VERBOSE)git clone $(GIT_URL) $(CONTRIB_DIR) which seems to ignore GIT_REV
First, I tried to make run/hello without the make prepare in base-nova, but I did after, and it finished building, so I did not rebuild.
First time I run/demo I hit a problem when clicking on liquid_framebuffer, that do not seems to repeat the next time: [init -> timer] Timer::Timeout_scheduler::Timeout_scheduler(Platform_timer*, Genode::Rpc_entrypoint*): starting timeout scheduler [init -> vesa_drv] int Framebuffer_drv::map_io_mem(Genode::addr_t, Genode::size_t, bool, void**, Genode::addr_t, Genode::Dataspace_capability*): fb mapped to 1000 [init -> vesa_drv] Could not open file "config" [init -> vesa_drv] Could not obtain config file [init -> vesa_drv] Found: VESA BIOS version 2.0 [init -> vesa_drv] OEM: VGABIOS Cirrus extension [init -> vesa_drv] Found: physical frame buffer at 0xfc000000 size: 0x00400000 [init -> vesa_drv] int Framebuffer_drv::map_io_mem(Genode::addr_t, Genode::size_t, bool, void**, Genode::addr_t, Genode::Dataspace_capability*): fb mapped to 400000 [init -> nitpicker] framebuffer is 1024x768@...23... [init -> nitpicker] create session with args: fb_format=1, label="launchpad", ram_quota=1646592 [init -> nitpicker] Could not open file "config" [init -> nitpicker] Could not obtain config file [init -> nitpicker] create session with args: fb_width=400, fb_height=1504, fb_format=1, label="launchpad", ram_quota=1211392 [init -> launchpad] --- entering main loop --- [init -> launchpad] starting liquid_fb with quota 7340032 [init -> launchpad] using unique child name "liquid_fb" [init -> launchpad -> liquid_fb] Could not open file "config" [init -> launchpad -> liquid_fb] Could not obtain config file [init -> nitpicker] create session with args: fb_format=1, label="launchpad -> liquid_fb", ram_quota=1646592 [init -> nitpicker] create session with args: fb_width=510, fb_height=880, fb_format=1, label="launchpad -> liquid_fb", ram_quota=905792 [init -> launchpad] liquid_fb registered service Framebuffer [init -> launchpad] liquid_fb registered service Input virtual void Genode::Signal_session_component::submit(Genode::Signal_context_capability, unsigned int): invalid signal-context capability unresolvable page-fault at address 0xa00fdfc0, ip=0x1010128 [ 0] Killed EC:0xffffffff810a02e0 SC:0xffffffff823ccba0 V:0xe CS:0x2b EIP:0x1010128 CR2:0xa00fdfc0 ERR:0x6 (PT not found)
Although id does run (moving background), the cursor stop. But I was able to get back control from Qemu with Ctrl-Alt.
The next time I did run/demo, the liquid_fb worked (cursor and all works), but there is an error: See the line with [init -> launchpad -> liquid_fb] tried to call an invalid object: [init -> launchpad] Could not open file "ld.lib.so" [init -> ps2_drv] Using keyboard with scan code set 1 (xlate). [init -> launchpad] Could not open file "config" [init -> launchpad] Could not obtain config file [init -> timer] Timer::Timeout_scheduler::Timeout_scheduler(Platform_timer*, Genode::Rpc_entrypoint*): starting timeout scheduler [init -> vesa_drv] int Framebuffer_drv::map_io_mem(Genode::addr_t, Genode::size_t, bool, void**, Genode::addr_t, Genode::Dataspace_capability*): fb mapped to 1000 [init -> vesa_drv] Could not open file "config" [init -> vesa_drv] Could not obtain config file [init -> vesa_drv] Found: VESA BIOS version 2.0 [init -> vesa_drv] OEM: VGABIOS Cirrus extension [init -> vesa_drv] Found: physical frame buffer at 0xfc000000 size: 0x00400000 [init -> vesa_drv] int Framebuffer_drv::map_io_mem(Genode::addr_t, Genode::size_t, bool, void**, Genode::addr_t, Genode::Dataspace_capability*): fb mapped to 400000 [init -> nitpicker] framebuffer is 1024x768@...23... [init -> nitpicker] create session with args: fb_format=1, label="launchpad", ram_quota=1646592 [init -> nitpicker] Could not open file "config" [init -> nitpicker] Could not obtain config file [init -> nitpicker] create session with args: fb_width=400, fb_height=1504, fb_format=1, label="launchpad", ram_quota=1211392 [init -> launchpad] --- entering main loop --- [init -> launchpad] starting liquid_fb with quota 7340032 [init -> launchpad] using unique child name "liquid_fb" [init -> launchpad -> liquid_fb] Could not open file "config" [init -> launchpad -> liquid_fb] Could not obtain config file [init -> nitpicker] create session with args: fb_format=1, label="launchpad -> liquid_fb", ram_quota=1646592 [init -> nitpicker] create session with args: fb_width=510, fb_height=880, fb_format=1, label="launchpad -> liquid_fb", ram_quota=905792 [init -> launchpad] liquid_fb registered service Framebuffer [init -> launchpad] liquid_fb registered service Input [init -> launchpad -> liquid_fb] tried to call an invalid object [init -> launchpad -> liquid_fb] C++ runtime: Genode::Ipc_error [init -> launchpad -> liquid_fb] void* abort(): abort called unmapping of managed dataspaces not yet supported [init -> launchpad] starting liquid_fb with quota 7340032 [init -> launchpad] using unique child name "liquid_fb" [init -> launchpad -> liquid_fb] Could not open file "config" [init -> launchpad -> liquid_fb] Could not obtain config file [init -> nitpicker] create session with args: fb_format=1, label="launchpad -> liquid_fb", ram_quota=1646592 [init -> nitpicker] create session with args: fb_width=510, fb_height=880, fb_format=1, label="launchpad -> liquid_fb", ram_quota=905792 [init -> launchpad] liquid_fb registered service Framebuffer [init -> launchpad] liquid_fb registered service Input qemu: terminating on signal 2
I intend to test the iso on my machine on a CD or DVD.
Ok, so I burn my var/run/demo.iso file from my build directory (8 MB, impressively small!) to a CD and tried it.
My big surprise when I ran it on my computer was to hear the 56k modem call a number. I heard the operator voice, so that I know it did not join it's destination fine. I first tought that the log output was going to COM1 serial port, and that somehow it had to have some "ATDT some-number in it" which now seems unbelievable to be just a coincidence.
I guess either Nova or Genode is setup to make a phone call. Anyway...
I was happy to see that the disk was working fine on my computer. I was not sure it would work, my CPU not having virtualization support as far as I know: paul@...162...:~/Bureau/genode-master/build.nova$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Celeron(R) CPU 2.66GHz stepping : 9 microcode : 0x3 cpu MHz : 2666.790 cache size : 256 KB fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc up pebs bts nopl pni dtes64 monitor ds_cpl tm2 cid cx16 xtpr lahf_lm bogomips : 5333.58 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: paul@...162...:~/Bureau/genode-master/build.nova$
I've seen that the "tried to call an invalid object:" problem does not happen always with liquid_fb. This message aso happen with nitpick (which does not seems to show anything). The invalid signal-context capability error did not come back.
I tried the CD in my Pentium-4 computer. It was rebooting in loop as soon as Grub did finish loading each modules. I guess I was expecting it more or less. I think Genode 64 bits was build for Nova, and the Pentium 4 does not support 64 bits.
It's fun to see such a small CD image doing so much!
Note 1: Genode seems to get latest version of Nova by a simple git clone without mentioning the revision that it seems to be done for: genode-master/base-nova/Makefile: GIT_URL = git://github.com/IntelLabs/NOVA.git GIT_REV = 16dd65c15dac298dc5b36d636d79fa0110bd5736 ... $(CONTRIB_DIR)/.git: $(VERBOSE)git clone $(GIT_URL) $(CONTRIB_DIR) which seems to ignore GIT_REV
You are missing the next block in that file: In this line ( https://github.com/genodelabs/genode/blob/master/base-nova/Makefile#L43) and two lines after the clone is reset to the revision specified in GIT_REV and then the custom patches are applied.
and two lines after the clone is reset to the revision specified in GIT_REV and then the custom patches are applied
Ah, yes, indeed. Thanks! It's the first time I see this reset command. I was expecting to clone a specific version, rather than resetting.
And the fact that the patches when applied, had a message kind of "succedded on the next line" (sorry not the exact message) made me suspect it was applied to a different version.
Nova 64 bits rebooting in loop on my older Pentium 4 computer was not a surprised. This morning I tested Nova 32 bits. Nova 32 bits seems to work well on my Celeron D computer, but not on my older (about 2002) IBM Netvista computer where I get when trying to boot the demo.iso CD: Nova Microhypervisor v5-16dd65c (x86_32): Jan 21 2013... (gcc 4.7.2)
[ 0] CORE:0:0:0 f:2:4:2 [f] Intel(R) Pentium(R) 4 CPU 2.26 GHz
And it hang there.
It's still a bit unclear if the message come really from the Genode Core but I guess so. Guess I should get my serial null-modem out of a dusted box here.
Hello Paul,
On 01/21/2013 05:44 PM, Paul Dufresne wrote:
Nova 64 bits rebooting in loop on my older Pentium 4 computer was not a surprised. This morning I tested Nova 32 bits. Nova 32 bits seems to work well on my Celeron D computer, but not on my older (about 2002) IBM Netvista computer where I get when trying to boot the demo.iso CD: Nova Microhypervisor v5-16dd65c (x86_32): Jan 21 2013... (gcc 4.7.2)
[ 0] CORE:0:0:0 f:2:4:2 [f] Intel(R) Pentium(R) 4 CPU 2.26 GHz
And it hang there.
It's still a bit unclear if the message come really from the Genode Core but I guess so. Guess I should get my serial null-modem out of a dusted box here.
the NOVA kernel uses some hardware features (ACPI, APIC), which are not available/not enabled/not properly implemented on some older computers. We got the same symptom you are describing on an IBM T42 (Pentium M) notebook just recently. Then we tried it on an IBM T60 (Core Solo) notebook, where it worked well.
Christian
On Mon, 21 Jan 2013 11:44:05 -0500 Paul Dufresne (PD) wrote:
PD> Nova 64 bits rebooting in loop on my older Pentium 4 computer was not PD> a surprised.
Probably because your P4 does not support x86_64?
PD> Nova 32 bits seems to work well on my Celeron D computer, but not on PD> my older (about 2002) IBM Netvista computer where I get when trying to PD> boot the demo.iso CD: PD> Nova Microhypervisor v5-16dd65c (x86_32): Jan 21 2013... (gcc 4.7.2) PD> PD> [ 0] CORE:0:0:0 f:2:4:2 [f] Intel(R) Pentium(R) 4 CPU 2.26 GHz PD> PD> And it hang there.
NOVA expects the machine to have at least one IOAPIC. We removed support for the 8259 legacy PIC in NOVA-0.2. If the machine does have an IOAPIC, it also needs to provide the ACPI MADT, so OS software can enumerate the IOAPIC.
There is little use in supporting hardware as old as your P4. It would not support multiple processors or virtualization anyway.
As a rule of thumb, NOVA should work on any multi-core x86 CPU.
Cheers, Udo
Hi Paul,
thanks for your feedback about running Genode with the park of your machines. :-)
For accommodating older machines, you may give one of the other kernels a try, i.e., OKL4.
Regarding NOVA, some of the stability glitches that you observed may stem from the fact that dynamic system scenarios (scenarios where programs are repeatedly started and stopped) are not yet fully supported for base-nova. In fact, the official kernel version is not complete in this respect. For this reason, there is currently rapid progress to enable such work load. This involves us to complement the kernel with prior missing functionality, adding support for destroying kernel objects. So this issue is actively being worked on. If you are interested in this line of work, please follow the branches created by Alexander (https://github.com/alex-ab) at GitHub.
The messages "tried to call an invalid object:..." are not always a reason to get worried. There are situations where they are actually expected. For example, let us assume there is a program that enters a main loop like this:
... static Timer::Connection timer; for (;;) { ... timer.msleep(20); }
The program will periodically wake up every 20ms, do some work, and sleep again by doing an RPC call to the timer service. Now, when the parent decides to kill the program (e.g., the user presses the X-button on launchpad), the parent will close all the program's sessions in reverse order as they had been created. So it will close the timer session before closing the other basic sessions like CPU, RM, and PD. After the parent closed the timer session, the main thread is still running and may attempt just another call of 'timer.msleep(20)'. Because the timer session does not exist anymore, you will see the message about the attempt to call an invalid object.
Best regards Norman
-
Christian Prochaska -
Markus Partheymueller -
Norman Feske -
Paul Dufresne -
Udo Steinberg