Hi all,
I'm trying to run some more elaborate demos on with Linux as the base system. My host is a Debian Stretch (x86_64), I'm on master which I checked out this morning (5cf8c49c).
When trying to run 'noux_vim', a completely black SDL window (no text or anything) shows up. The following is output on the command line:
$ make run/noux_vim [...] genode build completed spawn ./core Genode 15.08-25-g5cf8c49 int main(): --- create local services --- int main(): --- start init --- int main(): transferred 17592186044415 MB to init int main(): --- init created, waiting for exit condition --- [init] parent provides [init] service "ROM" [init] service "LOG" [init] service "CAP" [init] service "RAM" [init] service "RM" [init] service "CPU" [init] service "PD" [init] service "IRQ" [init] service "IO_PORT" [init] service "IO_MEM" [init] service "SIGNAL" [init] child "timer" [init] RAM quota: 876544 [init] ELF binary: timer [init] priority: 0 [init] provides service Timer [init] child "fb_sdl" [init] RAM quota: 4022272 [init] ELF binary: fb_sdl [init] priority: 0 [init] provides service Input [init] provides service Framebuffer [init] child "terminal" [init] RAM quota: 1925120 [init] ELF binary: terminal [init] priority: 0 [init] provides service Terminal Quota exceeded! amount=24576, size=4096, consumed=24576 [init] upgrading quota donation for Env::CPU (8192 bytes) [init] child "noux" [init] RAM quota: 1073569792 [init] ELF binary: noux [init] priority: 0 [init] child "timer" announces service "Timer" [init -> terminal] int main(int, char**): --- terminal service started --- [init -> fb_sdl] Could not open ROM session for module "config" [init -> fb_sdl] Could not obtain config file [init -> fb_sdl] creating virtual framebuffer for mode 1024x768@...64... [init] child "fb_sdl" announces service "Framebuffer" [init] child "fb_sdl" announces service "Input" [init -> terminal] cell size is 8x16 [init] child "terminal" announces service "Terminal"
I'm not sure whether the config file error in fb_sdl is critical in this context - it looks like it's offering a framebuffer. I guess I should be seeing vim being started somewhere, though...
Thanks for your help.
Cheers, Alex
Hi Alex,
On 17.09.2015 10:41, Alexander Senier wrote:
I'm trying to run some more elaborate demos on with Linux as the base system. My host is a Debian Stretch (x86_64), I'm on master which I checked out this morning (5cf8c49c).
When trying to run 'noux_vim', a completely black SDL window (no text or anything) shows up. The following is output on the command line:
$ make run/noux_vim
unfortunately, all but the simplest noux scenarios don't work on Linux. Ironically, 'fork' is not implemented on this base platform. On regular L4-like microkernels, it is possible to remotely manipulate address spaces. So the noux runtime is able to copy the address space of the forking noux process to another one. The Linux kernel does not allow us to do that (well, at least when not using ptrace or a similar hook).
Consequently, implementing fork on Linux calls for a different implementation where the noux process itself plays a more active role (i.e., issuing the Linux clone syscall directly, copying the locally implemented region-manager structures). It is actually quite tricky. So far, I found that the hassle wasn't worth the effort.
The plain noux.run script does work because is solely executes 'ls', which does not rely on fork. In contrast, the noux_vim.run scenario requires fork because Vim temporarily spawns a shell at startup.
Do you deem noux as critical in your Linux-based scenario? If yes, we should investigate to best way how to go forward.
Cheers Norman
Hello,
I just tried the 'noux_vim' run script on Xubuntu 14.04 and it worked for me.
This is the log output I'm seeing:
spawn ./core Genode 15.08-34-g8c7e052 int main(): --- create local services --- int main(): --- start init --- int main(): transferred 17592186044415 MB to init int main(): --- init created, waiting for exit condition --- [init] parent provides [init] service "ROM" [init] service "LOG" [init] service "CAP" [init] service "RAM" [init] service "RM" [init] service "CPU" [init] service "PD" [init] service "IRQ" [init] service "IO_PORT" [init] service "IO_MEM" [init] service "SIGNAL" [init] child "timer" [init] RAM quota: 876544 [init] ELF binary: timer [init] priority: 0 [init] provides service Timer [init] child "fb_sdl" [init] RAM quota: 4022272 [init] ELF binary: fb_sdl [init] priority: 0 [init] provides service Input [init] provides service Framebuffer [init] child "terminal" [init] RAM quota: 1925120 [init] ELF binary: terminal [init] priority: 0 [init] provides service Terminal Quota exceeded! amount=24576, size=4096, consumed=24576 [init] upgrading quota donation for Env::CPU (8192 bytes) [init] child "noux" [init] RAM quota: 1073569792 [init] ELF binary: noux [init] priority: 0 [init -> fb_sdl] Could not open ROM session for module "config" [init -> fb_sdl] Could not obtain config file [init -> terminal] int main(int, char**): --- terminal service started --- [init] child "timer" announces service "Timer" [init -> noux] --- noux started --- [init -> noux] tar archive 'vim.tar' local at 2ac00a020000, size is 19998720 [init -> fb_sdl] creating virtual framebuffer for mode 1024x768@...64... [init] child "fb_sdl" announces service "Framebuffer" [init] child "fb_sdl" announces service "Input" [init -> terminal] cell size is 8x16 [init] child "terminal" announces service "Terminal" [init -> terminal] create terminal session [init -> terminal] new terminal session: [init -> terminal] framebuffer has 1024x768 pixels [init -> terminal] character size is 8x16 pixels [init -> terminal] terminal size is 128x48 characters [init -> noux] invalid opcode 21 [init -> noux -> /bin/vim] int getrlimit(int, rlimit*): not implemented 2 [init -> noux -> /bin/vim] unsupported ioctl (request=0x802c7414)
Christian
On 09/17/2015 11:27 AM, Norman Feske wrote:
Hi Alex,
On 17.09.2015 10:41, Alexander Senier wrote:
I'm trying to run some more elaborate demos on with Linux as the base system. My host is a Debian Stretch (x86_64), I'm on master which I checked out this morning (5cf8c49c).
When trying to run 'noux_vim', a completely black SDL window (no text or anything) shows up. The following is output on the command line:
$ make run/noux_vim
unfortunately, all but the simplest noux scenarios don't work on Linux. Ironically, 'fork' is not implemented on this base platform. On regular L4-like microkernels, it is possible to remotely manipulate address spaces. So the noux runtime is able to copy the address space of the forking noux process to another one. The Linux kernel does not allow us to do that (well, at least when not using ptrace or a similar hook).
Consequently, implementing fork on Linux calls for a different implementation where the noux process itself plays a more active role (i.e., issuing the Linux clone syscall directly, copying the locally implemented region-manager structures). It is actually quite tricky. So far, I found that the hassle wasn't worth the effort.
The plain noux.run script does work because is solely executes 'ls', which does not rely on fork. In contrast, the noux_vim.run scenario requires fork because Vim temporarily spawns a shell at startup.
Do you deem noux as critical in your Linux-based scenario? If yes, we should investigate to best way how to go forward.
Cheers Norman
On Thu, Sep 17, 2015 at 11:27:45AM +0200, Norman Feske wrote:
Hi Alex,
On 17.09.2015 10:41, Alexander Senier wrote:
I'm trying to run some more elaborate demos on with Linux as the base system. My host is a Debian Stretch (x86_64), I'm on master which I checked out this morning (5cf8c49c).
When trying to run 'noux_vim', a completely black SDL window (no text or anything) shows up. The following is output on the command line:
$ make run/noux_vim
unfortunately, all but the simplest noux scenarios don't work on Linux. Ironically, 'fork' is not implemented on this base platform. On regular L4-like microkernels, it is possible to remotely manipulate address spaces. So the noux runtime is able to copy the address space of the forking noux process to another one. The Linux kernel does not allow us to do that (well, at least when not using ptrace or a similar hook).
Consequently, implementing fork on Linux calls for a different implementation where the noux process itself plays a more active role (i.e., issuing the Linux clone syscall directly, copying the locally implemented region-manager structures). It is actually quite tricky. So far, I found that the hassle wasn't worth the effort.
The plain noux.run script does work because is solely executes 'ls', which does not rely on fork. In contrast, the noux_vim.run scenario requires fork because Vim temporarily spawns a shell at startup.
Do you deem noux as critical in your Linux-based scenario? If yes, we should investigate to best way how to go forward.
Cheers Norman
Sorry to jump in, but running noux_vim in qemu with base.foc32 as the platform also gives a black screen. Could this be related?
Hi Christian,
I just tried the 'noux_vim' run script on Xubuntu 14.04 and it worked for me.
thanks. So apparently, Vim does not rely on fork. I stand corrected. ;-)
But now that my nice explanation became moot, I start to wonder what's going wrong in Alex' case.
Cheers Norman
I believe your issue is caused by some improper service routing: https://github.com/genodelabs/genode/blob/master/repos/ports/run/noux_vim.ru...
The default routing scheme should be attempt to route to the parent, and then fall back to any-child. This was caused when the new canned platform driver configuration was introduced but some of the interactive scenarios were not updated to account for the new service routes.
As for the fb_sdl error, the driver is trying to get some resolution configuration, catches an error, and then falls back to a default, so nothing to worry about.
Cheers, Emery
On Thu, Sep 17, 2015 at 10:41:25AM +0200, Alexander Senier wrote:
Hi all,
I'm trying to run some more elaborate demos on with Linux as the base system. My host is a Debian Stretch (x86_64), I'm on master which I checked out this morning (5cf8c49c).
When trying to run 'noux_vim', a completely black SDL window (no text or anything) shows up. The following is output on the command line:
$ make run/noux_vim [...]
I'm not sure whether the config file error in fb_sdl is critical in this context - it looks like it's offering a framebuffer. I guess I should be seeing vim being started somewhere, though...
Thanks for your help.
Cheers, Alex
On Thu, Sep 17, 2015 at 11:41:54AM +0200, Norman Feske wrote:
Hi Christian,
I just tried the 'noux_vim' run script on Xubuntu 14.04 and it worked for me.
thanks. So apparently, Vim does not rely on fork. I stand corrected. ;-)
But now that my nice explanation became moot, I start to wonder what's going wrong in Alex' case.
Cheers Norman
I mis-replied to someone (sorry!) but I'm also having this problem with base.foc32 running in qemu.
Hello Jookia,
On Thu, Sep 17, 2015 at 08:19:55PM +1000, Jookia wrote:
I mis-replied to someone (sorry!) but I'm also having this problem with base.foc32 running in qemu.
Please see the posting by Emery. The proposed change will fix your issue. Just change
<any-service> <any-child/> <parent/> </any-service>
to
<any-service> <parent/> <any-child/> </any-service>
in noux_vim.run.
Regards
Hello Emery,
On Thu, Sep 17, 2015 at 11:44:40AM +0200, emery@...261... wrote:
I believe your issue is caused by some improper service routing:
[...]
Your solution renders base-foc working again but seems to not apply for the original issue with base-linux. The current master branch works for Christian Prochaska (and also for me on Ubuntu 12.04) but not on Debian Stretch. So, I fear it's not that simple ;-)
Regards
On Thu, Sep 17, 2015 at 12:34:37PM +0200, Christian Helmuth wrote:
Hello Emery,
On Thu, Sep 17, 2015 at 11:44:40AM +0200, emery@...261... wrote:
I believe your issue is caused by some improper service routing:
[...]
Your solution renders base-foc working again but seems to not apply for the original issue with base-linux. The current master branch works for Christian Prochaska (and also for me on Ubuntu 12.04) but not on Debian Stretch. So, I fear it's not that simple ;-)
Ok, as for the routing thing I think its noux sending ROM to the report_rom server.
Emery
I can confirm that that routing changes do NOT solve the problem on Debian, I does however solve it on Nova/x86_32. I can live with that as an experimentation platform, but maybe the Linux issue is worth investigating. If you need me to try anything out, don't hesitate to get in touch with me.
Cheers, Alex
On 09/17/2015 12:34 PM, Christian Helmuth wrote:
Your solution renders base-foc working again but seems to not apply for the original issue with base-linux. The current master branch works for Christian Prochaska (and also for me on Ubuntu 12.04) but not on Debian Stretch. So, I fear it's not that simple ;-)
-
unknown＠example.com -
Alexander Senier -
Christian Helmuth -
Christian Prochaska -
Jookia -
Norman Feske