Le mercredi 04 janvier 2006 à 18:19 +0100, Gilles Chanteperdrix a
écrit :
> 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 ?

Yes, everything is soft 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.

Time has passed and the exceptions are now trapped. 

> - 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...

I'll take a look. 

Stelian.
-- 
Stelian Pop <[EMAIL PROTECTED]>


Reply via email to