| From | Sent On | Attachments |
|---|---|---|
| Juergen Unger | Jul 27, 2009 12:24 am | |
| O. Hartmann | Jul 27, 2009 12:58 pm | |
| Juergen Unger | Jul 27, 2009 2:33 pm | |
| Andriy Gapon | Jul 28, 2009 2:50 am | |
| Pawel Jakub Dawidek | Jul 29, 2009 1:47 am | |
| Thomas Backman | Jul 29, 2009 3:31 am | |
| Andriy Gapon | Jul 29, 2009 4:21 am | |
| Andriy Gapon | Jul 29, 2009 4:41 am | |
| Thomas Backman | Jul 29, 2009 5:45 am | |
| Andriy Gapon | Jul 29, 2009 6:03 am | |
| Thomas Backman | Jul 29, 2009 6:23 am | |
| Andriy Gapon | Jul 29, 2009 6:45 am | |
| Thomas Backman | Jul 29, 2009 6:52 am | |
| Andriy Gapon | Jul 29, 2009 6:55 am | |
| Thomas Backman | Jul 29, 2009 7:10 am | |
| Andriy Gapon | Jul 29, 2009 7:35 am | |
| Andriy Gapon | Jul 29, 2009 9:01 am | |
| Thomas Backman | Jul 29, 2009 9:10 am | |
| Thomas Backman | Jul 29, 2009 10:13 am | |
| Andriy Gapon | Jul 29, 2009 10:17 am | |
| Thomas Backman | Jul 29, 2009 11:03 am | |
| Thomas Backman | Jul 29, 2009 1:14 pm | |
| Pawel Jakub Dawidek | Jul 29, 2009 2:17 pm | |
| Thomas Backman | Jul 30, 2009 12:04 am | |
| Andriy Gapon | Jul 30, 2009 5:11 am | |
| Thomas Backman | Jul 30, 2009 5:51 am | |
| Andriy Gapon | Jul 30, 2009 6:13 am | |
| Thomas Backman | Jul 30, 2009 6:31 am | |
| Andriy Gapon | Jul 30, 2009 6:34 am | |
| Andriy Gapon | Jul 30, 2009 7:24 am | |
| Thomas Backman | Jul 30, 2009 7:39 am | |
| Andriy Gapon | Jul 30, 2009 7:45 am | |
| Andriy Gapon | Jul 30, 2009 7:48 am | |
| Thomas Backman | Jul 30, 2009 8:25 am | |
| Andriy Gapon | Jul 30, 2009 8:39 am | |
| Thomas Backman | Jul 30, 2009 9:41 am | |
| Thomas Backman | Jul 30, 2009 11:29 am | |
| Andriy Gapon | Jul 30, 2009 11:41 am | |
| Thomas Backman | Jul 31, 2009 2:04 am | |
| James R. Van Artsdalen | Jul 31, 2009 4:44 am | |
| Thomas Backman | Jul 31, 2009 5:26 am | |
| Thomas Backman | Jul 31, 2009 10:09 am | |
| Tim Kientzle | Aug 1, 2009 10:11 am | |
| Juergen Unger | Aug 2, 2009 2:26 am | |
| Pawel Jakub Dawidek | Aug 2, 2009 2:29 am | |
| Juergen Unger | Aug 3, 2009 1:32 pm | |
| Pawel Jakub Dawidek | Aug 4, 2009 12:33 am | |
| Juergen Unger | Aug 4, 2009 12:53 am | |
| Pawel Jakub Dawidek | Aug 4, 2009 2:49 am | |
| Juergen Unger | Aug 4, 2009 2:56 am | |
| Pawel Jakub Dawidek | Aug 4, 2009 12:50 pm | |
| Thomas Backman | Aug 4, 2009 1:10 pm | |
| Pawel Jakub Dawidek | Aug 4, 2009 1:25 pm | |
| Pawel Jakub Dawidek | Aug 4, 2009 11:49 pm | |
| Thomas Backman | Aug 5, 2009 12:08 am | |
| Thomas Backman | Aug 5, 2009 12:20 am | |
| Pawel Jakub Dawidek | Aug 5, 2009 2:37 am | |
| Thomas Backman | Aug 5, 2009 3:36 am | |
| Thomas Backman | Aug 5, 2009 5:06 am | |
| Pawel Jakub Dawidek | Aug 6, 2009 10:44 pm |
| Subject: | Re: zfs: Fatal trap 12: page fault while in kernel mode | |
|---|---|---|
| From: | Thomas Backman (sere...@exscape.org) | |
| Date: | Jul 29, 2009 3:31:50 am | |
| List: | org.freebsd.freebsd-current | |
On Jul 29, 2009, at 10:47, Pawel Jakub Dawidek wrote:
On Tue, Jul 28, 2009 at 12:50:26PM +0300, Andriy Gapon wrote:
on 27/07/2009 22:58 O. Hartmann said the following:
Juergen Unger wrote:
[snip]
_sx_xlock(3c,0,874aa28d,70f,8ae9a9f8,...) at _sx_xlock+0x43 dmu_buf_update_user(0,8ae9a9f8,0,0,0,...) at dmu_buf_update_user +0x35 zfs_znode_dmu_fini(8ae9a9f8,874b312d,1114,110b,879ab000,...) at zfs_znode_dmu_f3 zfs_freebsd_reclaim(fcd29c3c,1,0,8ec63754,fcd29c60,...) at zfs_freebsd_reclaim+0 VOP_RECLAIM_APV(874b65a0,fcd29c3c,0,0,8ec637c8,...) at VOP_RECLAIM_APV+0xa5 vgonel(8ec637c8,0,80c77037,386,0,...) at vgonel+0x1a4 vnlru_free(80f2a0f0,0,80c77037,300,3e8,...) at vnlru_free+0x2d5 vnlru_proc(0,fcd29d38,80c652bc,33e,871932a8,...) at vnlru_proc +0x80 fork_exit(8090d960,0,fcd29d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8
[snip]
I see a similar problem on two SMP boxes (is your SMP?), but in my case, it seems not to be ZFS related although I also use ZFS as /home filesystem
In this case this does seem to be caused by ZFS.
From the backtrace we see that _sx_xlock() is called on bogus struct sx pointer
(0x3c) and this is caused by dmu_buf_update_user() called with NULL first argument (dmu_buf_t). Which means that znode_t z_dbuf was NULL - this could have been caught by ASSERT in zfs_znode_dmu_fini if it were enabled.
If you have the crash dump, then it would be interesting to examine znode_t structure ('zp' argument) in zfs_znode_dmu_fini.
P.S. I see that zfs_inactive checks for z_dbuf being NULL and there is the following comment: /* * The fs has been unmounted, or we did a * suspend/resume and this file no longer exists. */ Maybe zfs_freebsd_reclaim should do the same?
Yes, you might be right.
Could you guys, who can reproduce it, try this patch:
OFF TOPIC:
Due to similarities in the backtrace between this and a panic I've
been seeing on exporting after zfs recv (see
http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009105.html
and also
http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009174.html
for a panics-every-time script) I tried this patch. Unfortunately, I
still get the same panic (from vgonel() and up, it's the same, except
for my typo in the linked email.)
Just thought I should point it out. Except for temporary storage
problems when moving my data to ZFS, this panic is the last hurdle in
not using FreeBSD for me. :/
Regards, Thomas
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "free...@freebsd.org"





