Re: Physical memory allocation to L4linux
Hey Adam, Yes I can confirm that I was a able to trace the code from fpage_map() to map() but I see zero addresses there - i.e. When I check the receiver and sender addresses and size everything is zero. This was despite it being correct until the handle_sigma0_request() function in mem_map.cc. So I just assumed I was looking in the wrong place. I will try to dig a little more and check. Sent from my phone On 15 Sep 2014, at 23:55, Adam Lackorzynski a...@os.inf.tu-dresden.de wrote: Hi, On Mon Sep 15, 2014 at 18:25:37 +, Masti Ramya Jayaram wrote: Thanks for the input. I will try changing one of the suggested functions. It would be great out of curiosity if you could elucidate why the following occurs. I see that there is a new iomem region being created and this happens only when I try to read from the mapped region - not until then. But none of this reaches the kernel or maybe I am not sure where to look.. Well, it should reach the kernel. For sigma0 mappings appear out of nothing (it's the root), so you should at least see it in the mapping loop in map_util.cpp's map() function (also see the comments on sigma0 there). In fact, I see that the init_mem file parses the kernel memory descriptors to find the regions. So under what circumstances does sigma0 go back to the kernel for mem/io? In this case there a fpage is created that is used in the reply to the client which will then create the mapping. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: l4/sys/syscalls.h: No such file or directory
Hi, On 09/16/2014 12:04 AM, Adam Lackorzynski wrote: Are there any entries? Yes, there are produced more than thousand identical entries in less than a second: pf: 0026 pfa=4f3c ip=01000200 (w-) spc=0xfcffae94 err=6 '26' is the id of the thread that is waiting for '1b'. On 09/16/2014 12:04 AM, Adam Lackorzynski wrote: And generally, what are the threads doing? They are doing a colored Hello World output. It's still the same code that I've sent you on September 5th in the zip file. You can find the thread function(s) in examples/libedft-example/main.c. Today, I've tested a very minimal example reducing the thread functions to nothing else but a simple 'printf(Hello World!);', but it's still the same issue. Best regards, Valentin ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: l4/sys/syscalls.h: No such file or directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.09.2014 13:15, Valentin Hauner wrote: Hi, On 09/16/2014 12:04 AM, Adam Lackorzynski wrote: Are there any entries? Yes, there are produced more than thousand identical entries in less than a second: pf: 0026 pfa=4f3c ip=01000200 (w-) spc=0xfcffae94 err=6 So you are triggering a write page fault at address 0x4f3c. The faulting instruction is at 0x1000200. * What is this instruction? * What address is this? It does not seem to be part of the binary as it is far off the instruction address. * Does this page fault appear in your pager? (It should?) * What are you sending as a reply to this page fault? Bjoern -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQYHUwACgkQP5ijxgQLUNnIsgCfX98UbISNgcBGN8z/q8X8Hft2 SNIAniwdD5i3HOHy9/YgBA4CzQHJQNuD =5yQE -END PGP SIGNATURE- ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: l4/sys/syscalls.h: No such file or directory
Hi, thanks again for your quick reply! On 09/16/2014 01:21 PM, Björn Döbel wrote: * What is this instruction? * What address is this? It does not seem to be part of the binary as it is far off the instruction address. * Does this page fault appear in your pager? (It should?) * What are you sending as a reply to this page fault? I'm not sure how to get any further information of this instruction. The JDB manual did not provide any help for that. Moreover, I guess it's not possible to deduce the line of code in my C files from that instruction pointer, is it? Special pre-compiler debugging features would be necessary for that. Best regards, Valentin ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: l4/sys/syscalls.h: No such file or directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.09.2014 13:40, Valentin Hauner wrote: Hi, thanks again for your quick reply! On 09/16/2014 01:21 PM, Björn Döbel wrote: * What is this instruction? * What address is this? It does not seem to be part of the binary as it is far off the instruction address. * Does this page fault appear in your pager? (It should?) * What are you sending as a reply to this page fault? I'm not sure how to get any further information of this instruction. The JDB manual did not provide any help for that. Moreover, I guess it's not possible to deduce the line of code in my C files from that instruction pointer, is it? Special pre-compiler debugging features would be necessary for that. Know your tools! man objdump man addr2line man nm man gcc / man clang man gdb Bjoern - -- Dipl.-Inf. Bjoern DoebelMail: doe...@tudos.org TU Dresden, OS ChairPhone: +49 351 463 38 799 Noethnitzer Str. 46 Fax: +49 351 463 38 284 01187 Dresden, Germany WWW: http://www.tudos.org/~doebel - -- When the seagulls follow the trawler, it's because they think sardines will be thrown into the sea. (Eric Cantona) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQYJIgACgkQP5ijxgQLUNmiuwCgh5lYuDYGiU+l+Ldv4nNWaboP FrcAnR+qY4EWqeB/78/1TuaRqCatQTd3 =9KWC -END PGP SIGNATURE- ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: l4/sys/syscalls.h: No such file or directory
Hi, thanks, I've used addr2line and found out that it was the head of thread_func (l. 27 in examples/libedft-example/main.c). So it seems that the stack I'm using for passing arguments to the thread function is the problem. As I am creating a dynamic number of threads, it does not make sense for me to create the stack object(s) statically as you guys do it in examples/sys/utcb-ipc/main.c. So until now, I've allocated memory on the _heap_ with malloc for each thread stack (l. 61 in lib/src/edft.c). But after creating 4 stacks for 4 example threads statically similiar to the utcb-ipc example, the page fault at 0x1000200 is gone. However, for each of the 4 threads, I'm getting a new page fault at 0: L4Re[rm]: unhandled read page fault @0 pc=0 L4Re: unhandled exception: pc=0x0 L4Re[rm]: unhandled read page fault @0 pc=0 L4Re: unhandled exception: pc=0x0 L4Re[rm]: unhandled read page fault @0 pc=0 L4Re: unhandled exception: pc=0x0 L4Re[rm]: unhandled read page fault @0 pc=0 L4Re: unhandled exception: pc=0x0 Why is this? Best regards, Valentin ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: l4/sys/syscalls.h: No such file or directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.09.2014 15:26, Valentin Hauner wrote: Hi, thanks, I've used addr2line and found out that it was the head of thread_func (l. 27 in examples/libedft-example/main.c). So it seems that the stack I'm using for passing arguments to the thread function is the problem. As I am creating a dynamic number of threads, it does not make sense for me to create the stack object(s) statically as you guys do it in examples/sys/utcb-ipc/main.c. So until now, I've allocated memory on the _heap_ with malloc for each thread stack (l. 61 in lib/src/edft.c). Just to be sure: How large is this per-thread stack? Are you properly aligning it to page boundaries? Otherwise you might miss mapping some parts of the stack. (Mappings always base on hardware memory pages, that's why your stack should be a multiple of a page size large and start at an address that is the start of a page.) But after creating 4 stacks for 4 example threads statically similiar to the utcb-ipc example, the page fault at 0x1000200 is gone. It's a bad idea to figure this out before you fix the previous problem. Let's keep complexity low. Bjoern - -- Dipl.-Inf. Bjoern DoebelMail: doe...@tudos.org TU Dresden, OS ChairPhone: +49 351 463 38 799 Noethnitzer Str. 46 Fax: +49 351 463 38 284 01187 Dresden, Germany WWW: http://www.tudos.org/~doebel - -- When the seagulls follow the trawler, it's because they think sardines will be thrown into the sea. (Eric Cantona) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQYQRYACgkQP5ijxgQLUNmAqgCeLOvLCpV0jliwYIDe4iAO6Ppw yCcAn1E62UdfcdOX4+vHK2J17GNvUsmN =nTi6 -END PGP SIGNATURE- ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: l4/sys/syscalls.h: No such file or directory
Hi,
On 09/16/2014 03:54 PM, Björn Döbel wrote:
Just to be sure: How large is this per-thread stack? Are you properly
aligning it to page boundaries?
Adam suggested to give it a size of 2000 * l4_umword_t
(THREAD_STACK_SIZE is set to 2000) in his mail from September 3th, so
I'm using the following code:
thread_stack[count] = malloc(THREAD_STACK_SIZE * sizeof(l4_umword_t));
// For x86-32, the arguments of functions are passed via the stack
thread_stack[count][THREAD_STACK_SIZE - 1] = (l4_umword_t)t-arg;
thread_stack[count][THREAD_STACK_SIZE - 2] = 0;
// ...
l4_touch_rw(thread_stack[count], sizeof(thread_stack[count]));
// ...
l4_thread_ex_regs(t-cap,
(l4_umword_t)t-func,
(l4_umword_t)thread_stack[count][THREAD_STACK_SIZE - 2], 0);
Header of the thread function:
void thread_func(l4_umword_t data) { /* ... */ }
That's the whole stack-relevant code in my library. With one task for
all threads only, everything works.
Best regards,
Valentin
___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Trimming uclibc in l4
Dear all, I would like to extract the minimal subset of uclibc required by bootstrap, sigma and their dependencies only. My idea is to have these modules use the smaller libc while retain the usual uclibc build for the other packages. I intend to go about this by copying uclibc (say into uclibc_min) and then modifying the contrib_files_all.lst and contrib_files_x86.lst. Is this the correct way to do this? Also, I extracted all the package dependencies of bootstrap and sigma from the control files (below) bootstrap: drivers_uart drivers_of libc l4util cxx_io drivers-frst:libc l4util: crtn libc crtn: l4sys l4sys: ldscripts l4util: crtn libc cxx: l4sys l4util ulibc: l4sys sigma0: crtn l4sys l4util libsigma0 cxx_io libsigma0: l4sys Is this the correct way to do this as well? Thanks, Ramya ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
RE: Trimming uclibc in l4
Update: turns out it is not very simple to compile just bootstrap against a smaller library because the l4/mk/modes.inc file defaults to the uclibc library for compiling the files which is used for all packages. Any ideas how I can change this only for some packages? Thanks. Ramya From: l4-hackers [l4-hackers-boun...@os.inf.tu-dresden.de] on behalf of Masti Ramya Jayaram [rma...@inf.ethz.ch] Sent: 16 September 2014 17:53 To: l4-hackers@os.inf.tu-dresden.de Subject: Trimming uclibc in l4 Dear all, I would like to extract the minimal subset of uclibc required by bootstrap, sigma and their dependencies only. My idea is to have these modules use the smaller libc while retain the usual uclibc build for the other packages. I intend to go about this by copying uclibc (say into uclibc_min) and then modifying the contrib_files_all.lst and contrib_files_x86.lst. Is this the correct way to do this? Also, I extracted all the package dependencies of bootstrap and sigma from the control files (below) bootstrap: drivers_uart drivers_of libc l4util cxx_io drivers-frst:libc l4util: crtn libc crtn: l4sys l4sys: ldscripts l4util: crtn libc cxx: l4sys l4util ulibc: l4sys sigma0: crtn l4sys l4util libsigma0 cxx_io libsigma0: l4sys Is this the correct way to do this as well? Thanks, Ramya ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
RE: Trimming uclibc in l4
Hey Markus, I am using a version from April 2011 but even that version contains a lot of things that bootstrap and sigma0 do not need. :) Did you mean more recent than that? best, ramya p.s. my board requires that I run an older version of the kernel - so the pain. From: l4-hackers [l4-hackers-boun...@os.inf.tu-dresden.de] on behalf of Marcus Hähnel [mhaeh...@os.inf.tu-dresden.de] Sent: 16 September 2014 18:31 To: l4-hackers@os.inf.tu-dresden.de Subject: Re: Trimming uclibc in l4 Hi, I would like to extract the minimal subset of uclibc required by bootstrap, sigma and their dependencies only. My idea is to have these modules use the smaller libc while retain the usual uclibc build for the other packages. Great idea, but you should probably update your L4Re. L4Re features such a minimal version since about 2011. So no need to do the same work twice :) - Marcus I intend to go about this by copying uclibc (say into uclibc_min) and then modifying the contrib_files_all.lst and contrib_files_x86.lst. Is this the correct way to do this? Also, I extracted all the package dependencies of bootstrap and sigma from the control files (below) bootstrap: drivers_uart drivers_of libc l4util cxx_io drivers-frst:libc l4util: crtn libc crtn: l4sys l4sys: ldscripts l4util: crtn libc cxx: l4sys l4util ulibc: l4sys sigma0: crtn l4sys l4util libsigma0 cxx_io libsigma0: l4sys Is this the correct way to do this as well? Thanks, Ramya ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: Trimming uclibc in l4
Hi, as Marcus already pointed out, newer versions of L4Re actually contain a package called uclibc_minimal that serves exactly this purpose. Even if you are using an older snapshot, chances are that backporting this package (and adapting l4/mk) might be easier than stripping things down yourself. Bjoern Am 16.09.2014 um 19:02 schrieb Masti Ramya Jayaram: Update: turns out it is not very simple to compile just bootstrap against a smaller library because the l4/mk/modes.inc file defaults to the uclibc library for compiling the files which is used for all packages. Any ideas how I can change this only for some packages? Thanks. Ramya From: l4-hackers [l4-hackers-boun...@os.inf.tu-dresden.de] on behalf of Masti Ramya Jayaram [rma...@inf.ethz.ch] Sent: 16 September 2014 17:53 To: l4-hackers@os.inf.tu-dresden.de Subject: Trimming uclibc in l4 Dear all, I would like to extract the minimal subset of uclibc required by bootstrap, sigma and their dependencies only. My idea is to have these modules use the smaller libc while retain the usual uclibc build for the other packages. I intend to go about this by copying uclibc (say into uclibc_min) and then modifying the contrib_files_all.lst and contrib_files_x86.lst. Is this the correct way to do this? Also, I extracted all the package dependencies of bootstrap and sigma from the control files (below) bootstrap: drivers_uart drivers_of libc l4util cxx_io drivers-frst:libc l4util: crtn libc crtn: l4sys l4sys: ldscripts l4util: crtn libc cxx: l4sys l4util ulibc: l4sys sigma0: crtn l4sys l4util libsigma0 cxx_io libsigma0: l4sys Is this the correct way to do this as well? Thanks, Ramya ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
RE: Trimming uclibc in l4
Hi Ramya, On 2014-09-16 19:05, Masti Ramya Jayaram wrote: Hey Markus, I am using a version from April 2011 but even that version contains a lot of things that bootstrap and sigma0 do not need. :) Did you mean more recent than that? this version is severely outdated :x. Please use a recent version (read: the current snapshot or svn head) unless you have a very good reason not to. Especially since it already contains features such as minimal uclibc for core programs, which you obviously want. Using recent versions will also help us help you, as a lot has changed in over 3 years. Best regards - Marcus best, ramya p.s. my board requires that I run an older version of the kernel - so the pain. From: l4-hackers [l4-hackers-boun...@os.inf.tu-dresden.de] on behalf of Marcus Hähnel [mhaeh...@os.inf.tu-dresden.de] Sent: 16 September 2014 18:31 To: l4-hackers@os.inf.tu-dresden.de Subject: Re: Trimming uclibc in l4 Hi, I would like to extract the minimal subset of uclibc required by bootstrap, sigma and their dependencies only. My idea is to have these modules use the smaller libc while retain the usual uclibc build for the other packages. Great idea, but you should probably update your L4Re. L4Re features such a minimal version since about 2011. So no need to do the same work twice :) - Marcus I intend to go about this by copying uclibc (say into uclibc_min) and then modifying the contrib_files_all.lst and contrib_files_x86.lst. Is this the correct way to do this? Also, I extracted all the package dependencies of bootstrap and sigma from the control files (below) bootstrap: drivers_uart drivers_of libc l4util cxx_io drivers-frst:libc l4util: crtn libc crtn: l4sys l4sys: ldscripts l4util: crtn libc cxx: l4sys l4util ulibc: l4sys sigma0: crtn l4sys l4util libsigma0 cxx_io libsigma0: l4sys Is this the correct way to do this as well? Thanks, Ramya ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
