Re: Another 6.99.31 amd64 panic

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

The panic still takes place with 6.99.32 from the overnight build.

Chavdar


On 11 February 2014 18:34, David Laight <david%l8s.co.uk@localhost> wrote:
> 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



-- 
----