Hello Stefan,
On 03.08.2017 12:27, Stephan Lex wrote:
I created a testcase in our repository for you, that shows the functionality we would like to achieve. ...
thanks for the test case. I just gave your branch a try. But please allow me the remark that I feel quite uneasy about debugging problems on a fork of an old Genode version. Aside the inconvenience of switching to an old tool chain, I was left uncertain about the following assumptions:
* Do I need to use the argos-research/genode repository with the branch called 'checkpointRestore'?
* Do I need to create a build directory for your customized version of the base-foc platform, called 'focnados_pbxa9'?
To lower the bar for people to assist you, it would be of great help if you rebase a test scenario to the most current version of Genode. So it becomes much easier to reproduce and we don't run into the risk of debugging problems that are already solved in a later version of Genode (not presuming that this is the case for the issue at hand).
What we were trying to achieve is running init as well as the three components on different cores in the system. Unfortunately the documentation for the affinity subspacing was a bit confusing for us, so it would be great, if you can tell us whether this is the right approach or what logic we are still missing.
I have not completely investigated your scenario but made the following interesting observations while tinkering with it:
* Even though you instruct Qemu to emulate a 4-core machine, the Platform::affinity_space method reports a physical affinity space of 2x1. Maybe the CPU detection is at fault? Or the kernel indeed only sees 2 CPUs? Anyhow, the logical affinity space of 4x1 as defined in your init configuration is ultimately mapped to a physical affinity space of 2x1, which is certainly not your intention.
* The member variable '_location' is designated for the location of a thread within the physical affinity space but it is not used anywhere. Instead, the value should somehow end up being specified to a kernel operation during the thread creation. Hence, regardless of the affinity arguments, they remain without effect.
* Unfortunately, the Fiasco.OC kernel debugger is quite incomplete when using the pbxa9 platform. I suggest to first debug the problem on a more common platform such as x86_32 where the kernel debugger is able to show the CPU number of each thread (via the 'lp' command). A quick test, however, shows that the 'focnados' base platform is apparently tied to ARM. (I get compile errors with ARM register names on x86_32). But maybe the base platform can be easily revived for x86_32?
I hope this little input brings you a bit further.
Cheers Norman