- l4-hackers - example.com Site

the ipcmon compiling error
by Guanghui, Cheng 21 Apr '10

21 Apr '10

Hello: there is an error when compiling the ipcmon with ubuntu 9.10 with default gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1 as following: LD_PRELOAD=/home/cheng/work/L4_DEMO/tudos/build/tool/gendep/libgendep.so GENDEP_TARGET=ipcmon-server.o GENDEP_BINARY=cc1 gcc -m32 -c -DLOG_TAG=\"ipcmon\" -DUSE_UCLIBC=y -DRAM_BASE=0x0 -DSYSTEM_x86_586_l4v2 -DARCH_x86 -DCPUTYPE_586 -DL4API_l4v2 -DCONFIG_L4_CALL_SYSCALLS -DCONFIG_L4_ABS_SYSCALLS -I/home/cheng/work/L4_DEMO/tudos/build/pkg/ipcmon/idl/OBJ-x86-l4v2 -I/home/cheng/work/L4_DEMO/tudos/build/include/x86/l4v2 -I/home/cheng/work/L4_DEMO/tudos/build/include/l4v2 -I/home/cheng/work/L4_DEMO/tudos/build/include/x86 -I/home/cheng/work/L4_DEMO/tudos/build/include -I/home/cheng/work/L4_DEMO/tudos/l4/../dice/include -I/home/cheng/work/L4_DEMO/tudos//include/x86/l4v2 -I/home/cheng/work/L4_DEMO/tudos//include/l4v2 -I/home/cheng/work/L4_DEMO/tudos//include/x86 -I/home/cheng/work/L4_DEMO/tudos//include -nostdinc -I/home/cheng/work/L4_DEMO/tudos/build/include/x86/uclibc -I/home/cheng/work/L4_DEMO/tudos/build/include/uclibc -I/home/cheng/work/L4_DEMO/tudos/build/include/uclibc++ -I/home/cheng/work/L4_DEMO/tudos//include/x86/uclibc -I/home/cheng/work/L4_DEMO/tudos//include/uclibc -I/home/cheng/work/L4_DEMO/tudos//include/uclibc++ -I/usr/lib/gcc/i486-linux-gnu/4.4.1/include -I/usr/lib/gcc/i486-linux-gnu/4.4.1/include-fixed -gstabs+ -g -O2 -fno-strict-aliasing -march=i586 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -fno-common -fno-stack-protector -g /home/cheng/work/L4_DEMO/tudos/build/pkg/ipcmon/idl/OBJ-x86-l4v2/ipcmon-server.c -o ipcmon-server.o ==> Linking ipcmon LD_PRELOAD=/home/cheng/work/L4_DEMO/tudos/build/tool/gendep/libgendep.so GENDEP_TARGET=ipcmon GENDEP_BINARY=ld GENDEP_BINARY_ALT1=ld ld -m elf_i386 -o ipcmon /home/cheng/work/L4_DEMO/tudos/build/lib/x86_586/crt0.o components.o capdescriptor.o capmanager.o blacklist.o whitelist.o ipcmon-server.o -Ttext=0x1000000 --hash-style=sysv -L/home/cheng/work/L4_DEMO/tudos/build/lib/x86_586/l4v2 -L/home/cheng/work/L4_DEMO/tudos/build/lib/x86_586 -L/home/cheng/work/L4_DEMO/tudos/build/lib -L/home/cheng/work/L4_DEMO/tudos//lib/x86_586/l4v2 -L/home/cheng/work/L4_DEMO/tudos//lib/x86_586 -L/home/cheng/work/L4_DEMO/tudos//lib -T/home/cheng/work/L4_DEMO/tudos/build/lib/x86_586/main_stat.ld -lparsecmdline -static -lgeneric_ts -ll4env -ll4rm -ldm_generic -ldm_mem -lthread -lsemaphore -llogserver_capsule -lnames -ll4util_root -ll4util -lsigma0 -lroot -ll4env -ll4env_err -ll4rm -ldm_generic -ldm_mem -lthread -lslab -ll4sys -luc_c++ -lc ++start.o /usr/lib/gcc/i486-linux-gnu/4.4.1/libsupc++.a -lmain -lcxx_base -nostdlib -luc_c -luclibc_support -u mmap_anon -lc_be_simple_mem -lc_be_mmap -lc_be_mmap_util -lc_be_l4env_start_stop -lc_be_minimal_log_io -luc_be_simple_sleep -ll4env -llogserver_capsule -ll4rm -ldm_generic -ldm_mem -lthread -lgeneric_ts -luc_c /usr/lib/gcc/i486-linux-gnu/4.4.1/libgcc_eh.a /usr/lib/gcc/i486-linux-gnu/4.4.1/libgcc.a -luc_c -ll4sys -ll4util -luc_be_minimal_io -Ttext=0x1000000 --warn-common -gc-sections /usr/lib/gcc/i486-linux-gnu/4.4.1/libsupc++.a(cp-demangle.o): In function `.L641': (.text+0x32e7): undefined reference to `__sprintf_chk' Thanks. Cheng Guanghui

