Date: Sat, 14 Sep 2013 15:40:43 +0200 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Patrick Lamaiziere <patfbsd@davenulle.org> Cc: freebsd-stable@freebsd.org Subject: Reproducible panic in 9.2-RC4 (was: Re: (9.2) panic under disk load (gam_server / knlist_remove_kq)) Message-ID: <86vc23ldwk.fsf@nine.des.no> In-Reply-To: <20130714115953.1afd6e90@davenulle.org> (Patrick Lamaiziere's message of "Sun, 14 Jul 2013 11:59:53 %2B0200") References: <20130714115953.1afd6e90@davenulle.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Patrick Lamaiziere <patfbsd@davenulle.org> writes:
> I'm seeing a panic while trying to build a poudriere repository.
> [...]
A related panic still occurs in 9.2-RC4. It is 100% reproducible: just
start a poudriere build while Gnome is running. The culprit this time
seems to be gvfsd-trash. Killing it doesn't work, because Gnome will
restart it, but stopping it (pkill -STOP gvfsd-trash) does.
I merged r254024 from stable/9 to see if it would help; it didn't.
I get the following core.txt:
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0x368
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff808f920d
stack pointer = 0x28:0xffffff825217c770
frame pointer = 0x28:0xffffff825217c7e0
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 = 1707 (gvfsd-trash)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0xffffffff80947986 at kdb_backtrace+0x66
#1 0xffffffff8090d9ae at panic+0x1ce
#2 0xffffffff80cf2110 at trap_fatal+0x290
#3 0xffffffff80cf2471 at trap_pfault+0x211
#4 0xffffffff80cf2a24 at trap+0x344
#5 0xffffffff80cdbd53 at calltrap+0x8
#6 0xffffffff809ab5e3 at filt_vfsvnode+0xf3
#7 0xffffffff808d1d46 at kqueue_register+0x3e6
#8 0xffffffff808d2396 at kern_kevent+0x106
#9 0xffffffff808d2ed0 at sys_kevent+0x90
#10 0xffffffff80cf18ba at amd64_syscall+0x5ea
#11 0xffffffff80cdc037 at Xfast_syscall+0xf7
but gdb gives a slightly different backtrace:
#0 doadump (textdump=<value optimized out>) at pcpu.h:234
#1 0xffffffff8090d486 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:449
#2 0xffffffff8090d987 in panic (fmt=0x1 <Address 0x1 out of bounds>)
at /usr/src/sys/kern/kern_shutdown.c:637
#3 0xffffffff80cf2110 in trap_fatal (frame=0xc, eva=<value optimized out>)
at /usr/src/sys/amd64/amd64/trap.c:879
#4 0xffffffff80cf2471 in trap_pfault (frame=0xffffff825217c6c0, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:795
#5 0xffffffff80cf2a24 in trap (frame=0xffffff825217c6c0)
at /usr/src/sys/amd64/amd64/trap.c:463
#6 0xffffffff80cdbd53 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:232
#7 0xffffffff808f920d in _mtx_lock_sleep (m=0xfffffe01068564b8,
tid=18446741882246426624, opts=<value optimized out>,
file=<value optimized out>, line=0) at /usr/src/sys/kern/kern_mutex.c:388
#8 0xffffffff809ab5e3 in filt_vfsvnode (kn=0xfffffe0136e11d00, hint=0)
at /usr/src/sys/kern/vfs_subr.c:4600
#9 0xffffffff808d1d46 in kqueue_register (kq=0xfffffe001a73ec00,
kev=0xffffff825217c980, td=0xfffffe01c29e7000, waitok=1)
at /usr/src/sys/kern/kern_event.c:1136
#10 0xffffffff808d2396 in kern_kevent (td=0xfffffe01c29e7000,
fd=<value optimized out>, nchanges=7, nevents=1, k_ops=0xffffff825217caa0,
timeout=0x0) at /usr/src/sys/kern/kern_event.c:847
#11 0xffffffff808d2ed0 in sys_kevent (td=0xfffffe01c29e7000,
uap=0xffffff825217cbb0) at /usr/src/sys/kern/kern_event.c:768
#12 0xffffffff80cf18ba in amd64_syscall (td=0xfffffe01c29e7000, traced=0)
at subr_syscall.c:135
#13 0xffffffff80cdc037 in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:391
#14 0x0000000802e84d8c in ?? ()
Previous frame inner to this frame (corrupt stack?)
This is GENERIC built from the latest releng/9.2 sources with no other
modifications than the addition of r254024.
With the stock kernel (from freebsd-update), I get
#0 0xffffffff80947986 at kdb_backtrace+0x66
#1 0xffffffff8090d9ae at panic+0x1ce
#2 0xffffffff80cf20d0 at trap_fatal+0x290
#3 0xffffffff80cf2431 at trap_pfault+0x211
#4 0xffffffff80cf29e4 at trap+0x344
#5 0xffffffff80cdbd13 at calltrap+0x8
#6 0xffffffff808d2396 at kern_kevent+0x106
#7 0xffffffff808d2ed0 at sys_kevent+0x90
#8 0xffffffff80cf187a at amd64_syscall+0x5ea
#9 0xffffffff80cdbff7 at Xfast_syscall+0xf7
but kgdb is useless - it doesn't see past calltrap().
DES
--
Dag-Erling Smørgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86vc23ldwk.fsf>