Stelian Pop wrote:
> Before hanging, sometimes it just prints:
> Unable to handle kernel NULL pointer dereference at virtual address
> 0000004d
>
> Sometimes the oops is more complete (note that sometimes it also hangs in
> the middle of
> the printout):
> Unable to handle kernel NULL pointer dereference at virtual address
> 0000004d
> pgd = c0004000
> [0000004d] *pgd=00000000
> Internal error: Oops: 817 [#1]
> Modules linked in: xeno_timerbench
> CPU: 0
> PC is at xnpod_schedule+0x6b4/0x7f0
> LR is at xnpod_schedule+0x54c/0x7f0
> pc : [<c0056cc4>] lr : [<c0056b5c>] Not tainted
> sp : c7d41830 ip : c79e8044 fp : c7d41860
> r10: c0283c2c r9 : c0282
>
> Does this rings a bell to someone ?
Not much, but two remarks:
- last summer, there use to be such a problem on x86 because of some
wrong FPU switch. So, is FPU enabled ? Are you compiling latency with
-msoft-float ?
When announcing the ARM Adeos port, you told us that not all
exceptions were trapped by the Adeos patch. If one of the FPU
exceptions is not trapped, it would explain why we do not get the
usual message "Invalid use of FPU at ..." before the oops.
- as far as I know, xnpod_schedule never recurses, so, there is little
chance for PC and LR to be both in xnpod_schedule. If I am not wrong,
it means that you will have to have a look at the disassembly (sorry)
and see in really what functions the bugs happen. Sometimes the -r and
-S option of objdump help...
--
Gilles Chanteperdrix.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
