9.2 + ZFS + i386 = panic: pmap_enter: attempted pmap_enter on 4MB page

[Konstantin Belousov]

On Wed, Oct 16, 2013 at 04:58:47PM -0400, J David wrote:
> OK, that didn't take long:
> 
> Tracing pid 3153 tid 100432 td 0x885d28d0
> kdb_enter(8111d67f,8111d67f,811736e8,bf7511c0,80a9c47f,...) at
> kdb_enter+0x3d/frame 0xbf751170
> panic(811736e8,0,811733cf,dbf,81479a24,...) at panic+0x1dc/frame 0xbf7511b4
> pmap_enter(81487c78,88d92000,7,82fab0c8,7,...) at
> pmap_enter+0x6cc/frame 0xbf751200
> vm_fault_hold(81feb000,88d92000,1,0,0,...) at
> vm_fault_hold+0x1b41/frame 0xbf751368
> vm_fault(81feb000,88d92000,1,0,bf7513f4,...) at vm_fault+0x82/frame 0xbf751390
> trap_pfault(88d92334,81fed780,246,81feca80,88271b80,...) at
> trap_pfault+0x21e/frame 0xbf751408
> trap(bf751558) at trap+0x58c/frame 0xbf75154c
> calltrap() at calltrap+0x6/frame 0xbf75154c
> --- trap 0xc, eip = 0x80afbc7d, esp = 0xbf751598, ebp = 0xbf7515dc ---
> witness_checkorder(81fed988,9,81156ee6,9f9,0,...) at
> witness_checkorder+0x34d/frame 0xbf7515dc
> _mtx_lock_flags(81fed988,0,81156ee6,9f9,80a98adb,...) at
> _mtx_lock_flags+0x75/frame 0xbf75160c
> uma_zfree_arg(81fecd80,8945b800,88c5a9fc,ffffffff,0,...) at
> uma_zfree_arg+0x54/frame 0xbf751648
> free(8945b800,818dc100,bf7516e8,817f24a9,8945b800,...) at
> free+0xb6/frame 0xbf751678
> zfs_kmem_free(8945b800,124,892f71e0,0,0,...) at
> zfs_kmem_free+0x19/frame 0xbf751688
> zap_lockdir(88452400,115,0,0,1,...) at zap_lockdir+0x359/frame 0xbf7516e8
> zap_lookup_norm(88452400,115,0,bf7518b8,8,...) at
> zap_lookup_norm+0x49/frame 0xbf75172c
> zap_lookup(88452400,115,0,bf7518b8,8,...) at zap_lookup+0x69/frame 0xbf751768
> zfs_dirent_lock(bf751830,88a5b0fc,bf7518b8,bf75182c,6,...) at
> zfs_dirent_lock+0x4e9/frame 0xbf7517e8
> zfs_dirlook(88a5b0fc,bf7518b8,bf751bbc,0,0,...) at
> zfs_dirlook+0x1bb/frame 0xbf751848
> zfs_lookup(bf751bbc,bf751bd0,0,89eee080,0,...) at
> zfs_lookup+0x288/frame 0xbf75189c
> zfs_freebsd_lookup(bf751a18,8117a717,bf7519e4,80b3ead8,88d92328,...)
> at zfs_freebsd_lookup+0x6c/frame 0xbf7519c8
> VOP_CACHEDLOOKUP_APV(818a3e1c,bf751a18,bf751bd0,0,0,...) at
> VOP_CACHEDLOOKUP_APV+0xca/frame 0xbf7519f8
> vfs_cache_lookup(bf751ab8,8117a697,8114f476,8112db4f,812746d4,...) at
> vfs_cache_lookup+0xec/frame 0xbf751a40
> VOP_LOOKUP_APV(818a3e1c,bf751ab8,bf751bd0,33a,885d28d0,...) at
> VOP_LOOKUP_APV+0xca/frame 0xbf751a70
> lookup(bf751b90,8112cf73,106,cc,8,...) at lookup+0x646/frame 0xbf751ae0
> namei(bf751b90,89ed5904,885d28d0,bf751c18,0,...) at namei+0x591/frame 0xbf751b68
> kern_accessat(885d28d0,ffffff9c,280ff800,0,0,0) at
> kern_accessat+0xdd/frame 0xbf751c20
> sys_access(885d28d0,bf751cc8,81174954,8112194d,8111ddc0,...) at
> sys_access+0x39/frame 0xbf751c40
> syscall(bf751d08) at syscall+0x2da/frame 0xbf751cfc
> Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xbf751cfc
> --- syscall (33, FreeBSD ELF32, sys_access), eip = 0x280f0ec7, esp =
> 0x7fbfc4ec, ebp = 0x7fbfc510 ---

As I said you before, obtain the core and get backtrace from kgdb.
I want to see both ddb and kgdb backtraces, the trap from the guts of
witness means that somebody passed incorrect pointer in the kernel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20131017/daf875d1/attachment.sig>