Genode on RPI - second round

[Tomasz Gajewski]

Stefan Kalkowski <stefan.kalkowski at genode-labs.com> writes:

> Hi Tomasz,
>
> first of all: congratulation for going that far with RPI3.

Thanks.

> On Mon, Feb 18, 2019 at 11:21:10PM +0100, Tomasz Gajewski wrote:
>> 
>> Hi again,
>> 
>> > 3. run/smp test hangs during threads destruction
>> >
>> > Like I wrote earlier run/smp test is almost working on multiple
>> > cores. It hangs somewhere in [5] during destructing thread running
>> > non-zero core (destroying first one does not cause problems).
>> >
>> > I don't have any concrete questions here. The only ones are:
>> >
>> >  a. Does this test properly work on arndale?
>> >
>> >  b. Do you have any thoughts what can go wrong? Maybe I haven't
>> >     implemented something important for smp yet? Only timer and IPI?
>> 
>> Situation with this test has changed after I rebased my branch to
>> current staging. It doesn't stop at threads destruction in Affinity test
>> like earlier so probably something was fixed since 18.11 release.
>> 
>> Currently it hangs a little further:
>> 
>> ...
>> init -> test-smp] Affinity: Round 09:  A  A  A  A 
>> [init -> test-smp] Affinity:     CPU: 00 01 02 03 
>> [init -> test-smp] Affinity: Round 10:  A  A  A  A 
>> [init -> test-smp] Affinity: --- test finished ---
>> [init -> test-smp] TLB: --- test started ---
>> [init -> test-smp] TLB: thread started on CPU 1
>> [init -> test-smp] TLB: thread started on CPU 2
>> [init -> test-smp] TLB: thread started on CPU 3
>> [init -> test-smp] TLB: all threads are up and running...
>> [init -> test-smp] TLB: ram dataspace destroyed, all will fault...
>> no RM attachment (READ pf_addr=0xc00c pf_ip=0x1000d2c from
>> pager_object: pd='init -> test-smp' thread='tlb_thread')
>> Warning: page fault, pager_object: pd='init -> test-smp'
>> thread='tlb_thread' ip=0x1000d2c fault-addr=0xc00c type=no-page
>> Warning: core -> pager_ep: cannot submit unknown signal context
>> [init -> test-sm
>> 
>
> The page-fault of this tlb-thread is perfectly fine! It is what is
> tested here exactly. Actually, you should see three faulting
> tlb-threads.
> The test forks threads on each cpu apart from the first one, and let
> them infinetly work on a shared page, which is thereby in the TLB of
> the corresponding cpu. Because we do not start anything else on the
> other cpus, there is little probability that the TLB entry gets
> evicted. Then the first cpu unmaps the page. If cross-cpu TLB
> shootdown is implemented correctly for the platform, you should notice
> a fault on all other cpus.
>
> The question is why your messages end here, or did you just send a
> snippet?

No. Unfortunately it is what I get. From the beginning I have problems
with everything hanging after faults. I would expect some handler to be
invoked that would give me some debug information but I don't get any.

I have a feeling that some exceptions may be routed to hyp mode but I
didn't put much effort to confirm that. Is there any code that installs
exception handlers in hyp mode on base-hw on some other architecture
that I could check/use?

Generally from the beginning I had problems with hangs and I had no uart
driver at all. That's why I use macros to dump to memory. Unfortunately
this "framework" is also new and caused some troubles. I think I get
similar hangs when I generate mmu exception in kernel code. That's why I
think that such exceptions can be routed "somewhere else" (hyp?). Unless
you'll be able to help with some wild guess I'll have to read more arm
reference documentation and check control registers values.

Tomasz Gajewski