Associating Threads with Process Rm's

Bob Stewart robjsstewart at ...196...
Sat Jan 24 16:55:49 CET 2015


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 at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/genode-main
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20150124/99df1cd9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pager_issue.tar.gz
Type: application/gzip
Size: 3931 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20150124/99df1cd9/attachment.gz>


More information about the users mailing list