Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Another 6.99.31 amd64 panic



On Tue, Feb 11, 2014 at 05:28:11PM +0000, Christos Zoulas wrote:
> In article 
> <CAG0OUxizzaDgjffmfKU1tSiPwYLi-+AUS+98mNgv=e6oqkCaRw%mail.gmail.com@localhost>,
> Chavdar Ivanov  <ci4ic4%gmail.com@localhost> wrote:
> >Same with a kernel from today.
> >
> >Chavdar
> >
> >On 10 February 2014 16:38, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
> >> From a build at 2014/02/09 14:29 I get:
> >>
> >> ...
> >> boot device: raid0
> >> root on raid0a dumps on raid0b
> >> root file system type: ffs
> >> uvm_fault(0xfffffe8006d1ce60, 0x0, 4) -> e
> >> uvm_fault(0xfffffe8006d1ce60, 0x0, 4) -> e
> >> fatal page fault in supervisor mode
> >> trap type 6 code 0 rip ffffffff807d428e cs 8 rflags 10246 cr2 0 ilevel
> >> 0 rsp fffffe8006d09560
> >> curlwp 0xfffffe8006d2fa00 pid 1.1 lowest kstack 0xfffffe8006d06000
> >> kernel: page fault trap, code=0
> >> Stopped in pid 1.1 (init) at   netbsd:trap+0x99b:      movzwl   
> >> 0(%rax),%eax
> >> db{1}> bt
> >> trap() at netbsdL:trap+0x99b
> >> --- trap (number 6) ---
> >> ?() at 0
> >> execve_loadvm() at netbsd:execve_loadvm+0x1d6
> >> execve1() at netbsd:execve1+0x2d
> >> start_init() at netbsd:start_init+0x2a7
> >> db{1}>
> 
>         movq    256(%rbx), %rdx
>         movq    %rbx, %rsi
>         movq    -88(%rbp), %rdi
>         call    check_exec
> ->      movl    %eax, %r13d
>         testl   %eax, %eax
> 
> That does not look correct, can you use objdump --disassemble on kern_exec.o
> then compile kern_exec.c changing on the compile line s/-c/-S -gstabs/ and
> see which source line corresponds to your failing instruction by matching
> the offset from kern_exec.o to the instruction in kern_exec.s and then finding
> the source line to kern_exec.c?

objdump -r -d kern_exec.o will lookup the relocations for you.
But I'd guess that the backtrace has missed a function and the fault
is somewhere inside check_exec().
The address ffffffff807d428e printed by the fault code is probbaly correct.
Try 'objdump -d /netbsd' and sort out which function it is in.

        David

-- 
David Laight: david%l8s.co.uk@localhost


Home | Main Index | Thread Index | Old Index