Hi,
I'm being spectacularly unsuccessful in getting a process thread to be associated with an RM Pager object.
I have an application whose main function creates an object instance based on a Thread. That instance creates another object instance whose main purpose is to read and write to an ffat file system through the libc plug-in for that purpose. As soon as this object attempts to access the file system a error message complaining about no pager object implemented ("/void Genode::Pager_object::unresolved_page_fault_occurred(): not implemented/") occurs.
On re-reading the Architecture documentation about RM in the Core, it *very* briefly explains that a thread capability for a pager needs to be created for the thread, using an add_client function call. I assumed this would be done in the thread entry() member function and added the following line of code at the the beginning of that function:
Thread_capability ap = Thread::cap(); Pager_capability pc = env()->rm_session()->add_client(ap); env()->cpu_session()->set_pager(ap, pc);
This did not work and I got he same error message about no pager object.
In looking through the threading code, I noticed that Thread_base::start() creates the thread and sets up a pager. Adding a void start() function to my thread with a call to the Thread_base::start function resulted in the same error.
I finally got a pager to be associated with the thread and access the file system by creating my own thread object in my thread start() function, binding it to the PD, and setting up the pager with the snippet shown above the same as was done in the Thread_base::start() function.
I'm obviously confused about what's going with a process's region manager handling of threads. Could someone please enlighten me?
Thanks in advance, Bob Stewart Bob Stewart
Hello Bob,
I have an application whose main function creates an object instance based on a Thread. That instance creates another object instance whose main purpose is to read and write to an ffat file system through the libc plug-in for that purpose. As soon as this object attempts to access the file system a error message complaining about no pager object implemented ("/void Genode::Pager_object::unresolved_page_fault_occurred(): not implemented/") occurs.
this message is printed by the base-hw version of core if a program crashes (it corresponds to a segmentation fault on Linux). It would be interesting to see the surrounding log output of the message you quoted. Normally, core prints the instruction pointer and name of the thread that caused the trouble.
On re-reading the Architecture documentation about RM in the Core, it *very* briefly explains that a thread capability for a pager needs to be created for the thread, using an add_client function call. I assumed this would be done in the thread entry() member function and added the following line of code at the the beginning of that function:
Thread_capability ap = Thread::cap(); Pager_capability pc = env()->rm_session()->add_client(ap); env()->cpu_session()->set_pager(ap, pc);
This did not work and I got he same error message about no pager object.
I think you are on the wrong track. For implementing your service, you should not need to deal with the peculiarities of page-fault handling or thread creation at all.
I'm obviously confused about what's going with a process's region manager handling of threads. Could someone please enlighten me?
To get a clearer picture, you may find the documentation useful that I am currently writing. In particular the Sections "Component creation" (in the Architecture chapter) and "Page-fault handling" (in the Under-the-hood chapter) might be of interest:
https://github.com/nfeske/genode-manual
Right now, the document is not finished. So you have to go through the trouble to build it yourself (see the README for the instructions). I hope that it is still useful.
To investigate your problem, may you consider to make your branch along with a run script publicly available (e.g., on GitHub) so that I can reproduce it?
Cheers Norman
Thank you for the reply, Norman.
I am running base-hw on 14.11.
The complete log output is attached. As you can see there is no faulting address displayed. It sure looks like its complaining about the absence of a pager.
The run script is fairly extensive. Over the weekend, I'll try to strip it down to only the elements that appear to be involved in the issue and reproduce it with that script, Then, I can submit it via git.
I'll build your documentation and see if that helps me.
Thanks for the help.
Bob
On 01/23/2015 03:28 PM, Norman Feske wrote:
Hello Bob,
I have an application whose main function creates an object instance based on a Thread. That instance creates another object instance whose main purpose is to read and write to an ffat file system through the libc plug-in for that purpose. As soon as this object attempts to access the file system a error message complaining about no pager object implemented ("/void Genode::Pager_object::unresolved_page_fault_occurred(): not implemented/") occurs.
this message is printed by the base-hw version of core if a program crashes (it corresponds to a segmentation fault on Linux). It would be interesting to see the surrounding log output of the message you quoted. Normally, core prints the instruction pointer and name of the thread that caused the trouble.
On re-reading the Architecture documentation about RM in the Core, it *very* briefly explains that a thread capability for a pager needs to be created for the thread, using an add_client function call. I assumed this would be done in the thread entry() member function and added the following line of code at the the beginning of that function:
Thread_capability ap = Thread::cap(); Pager_capability pc = env()->rm_session()->add_client(ap); env()->cpu_session()->set_pager(ap, pc);
This did not work and I got he same error message about no pager object.
I think you are on the wrong track. For implementing your service, you should not need to deal with the peculiarities of page-fault handling or thread creation at all.
I'm obviously confused about what's going with a process's region manager handling of threads. Could someone please enlighten me?
To get a clearer picture, you may find the documentation useful that I am currently writing. In particular the Sections "Component creation" (in the Architecture chapter) and "Page-fault handling" (in the Under-the-hood chapter) might be of interest:
https://github.com/nfeske/genode-manual
Right now, the document is not finished. So you have to go through the trouble to build it yourself (see the README for the instructions). I hope that it is still useful.
To investigate your problem, may you consider to make your branch along with a run script publicly available (e.g., on GitHub) so that I can reproduce it?
Cheers Norman
p.s. As a test of the need for a pager, when the object based on Thread is changed to include the following start(), is initializes correctly as shown in the attached log.
void start() { Thread_capability ap = Thread::cap(); env()->pd_session()->bind_thread(ap); Pager_capability pc = env()->rm_session()->add_client(ap); env()->cpu_session()->set_pager(ap, pc); entry(); } Bob
On 01/23/2015 05:21 PM, Bob Stewart wrote:
Thank you for the reply, Norman.
I am running base-hw on 14.11.
The complete log output is attached. As you can see there is no faulting address displayed. It sure looks like its complaining about the absence of a pager.
The run script is fairly extensive. Over the weekend, I'll try to strip it down to only the elements that appear to be involved in the issue and reproduce it with that script, Then, I can submit it via git.
I'll build your documentation and see if that helps me.
Thanks for the help.
Bob
On 01/23/2015 03:28 PM, Norman Feske wrote:
Hello Bob,
I have an application whose main function creates an object instance based on a Thread. That instance creates another object instance whose main purpose is to read and write to an ffat file system through the libc plug-in for that purpose. As soon as this object attempts to access the file system a error message complaining about no pager object implemented ("/void Genode::Pager_object::unresolved_page_fault_occurred(): not implemented/") occurs.
this message is printed by the base-hw version of core if a program crashes (it corresponds to a segmentation fault on Linux). It would be interesting to see the surrounding log output of the message you quoted. Normally, core prints the instruction pointer and name of the thread that caused the trouble.
On re-reading the Architecture documentation about RM in the Core, it *very* briefly explains that a thread capability for a pager needs to be created for the thread, using an add_client function call. I assumed this would be done in the thread entry() member function and added the following line of code at the the beginning of that function:
Thread_capability ap = Thread::cap(); Pager_capability pc = env()->rm_session()->add_client(ap); env()->cpu_session()->set_pager(ap, pc);
This did not work and I got he same error message about no pager object.
I think you are on the wrong track. For implementing your service, you should not need to deal with the peculiarities of page-fault handling or thread creation at all.
I'm obviously confused about what's going with a process's region manager handling of threads. Could someone please enlighten me?
To get a clearer picture, you may find the documentation useful that I am currently writing. In particular the Sections "Component creation" (in the Architecture chapter) and "Page-fault handling" (in the Under-the-hood chapter) might be of interest:
https://github.com/nfeske/genode-manual
Right now, the document is not finished. So you have to go through the trouble to build it yourself (see the README for the instructions). I hope that it is still useful.
To investigate your problem, may you consider to make your branch along with a run script publicly available (e.g., on GitHub) so that I can reproduce it?
Cheers Norman
New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Please ignore the attachment to the last e-mail, The attached is the correct one.
Bob
On 01/23/2015 05:57 PM, Bob Stewart wrote:
p.s. As a test of the need for a pager, when the object based on Thread is changed to include the following start(), is initializes correctly as shown in the attached log.
void start() { Thread_capability ap = Thread::cap(); env()->pd_session()->bind_thread(ap); Pager_capability pc = env()->rm_session()->add_client(ap); env()->cpu_session()->set_pager(ap, pc); entry(); } Bob
On 01/23/2015 05:21 PM, Bob Stewart wrote:
Thank you for the reply, Norman.
I am running base-hw on 14.11.
The complete log output is attached. As you can see there is no faulting address displayed. It sure looks like its complaining about the absence of a pager.
The run script is fairly extensive. Over the weekend, I'll try to strip it down to only the elements that appear to be involved in the issue and reproduce it with that script, Then, I can submit it via git.
I'll build your documentation and see if that helps me.
Thanks for the help.
Bob
On 01/23/2015 03:28 PM, Norman Feske wrote:
Hello Bob,
I have an application whose main function creates an object instance based on a Thread. That instance creates another object instance whose main purpose is to read and write to an ffat file system through the libc plug-in for that purpose. As soon as this object attempts to access the file system a error message complaining about no pager object implemented ("/void Genode::Pager_object::unresolved_page_fault_occurred(): not implemented/") occurs.
this message is printed by the base-hw version of core if a program crashes (it corresponds to a segmentation fault on Linux). It would be interesting to see the surrounding log output of the message you quoted. Normally, core prints the instruction pointer and name of the thread that caused the trouble.
On re-reading the Architecture documentation about RM in the Core, it *very* briefly explains that a thread capability for a pager needs to be created for the thread, using an add_client function call. I assumed this would be done in the thread entry() member function and added the following line of code at the the beginning of that function:
Thread_capability ap = Thread::cap(); Pager_capability pc = env()->rm_session()->add_client(ap); env()->cpu_session()->set_pager(ap, pc);
This did not work and I got he same error message about no pager object.
I think you are on the wrong track. For implementing your service, you should not need to deal with the peculiarities of page-fault handling or thread creation at all.
I'm obviously confused about what's going with a process's region manager handling of threads. Could someone please enlighten me?
To get a clearer picture, you may find the documentation useful that I am currently writing. In particular the Sections "Component creation" (in the Architecture chapter) and "Page-fault handling" (in the Under-the-hood chapter) might be of interest:
https://github.com/nfeske/genode-manual
Right now, the document is not finished. So you have to go through the trouble to build it yourself (see the README for the instructions). I hope that it is still useful.
To investigate your problem, may you consider to make your branch along with a run script publicly available (e.g., on GitHub) so that I can reproduce it?
Cheers Norman
New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
I've stripped down the problem to a simple main routine, a threaded object that is instantiated in main and contains only the code to create the object that accesses the file system. This stripped down version results in the same pager issue.
The attached tar contains the main, the simplified code of the thread-based class, the file server access code, the run scipt I used for testing, and the console log.
The main routine contains a fault handler that I copied from a test program in base/src and that thread is started prior to starting the problem thread.
I can instantiate the file system object in main and the initialization routine successfully access the file system, so the code in there does work.
I can see no reason why the rm is failing to add the necessary dataspace. I've tried adding time delays between starting the fault handler and instantiating the other object with no change in result.
This is not a show-stopper for me as I can proceed using the main thread. If necessary I can add an issue to the git repository.
Thanks, Bob On 01/23/2015 06:07 PM, Bob Stewart wrote:
Please ignore the attachment to the last e-mail, The attached is the correct one.
Bob
On 01/23/2015 05:57 PM, Bob Stewart wrote:
p.s. As a test of the need for a pager, when the object based on Thread is changed to include the following start(), is initializes correctly as shown in the attached log.
void start() { Thread_capability ap = Thread::cap(); env()->pd_session()->bind_thread(ap); Pager_capability pc = env()->rm_session()->add_client(ap); env()->cpu_session()->set_pager(ap, pc); entry(); } Bob
On 01/23/2015 05:21 PM, Bob Stewart wrote:
Thank you for the reply, Norman.
I am running base-hw on 14.11.
The complete log output is attached. As you can see there is no faulting address displayed. It sure looks like its complaining about the absence of a pager.
The run script is fairly extensive. Over the weekend, I'll try to strip it down to only the elements that appear to be involved in the issue and reproduce it with that script, Then, I can submit it via git.
I'll build your documentation and see if that helps me.
Thanks for the help.
Bob
On 01/23/2015 03:28 PM, Norman Feske wrote:
Hello Bob,
I have an application whose main function creates an object instance based on a Thread. That instance creates another object instance whose main purpose is to read and write to an ffat file system through the libc plug-in for that purpose. As soon as this object attempts to access the file system a error message complaining about no pager object implemented ("/void Genode::Pager_object::unresolved_page_fault_occurred(): not implemented/") occurs.
this message is printed by the base-hw version of core if a program crashes (it corresponds to a segmentation fault on Linux). It would be interesting to see the surrounding log output of the message you quoted. Normally, core prints the instruction pointer and name of the thread that caused the trouble.
On re-reading the Architecture documentation about RM in the Core, it *very* briefly explains that a thread capability for a pager needs to be created for the thread, using an add_client function call. I assumed this would be done in the thread entry() member function and added the following line of code at the the beginning of that function:
Thread_capability ap = Thread::cap(); Pager_capability pc = env()->rm_session()->add_client(ap); env()->cpu_session()->set_pager(ap, pc);
This did not work and I got he same error message about no pager object.
I think you are on the wrong track. For implementing your service, you should not need to deal with the peculiarities of page-fault handling or thread creation at all.
I'm obviously confused about what's going with a process's region manager handling of threads. Could someone please enlighten me?
To get a clearer picture, you may find the documentation useful that I am currently writing. In particular the Sections "Component creation" (in the Architecture chapter) and "Page-fault handling" (in the Under-the-hood chapter) might be of interest:
https://github.com/nfeske/genode-manual
Right now, the document is not finished. So you have to go through the trouble to build it yourself (see the README for the instructions). I hope that it is still useful.
To investigate your problem, may you consider to make your branch along with a run script publicly available (e.g., on GitHub) so that I can reproduce it?
Cheers Norman
New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Bob,
I've stripped down the problem to a simple main routine, a threaded object that is instantiated in main and contains only the code to create the object that accesses the file system. This stripped down version results in the same pager issue.
The attached tar contains the main, the simplified code of the thread-based class, the file server access code, the run scipt I used for testing, and the console log.
The main routine contains a fault handler that I copied from a test program in base/src and that thread is started prior to starting the problem thread.
I can instantiate the file system object in main and the initialization routine successfully access the file system, so the code in there does work.
thanks for stripping down the test case. I just tried it out and could reproduce the behavior. The problem is quite mundane though: You dimensioned the stack of the 'CommandTerminal' to be 4096 bytes. This is too low for a thread that calls the libc. I just increased the value by a factor of 10 and it works.
It has really nothing to do with the RM fault handling. The code of your example does not even use the RM connection that you created as a managed dataspace.
Admittedly, the error message printed by the base-hw version of core is not very instructive to identify such a stack-overflow problem. But thanks to your stripped-down example, I could execute it quickly on nova_x86_32, where a far more useful message appears:
static void Genode::Pager_object::_page_fault_handler(): unhandled page fault, 'pager:Command Terminal' address=0xa03fd8c0 ip=0x10a4327
Here we see the name of the thread that just crashed ("pager:Command Terminal"), the instruction pointer (ip), and the fault address. The fault address lies within the so-called thread-context area (defined in base-nova/include/base/native_types.h). This virtual-memory area hosts all the stacks. If a page fault occurs within the thread-context area, it is most likely a stack overflow.
We should really add a more useful diagnostic message to the base-hw version of core. I just created an issue for that:
https://github.com/genodelabs/genode/issues/1382
For reference, I have attached the run script and target.mk file that I used for reproducing the issue.
Cheers Norman
Than you very much, Norman. I've learned a bit more about Genode through this. I enjoy working with it.
Bob
Sent from my android device.
-----Original Message----- From: Norman Feske <norman.feske@...1...> To: genode-main@lists.sourceforge.net Sent: Sun, 25 Jan 2015 4:15 PM Subject: Re: Associating Threads with Process Rm's
Hi Bob,
I've stripped down the problem to a simple main routine, a threaded object that is instantiated in main and contains only the code to create the object that accesses the file system. This stripped down version results in the same pager issue.
The attached tar contains the main, the simplified code of the thread-based class, the file server access code, the run scipt I used for testing, and the console log.
The main routine contains a fault handler that I copied from a test program in base/src and that thread is started prior to starting the problem thread.
I can instantiate the file system object in main and the initialization routine successfully access the file system, so the code in there does work.
thanks for stripping down the test case. I just tried it out and could reproduce the behavior. The problem is quite mundane though: You dimensioned the stack of the 'CommandTerminal' to be 4096 bytes. This is too low for a thread that calls the libc. I just increased the value by a factor of 10 and it works.
It has really nothing to do with the RM fault handling. The code of your example does not even use the RM connection that you created as a managed dataspace.
Admittedly, the error message printed by the base-hw version of core is not very instructive to identify such a stack-overflow problem. But thanks to your stripped-down example, I could execute it quickly on nova_x86_32, where a far more useful message appears:
static void Genode::Pager_object::_page_fault_handler(): unhandled page fault, 'pager:Command Terminal' address=0xa03fd8c0 ip=0x10a4327
Here we see the name of the thread that just crashed ("pager:Command Terminal"), the instruction pointer (ip), and the fault address. The fault address lies within the so-called thread-context area (defined in base-nova/include/base/native_types.h). This virtual-memory area hosts all the stacks. If a page fault occurs within the thread-context area, it is most likely a stack overflow.
We should really add a more useful diagnostic message to the base-hw version of core. I just created an issue for that:
https://github.com/genodelabs/genode/issues/1382
For reference, I have attached the run script and target.mk file that I used for reproducing the issue.
Cheers Norman
-
unknown＠example.com -
Bob Stewart -
Norman Feske