Yup, its almost certain that this is the bug you are hitting.
-Mark
Alan Hargreaves wrote:
I know, bad form replying to myself, but I am wondering if it might be
related to
6438702 error handling in zfs_getpage() can trigger "page not
locked"
Which is marked "fix in progress" with a target of the current build.
alan.
Alan Hargreaves wrote:
Folks, before I start delving too deeply into this crashdump, has
anyone seen anything like it?
The background is that I'm running a non-debug open build of b49 and
was in the process of running the "zoneadm -z redlx install ...".
After a bit, the machine panics, initially looking at the crashdump,
I'm down to 88mb free (out of a gig) and see the following stack.
fffffe8000de7800 page_unlock+0x3b(180218720)
fffffe8000de78d0 zfs_getpage+0x236(ffffffff89b84d80, 12000, 2000,
fffffe8000de7a1c, fffffe8000de79b8, 2000, fffffffffbc29b20,
fffffe808180a000, 1,
ffffffff80826dc8)
fffffe8000de7950 fop_getpage+0x52(ffffffff89b84d80, 12000, 2000,
fffffe8000de7a1c, fffffe8000de79b8, 2000, fffffffffbc29b20,
fffffe8081818000, 1,
ffffffff80826dc8)
fffffe8000de7a50 segmap_fault+0x1d6(ffffffff801a6f38,
fffffffffbc29b20, fffffe8081818000, 2000, 0, 1)
fffffe8000de7b30 segmap_getmapflt+0x67a(fffffffffbc29b20,
ffffffff89b84d80, 12000, 2000, 1, 1)
fffffe8000de7bd0 lofi_strategy_task+0x14b(ffffffff959d2400)
fffffe8000de7c60 taskq_thread+0x1a7(ffffffff84453da8)
fffffe8000de7c70 thread_start+8()
%rax = 0x0000000000000000 %r9 = 0x000000000300430e
%rbx = 0x000000000000000e %r10 = 0x0000000000001000
%rcx = 0xfffffe8081819000 %r11 = 0x1ffffffff13709b0
%rdx = 0xfffffe8000de7c80 %r12 = 0x0000000180218720
%rsi = 0x0000000000013000 %r13 = 0xfffffffffbc52160
pse_mutex+0x200
%rdi = 0xfffffffffbc52160 pse_mutex+0x200 %r14 = 0x0000000000004000
%r8 = 0x0000000000000200 %r15 = 0xfffffe8000de79d8
%rip = 0xfffffffffb8474fb page_unlock+0x3b
%rbp = 0xfffffe8000de7800
%rsp = 0xfffffe8000de77e0
%rflags = 0x00010246
id=0 vip=0 vif=0 ac=0 vm=0 rf=1 nt=0 iopl=0x0
status=<of,df,IF,tf,sf,ZF,af,PF,cf>
%cs = 0x0028 %ds = 0x0043 %es = 0x0043
%trapno = 0xe %fs = 0x0000 fsbase = 0xffffffff80000000
%err = 0x0 %gs = 0x01c3 gsbase = 0xfffffffffbc27b70
While the panic string says NULL pointer dereference, it appears that
0x180218720 is not mapped. The dereference looks like the first
dereference in page_unlock(), which looks at pp->p_selock.
I can spend a little time looking at it, but was wondering if anyone
had seen this kind of panic previously?
I have two identical crashdumps created in exactly the same way.
alan.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