2 1

About Periodic Tasks
by Jungwoo Yang 21 Apr '10

21 Apr '10

Hello, I'm a student who are studying periodic task on L4, so I'm trying to use your cpu_reserved example. However, what I tried to use res_rt_sched or periodic. I've gotten some errors. title Fiasco Periodic Test kernel /bootstrap -serial -modaddr=0x06000000 module /fiasco -serial_esc -comport 1 module /sigma0 module /roottask task modname "cpu_reserved" allow_cli task modname "res_rt_sched" allow_cli module /events module /names --events module /log module /dm_phys module /cpu_reserved module /res_rt_sched This is my configuration of grub. but I have gotten some error like that. res_rt_s| Error: l4_rt_next_period(): Unknown (unregistered) error res_rt_s| [A.3] cpu_reserve/examples/res_rt_sched/main.c:77:worker(): res_rt_s| Error: l4_rt_next_period(): Unknown (unregistered) error res_rt_s| [A.3] cpu_reserve/examples/res_rt_sched/main.c:77:worker(): When I tried to figure out the error. The problem is from "l4_rt_next_period()". It returns 0x20 error "L4_IPC_RETIMEOUT". I've found the error from "l4cpu_reserve_wait_periodic()" in cpu_reserved server. The function returns 0 if the IPC returns "L4_IPC_RETIMEOUT", so I thought that "L4_IPC_RETIMEOUT" is not real error at that time. But when I execute the compoent "res_rt_sched", it look like that it is not a periodic task. I've spent about 3 weeks because of this.. please help me! Thank you.

2 1

bug report and fixed in the dice compiling
by Guanghui, Cheng 19 Apr '10

19 Apr '10

Hello: In the ubuntu 9.10 with default bison version 2.4.1 the dice configure script failed to check the valid bison version: the old one: 20627 if test "(" "${1}" = "2" -a "(" "${2}" = "1a" -o "${2}" = "1b" -o "${2}" = "2" -o "${2}" = "3" ")" ")"; then 20628 dice_bison_version="${1}.${2} (ok)" 20629 else 20630 dice_bison_version=invalid 20631 fi this verification is only available for bison version 2.1a, 2.2 and 2.3. it will be invalid in the bison 2.4 and later. the new one: 20626 set `$YACC --version|grep 'GNU Bison'|cut -d ' ' -f 4|sed -e 's/\./ /'` 20627 if test "(" "${1}" = "2" -a "(" "${2}" = "1a" -o "${2}" = "1b" -o "${2}" = "2" -o "${2}" = "3" -o "${2}" = "4" -o "${2}" = "4.1" -o "${2}" = "4.2" ")" ")"; then 20628 dice_bison_version="${1}.${2} (ok)" 20629 else 20630 dice_bison_version=invalid That's all. Cheng Guanghui

3 2

Post Bison version fix error
by Harish G. Naik 18 Apr '10

18 Apr '10

So I was advised to download bison 2.3 and install it and use it instead of the system default 2.4.1. I did that and I now get a different, much shorter: c-scanner.ll: In function ‘yy::c_parser::token::yytokentype clex(yy::c_parser::semantic_type*, yy::location*, c_parser_driver&)’: c-scanner.ll:523: error: ‘strlen’ was not declared in this scope make[6]: *** [c-scanner.o] Error 1 make[5]: *** [all-recursive] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [../dice] Error 2 Can someone tell me what I might still be missing? -Harish

2 3

Re: pci_set_master in dde linux26
by Björn Döbel 07 Apr '10

07 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, > On 10-4-7 下午4:30, Björn Döbel wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, >> >>> We tried to run the e100 driver with the hurd porting of dde linux26, but got >>> one problem, i.e., pci_set_master() hasn't been implemented. In >>> linux26/lib/src/arch/l4/pci.c, >>> void pci_set_master(struct pci_dev *dev) >>> { >>> CHECK_INITVAR(dde26_pci); >>> WARN_UNIMPL; >>> } >>> >>> Were there any reasons that pci_set_master() was implemented? It seems >>> pci_set_master() only needs to read or write the PCI configuration space. >> >> obviously we didn't need this feature yet. Feel free to add it. > OK, I see. Does DDE Linux26 works with drivers using MMIO? I'm trying to make > DDE Linux26 with e1000 driver, which uses MMIO, but have no luck. Yes, works here. Bjoern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAku8ZS8ACgkQP5ijxgQLUNlyqACfWgQyom6YnQBrwNTGp86eu5tp dWkAnjYgM/Pcm0HX5wGECZ0OacYCV2eT =8sro -----END PGP SIGNATURE-----

