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 =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<value optimized out>) 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 <Address 0x1 out of bounds>)
at /usr/src/sys/kern/kern_shutdown.c:637
#3 0xffffffff80cf2110 in trap_fatal (frame=3D0xc, eva=3D<value optimized o=
ut>)
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<value optimized out>,=20
file=3D<value optimized out>, 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<value optimized out>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86vc23ldwk.fsf>