Ah, now I got it I think. You need to allow L4Linux to access those ports, i.e. add 'ioport [ 0x0cf8, 0x0cff ]' to the loader config script to allow access to the PCI ports. That should fix it. For other devices this works equally.
I've added command ioport to l4linux26.cfg: sleep 1 task "vmlinuz-2.6.24-l4" "earlyprintk=yes mem=128M root=LABEL=/ l4env_rd=initrd-2.6.24-l4.img" ioport [ 0x0cf8, 0x0cff ] all_sects_writable allow_vga allow_cli
but it still comes to old behaviour, with the same failure: l4lx | L4RM: [PF] read at 0xf0cfb000, ip 0069730c, src F.02 l4lx | [F.0] l4rm/lib/src/pagefault.c:81:__unknown_pf(): l4lx | unhandled page fault
I've built L4Env and L4Linux in Debian system (runned for a long time) under VMware. In this case everything was going allmost fine. Comparing the logs:
Physical machine: =================
l4lx | Using tamed mode. ROOT: Task #0d is not allowed to execute cli/sti loader | vmlinuz-2.6.24-l4,#f: WARNING: Can't map I/O space, ROOT denies page loader : (result=00004000) loader | vmlinuz-2.6.24-l4,#f: Not allowed to perform any I/O l4lx | Got 0 out of 65536 I/O ports l4lx | Connecting to l4io server. l4lx | l4env_linux_startup thread 4. l4lx | l4lx_thread_create: Created thread 0f.04 (cpu0) l4lx | main thread will be 0f.04
VMware: ======= l4lx | Using tamed mode. l4lx | Connecting to l4io server. l4lx | l4env_linux_startup thread 4. l4lx | l4lx_thread_create: Created thread 0c.04 (cpu0) l4lx | main thread will be 0c.04
i.e. in the first case its seen that l4linux isn't allowed by loader to map I/O space. Could it be like the symptom of such L4Linux behaviour in the first case? I even made identical (except con- and rtc-server presented in GRUB's menu.lst on physical machine) configs - l4linux26.cfg and L4Linux loading section in menu.lst.