2 4

pci_set_master in dde linux26
by Da Zheng 07 Apr '10

07 Apr '10

Hello, We tried to run the e100 driver with the hurd porting of dde linux26, but got one problem, i.e., pci_set_master() hasn't been implemented. In linux26/lib/src/arch/l4/pci.c, void pci_set_master(struct pci_dev *dev) { CHECK_INITVAR(dde26_pci); WARN_UNIMPL; } Were there any reasons that pci_set_master() was implemented? It seems pci_set_master() only needs to read or write the PCI configuration space. Best regards, Zheng Da

2 1

a bug fix in dde linux26
by Da Zheng 07 Apr '10

07 Apr '10

Hello, There is a small bug __kmalloc in DDE Linux26: when the memory is allocated by ddekit_large_malloc, the memory isn't set to zero even when __GFP_ZERO is set. It could cause some potential problems. For example, when a programmer calls kzalloc to allocate memory, he wants a piece of memory that has been set to zero. When I ran e1000 in DDE Linux26, this bug caused a big problem. Best regards, Zheng Da

1 0

Hello and make problem
by Leonardo Lazzaro 28 Mar '10

28 Mar '10

Hello, Today I started to read about l4linux and I wanted to build the l4-kernel. I tried to follow the steps at l4 webpage, now I am running ubuntu 9.10 and i am getting this error at make configure: error: You will need at least bison version 2.1a (found 2.4.1). Since it dont have too much sense (at least lower version but it found newer one) I suscript to the list to report this problem. Its important to know that : I found the l4-linux via google, download the code via svn trunk and follow the steps at the webpage. all this took me like 15min (found and tried to make, not compilation time) so I didnt read any docs (I should do it before send this email). I dont know if this kernel will work under ubuntu, and I think I will find more problems ahead. If anyone could recommend docs to read (or better the order to read them) about l4kernel. Sorry for bad english!

2 1

[ANNOUNCE] NOVA Microhypervisor 0.1 prerelease
by Udo A. Steinberg 08 Mar '10

08 Mar '10

Hi, The NOVA project is happy to announce that there is a prerelease of the NOVA microhypervisor available for download at http://www.hypervisor.org/ or http://os.inf.tu-dresden.de/~us15/nova/ under the terms of the GNU Public License version 2. NOVA is based on a modern microhypervisor written in C++ and assembler. It currently supports x86-32 SMP platforms with hardware virtualization features, such as Intel VT-x or AMD-V, and facilitates running multiple unmodified guest operating systems in virtual machines with near-native performance. On machines without VT-x or AMD-V, the functionality is reduced to that of a microkernel. Like third-generation microkernels, the NOVA microhypervisor uses a capability-based authorization model and provides only basic mechanisms for spatial and temporal isolation, scheduling, communication and delegation of platform resources. Additional services are provided by an unprivileged multi-server user environment running on top of the microhypervisor. In NOVA, we implemented almost all of the virtualization functionality in a deprivileged user-level virtual-machine monitor. This design choice improves the overall security of the system, because exploitation of a bug in the platform virtualization code only compromises the VMM and leaves the remaining components unaffected. Cheers, - Udo

6 9

Re: A question about the softirq implementation in DDE Linux26
by Da Zheng 01 Mar '10

01 Mar '10

Hi, On 10-2-27 上午9:10, Dirk Vogt wrote: > Hej, > You're right. There is indeed a problem, which we haven't stumbled over > yet. That is, because the irq handler runs at at a higher priority in > our ddekit implementation. However on a multiprocessor machine this I don't understand. How can using a higher priority in the irq handler solve/avoid the problem? unless you mean running the softirq thread in a higher priority. Otherwise, the softirq thread can still be preempted and lose raised softirq as I mentioned in the previous letter. > problem would indeed occur. We recognized the problem and are currently > discussing solutions. One Solution would be to have one Soft-irq thread > for each irq. You can expect a fix for this soon. If mach supports it Isn't it the current implementation? In DDE, each driver has one irq and one softirq thread? > and you are using a single core machine a suggest to raise the prio of > the irq handler thread in the ddekit as workaround. In my current porting, I already raise the priority of the irq handler, but it doesn't solve the problem. I am thinking of using a lock to simulate cli/sti. When local_irq_enable() or local_irq_save() is called, we hold the lock; when local_irq_restore() or local_irq_disable(), we release the lock. We can even provide nested locking support if local_irq_enable() or local_irq_save() is allowed to be called multiple times in the same thread. Best regards, Zheng Da

3 9