On Tuesday 18. July 2017 08.58.14 Sarah Hoffmann wrote:
There is a bug in the Fiasco where it sends the wrong message size. Please apply the attached patch to Fiasco. Afterwards you should get more useful error messages in your L4 applications when it throws exceptions.
Yes, this fixes the recurring failure to handle the page fault successfully. Thanks for sending this!
[...]
An address error generally means that you are trying to access a bad address (which would be the case with the PFA given above). This is different from a normal page fault, which corresponds to TLB exceptions. That is why sigma0 is not involved.
Right. I appreciate the clarification here.
Exceptions are directly sent to the exception handler which in a standard L4 application is the thread started first (l4re-kernel thread) or, if that one fails, the launcher (moe in your case).
Yes, this is what I might have expected.
[...]
The t9 issue is a likely cause. There are a couple of places where .cpload is used.
I found another location where t9 is not initialised:
pkg/l4re-core/l4re_kernel/server/src/ARCH-mips/loader_mips.S
I had actually seen this, but I guess I was distracted too much with the other problems to realise that it needed changing.
So, I applied the Fiasco patch and then looked at the above file, checking the objdump output for the l4re binary. With the patch applied, the page fault did not occur endlessly, and with a change to the above file similar to those already made for sigma0 and moe, it appears that the page fault is eliminated completely. As a consequence, the "hello" example now runs, finally!
I have attached a few patches required to make this happen in my 32-bit Intel, Debian-based mipsel-linux-gnu development environment:
ci20-gcc-cpload.diff Initialises t9 for .cpload ci20-gcc-debian.diff Uses the mipsel-linux-gnu toolchain prefix ci20-rdhwr.diff Implements rdhwr SYNCI_Step handling ci20-uart0.diff Uses the UART0 connection to work around UART4 problems no-at.diff A missing definition (mentioned previously on this list)
The rdhwr patch could probably be improved, and I think there are places in the affected file where common code could be consolidated a bit more.
I appreciate the help and guidance you have provided in getting me to this point, and I hope now to try and test the drivers that I had written in advance of getting the examples working.
Thanks once again,
Paul