Current-Users archive

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

Re: Another 6.99.31 amd64 panic



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?


christos



Home | Main Index | Thread Index | Old Index