Date: Tue, 15 Oct 2013 12:26:01 +0200 From: Davide Italiano <davide@freebsd.org> To: mexas@bris.ac.uk Cc: freebsd-current <freebsd-current@freebsd.org>, freebsd-ia64@freebsd.org Subject: Re: panic: wrong page state m 0xe00000027a9adb40 + savecore deadlock Message-ID: <CACYV=-GE%2BSUR_RrXfhaH9FekQ3QC6DuYuSpcdhAok0kH0uBShQ@mail.gmail.com> In-Reply-To: <201310150843.r9F8ho1c043235@mech-cluster241.men.bris.ac.uk> References: <CACYV=-E3GBEAQpo92m4kzQiJh-6LB34N=g5Y4AvryzoV%2BTJUJQ@mail.gmail.com> <201310150843.r9F8ho1c043235@mech-cluster241.men.bris.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 15, 2013 at 10:43 AM, Anton Shterenlikht <mexas@bris.ac.uk> wrote:
> Anyway, savecore eventually deadlocks:
>
> panic: deadlkres: possible deadlock detected for 0xe0000000127b7b00, blocked for 901401 ticks
>
[trim]
>
> Tracing command savecore pid 805 tid 100079 td 0xe0000000127b7b00
> cpu_switch(0xe0000000127b7b00, 0xe000000011178900, 0xe000000012402fc0, 0x9ffc0000005e7e80) at cpu_switch+0xd0
> sched_switch(0xe0000000127b7b00, 0xe000000011178900, 0x9ffc000000f15698, 0x9ffc000000f15680) at sched_switch+0x890
> mi_switch(0x103, 0x0, 0xe0000000127b7b00, 0x9ffc00000062d1f0) at mi_switch+0x3f0
> turnstile_wait(0xe000000012402fc0, 0xe000000012400480, 0x0, 0x9ffc000000dcb698) at turnstile_wait+0x960
> __mtx_lock_sleep(0x9ffc0000010f9998, 0xe0000000127b7b00, 0xe000000012402fc0, 0x9ffc000000dc0558, 0x742) at __mtx_lock_sleep+0x2f0
> __mtx_lock_flags(0x9ffc0000010f9980, 0x0, 0x9ffc000000dd4a90, 0x742) at __mtx_lock_flags+0x1e0
> vfs_vmio_release(0xa00000009ebe72f0, 0xe00000027ed2ab70, 0x3, 0xa00000009ebe736c, 0xa00000009ebe7498, 0xa00000009ebe72f8, 0x9ffc000000dd4a90, 0x9ffc0000010f9680) at vfs_vmio_release+0x290
> getnewbuf(0xe0000000127f4ec0, 0x0, 0x0, 0x8000, 0xa00000009ebe99a8, 0x0, 0x9ffc0000010f0798, 0xa00000009ebe72f0) at getnewbuf+0x7e0
> getblk(0xe0000000127f4ec0, 0x4cbaa, 0x8000, 0x0, 0x0, 0x0, 0x0, 0x0) at getblk+0xee0
> ffs_balloc_ufs2(0xe0000000127f4ec0, 0x4cbaa, 0xa0000000c60ba000, 0xe000000011165a00, 0x7f050000, 0xa00000009dd79160) at ffs_balloc_ufs2+0x2950
> ffs_write(0xa00000009dd79248, 0x3000, 0x265d50000) at ffs_write+0x5c0
> VOP_WRITE_APV(0x9ffc000000e94ac0, 0xa00000009dd79248, 0x0, 0x0) at VOP_WRITE_APV+0x330
> vn_write(0xe0000000129ae820, 0xa00000009dd79360, 0xe000000011165a00, 0x0, 0xe0000000129ae830, 0xe0000000127f4ec0) at vn_write+0x450
> vn_io_fault(0xe0000000129ae820, 0xa00000009dd79360, 0xe000000011165a00, 0x0, 0xe0000000127b7b00) at vn_io_fault+0x330
> dofilewrite(0xe0000000127b7b00, 0x7, 0xe0000000129ae820, 0xa00000009dd79360, 0xffffffffffffffff, 0x0) at dofilewrite+0x180
> kern_writev(0xe0000000127b7b00, 0x7, 0xa00000009dd79360) at kern_writev+0xa0
> sys_write(0xe0000000127b7b00, 0xa00000009dd794e8, 0x9ffc000000abac80, 0x48d) at sys_write+0x100
> syscall(0xe0000000129d04a0, 0x140857000, 0x8000, 0xe0000000127b7b00, 0x0, 0x0, 0x9ffc000000ab7280, 0x8) at syscall+0x5e0
> --More--
I'm not commenting on the first panic you got -- but on the deadlock
reported by DEADLKRES. I think that's the vm_page lock.
You can run kgdb /boot/${KERNEL}/kernel where ${KERNEL} is the incrimined one
then l *vfs_vmio_release+0x290
to get the exact point where it fails.
I'm unsure here because 'show alllocks' and 'show locks' outputs are
empty -- are you building your kernel with WITNESS etc..?
Thanks,
--
Davide
"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACYV=-GE%2BSUR_RrXfhaH9FekQ3QC6DuYuSpcdhAok0kH0uBShQ>