Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Jan 2015 15:20:05 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Steve Kargl <sgk@troutmask.apl.washington.edu>
Cc:        freebsd-current@freebsd.org
Subject:   Re: panic in pmap_remove_pages()
Message-ID:  <20150124132005.GU42409@kib.kiev.ua>
In-Reply-To: <20150123155808.GA36783@troutmask.apl.washington.edu>
References:  <20150121214706.GA912@troutmask.apl.washington.edu> <20150123105100.GH42409@kib.kiev.ua> <20150123155808.GA36783@troutmask.apl.washington.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 23, 2015 at 07:58:08AM -0800, Steve Kargl wrote:
> On Fri, Jan 23, 2015 at 12:51:00PM +0200, Konstantin Belousov wrote:
> > On Wed, Jan 21, 2015 at 01:47:06PM -0800, Steve Kargl wrote:
> > > Fatal trap 9: general protection fault while in kernel mode
> > > cpuid = 3; apic id = 13
> > > instruction pointer     = 0x20:0xffffffff8079abf9
> > > stack pointer           = 0x28:0xfffffe047325e360
> > > frame pointer           = 0x28:0xfffffe047325e440
> > > code segment            = base 0x0, limit 0xfffff, type 0x1b
> > >                         = DPL 0, pres 1, long 1, def32 0, gran 1
> > > processor eflags        = interrupt enabled, resume, IOPL = 0
> > > current process         = 41779 (z)
> > > trap number             = 9
> > > panic: general protection fault
> > > cpuid = 3
> > > KDB: stack backtrace:
> > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe047325e020
> > > panic() at panic+0x1c1/frame 0xfffffe047325e0e0
> > > trap_fatal() at trap_fatal+0x396/frame 0xfffffe047325e140
> > > trap() at trap+0x6ce/frame 0xfffffe047325e2a0
> > > calltrap() at calltrap+0x8/frame 0xfffffe047325e2a0
> > > --- trap 0x9, rip = 0xffffffff8079abf9, rsp = 0xfffffe047325e360, rbp = 0xfffffe047325e440 ---
> > > pmap_remove_pages() at pmap_remove_pages+0x539/frame 0xfffffe047325e440
> > > exec_new_vmspace() at exec_new_vmspace+0x180/frame 0xfffffe047325e4a0
> > > exec_elf64_imgact() at exec_elf64_imgact+0x6c0/frame 0xfffffe047325e570
> > > kern_execve() at kern_execve+0x484/frame 0xfffffe047325e8c0
> > > sys_execve() at sys_execve+0x35/frame 0xfffffe047325e920
> > > amd64_syscall() at amd64_syscall+0x289/frame 0xfffffe047325ea30
> > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe047325ea30
> > > --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x4251ba, rsp = 0x7ffffe8ebab8, rbp = 0x7ffffe8ec1c0 ---
> > > Uptime: 22d22h22m46s
> > > 
> > > #0  doadump (textdump=1) at pcpu.h:219
> > > 219	pcpu.h: No such file or directory.
> > > 	in pcpu.h
> > > (kgdb) #0  doadump (textdump=1) at pcpu.h:219
> > > #1  0xffffffff80555bd7 in kern_reboot (howto=260)
> > >     at /usr/src/sys/kern/kern_shutdown.c:447
> > > #2  0xffffffff80556040 in panic (fmt=<value optimized out>)
> > >     at /usr/src/sys/kern/kern_shutdown.c:746
> > > #3  0xffffffff807a2986 in trap_fatal (frame=<value optimized out>, 
> > >     eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:867
> > > #4  0xffffffff807a25de in trap (frame=<value optimized out>)
> > >     at /usr/src/sys/amd64/amd64/trap.c:201
> > > #5  0xffffffff80787ca3 in calltrap ()
> > >     at /usr/src/sys/amd64/amd64/exception.S:235
> > > #6  0xffffffff8079abf9 in pmap_remove_pages (pmap=0xfffff801c627dec8)
> > >     at /usr/src/sys/amd64/amd64/pmap.c:5389
> > Please do 'frame 6' and from there, do 'p *m'.  Is it reproducable ?
> > 
> 
> (kgdb) p *m
> $9 = {plinks = {q = {tqe_next = 0xfffff804384044c0, 
>       tqe_prev = 0xfffff8042e89eac0}, s = {ss = {
>         sle_next = 0xfffff804384044c0}, pv = 0xfffff8042e89eac0}, memguard = {
>       p = 18446735295740134592, v = 18446735295577189056}}, listq = {
>     tqe_next = 0xfffff8043cddb158, tqe_prev = 0xfffff804335c2358}, 
>   object = 0xfffff801882d5100, pindex = 30, phys_addr = 4352778240, md = {
>     pv_list = {tqh_first = 0xfffff800bc1d37a8, tqh_last = 0xfefff800bc1d37b0},
The tqh_last has single-bit error, note the 0xf_e_fff8... pattern of the
pv_list.tqh_last value. It is consistent with the general protection
fault which was reported, amd64 reacts this way to the non-canonical
address. It is theoretically possible that some random memory corruption
occured, but I tend to believe that hardware bit-flipping took place.

>     pv_gen = 1012, pat_mode = 6}, wire_count = 0, busy_lock = 1, 
>   hold_count = 0, flags = 0, aflags = 1 '\001', oflags = 0 '\0', 
>   queue = 1 '\001', psind = 0 '\0', segind = 7 '\a', order = 13 '\r', 
>   pool = 0 '\0', act_count = 5 '\005', valid = 255 '?', dirty = 255 '?'}
> 
> It would have been reproducible except that the panic truncated
> the program 'z' (which caused the panic) to 0 bytes and took the
> source code I was writing.  Neither 'z' nor the source code appeared
> in /usr/lost+found.  Unfortunately, the source code was a quickly
> written Fortran program with obviously a programming error, and I
> doubt that I'll be able to replicate the program.
> 
> -- 
> Steve



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150124132005.GU42409>