Booting L4Re on the CI20: Panic in sigma0

Paul Boddie paul at
Wed Jul 19 19:40:23 CEST 2017

On Tuesday 18. July 2017 16.56.08 Paul Boddie wrote:
> 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!

Despite this success, I should point out that Ned doesn't manage to function 
at all. It would appear that upon starting, Ned tries to import various Lua 
libraries, and the second one causes a page fault:

Ned says: Hi World!
L = luaL_newstate()
luaL_requiref(L, "_G", libs[0].func, 1)
luaL_requiref(L, "package", libs[1].func, 1)
luaL_newlib(L, pk_funcs)
L4Re[rm]: unhandled read page fault at 0x8 pc=0x10350cc

Here, the first and last lines are normal logging output. The other lines are 
from my clumsy debugging statements. The exception always seems to occur in 
the luaL_checkversion_ function in...


...coincidentally when performing an operation like this:

sdc1    $f20,48(sp)

Looking at the registers in the kernel debugger, sp refers to a kernel 
address. Meanwhile, the t9 and gp addresses are valid for accesses to the 
global offset table (verified from an objdump on ned):


Trying to check the stack pointer in the offending function is awkward because 
gcc will happily move any statement printing it out after instructions causing 
the page fault. Replacing the code with the stack pointer output statements 
produces a value of 0x8cd8 for sp, which is not a kernel address at least, but 
I have no idea if it is (or seems) valid.

A side-effect of removing the version-checking code is that this does not then 
obstruct the rest of the package-importing operations. However, another 
exception of this nature arises when attempting to invoke the execute_lua_buf 
function in...


It always seems to involve an address of 0x8, which seems rather bizarre. 
Again, I think I must be missing something fundamental and must only be seeing 
the consequences.


More information about the l4-hackers mailing list