Booting L4Re on the CI20: Panic in sigma0
Paul Boddie
paul at boddie.org.uk
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)
createclibstable(L)
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...
pkg/l4re-core/lua/lib/contrib/src/lauxlib.c
...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):
t9=0101b2f8
gp=0109adc0
sp=80c41ef8
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...
pkg/l4re-core/ned/server/src/lua.cc
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.
Paul
More information about the l4-hackers
mailing list