From owner-freebsd-stable@FreeBSD.ORG Sat Sep 14 13:41:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F7F5719 for ; Sat, 14 Sep 2013 13:41:28 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CE9A027CD for ; Sat, 14 Sep 2013 13:41:27 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 9F9A94FEF; Sat, 14 Sep 2013 13:41:26 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 1E3654A0C9; Sat, 14 Sep 2013 15:40:44 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Patrick Lamaiziere Subject: Reproducible panic in 9.2-RC4 (was: Re: (9.2) panic under disk load (gam_server / knlist_remove_kq)) References: <20130714115953.1afd6e90@davenulle.org> Date: Sat, 14 Sep 2013 15:40:43 +0200 In-Reply-To: <20130714115953.1afd6e90@davenulle.org> (Patrick Lamaiziere's message of "Sun, 14 Jul 2013 11:59:53 +0200") Message-ID: <86vc23ldwk.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 13:41:28 -0000 Patrick Lamaiziere 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 =3D 2; apic id =3D 02 fault virtual address =3D 0x368 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff808f920d stack pointer =3D 0x28:0xffffff825217c770 frame pointer =3D 0x28:0xffffff825217c7e0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1707 (gvfsd-trash) trap number =3D 12 panic: page fault cpuid =3D 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=3D) at pcpu.h:234 #1 0xffffffff8090d486 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff8090d987 in panic (fmt=3D0x1
) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff80cf2110 in trap_fatal (frame=3D0xc, eva=3D) at /usr/src/sys/amd64/amd64/trap.c:879 #4 0xffffffff80cf2471 in trap_pfault (frame=3D0xffffff825217c6c0, usermode= =3D0) at /usr/src/sys/amd64/amd64/trap.c:795 #5 0xffffffff80cf2a24 in trap (frame=3D0xffffff825217c6c0) 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=3D0xfffffe01068564b8,=20 tid=3D18446741882246426624, opts=3D,=20 file=3D, line=3D0) at /usr/src/sys/kern/kern_mutex= .c:388 #8 0xffffffff809ab5e3 in filt_vfsvnode (kn=3D0xfffffe0136e11d00, hint=3D0) at /usr/src/sys/kern/vfs_subr.c:4600 #9 0xffffffff808d1d46 in kqueue_register (kq=3D0xfffffe001a73ec00,=20 kev=3D0xffffff825217c980, td=3D0xfffffe01c29e7000, waitok=3D1) at /usr/src/sys/kern/kern_event.c:1136 #10 0xffffffff808d2396 in kern_kevent (td=3D0xfffffe01c29e7000,=20 fd=3D, nchanges=3D7, nevents=3D1, k_ops=3D0xffffff= 825217caa0,=20 timeout=3D0x0) at /usr/src/sys/kern/kern_event.c:847 #11 0xffffffff808d2ed0 in sys_kevent (td=3D0xfffffe01c29e7000,=20 uap=3D0xffffff825217cbb0) at /usr/src/sys/kern/kern_event.c:768 #12 0xffffffff80cf18ba in amd64_syscall (td=3D0xfffffe01c29e7000, traced=3D= 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 --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no