ia64/183227: panic: uma_zfree: Freeing to non free bucket index; in r262690

[Anton Shterenlikht]

Hi Marcel

Just to let you know that the panic
ia64/183227: panic: uma_zfree: Freeing to non free bucket index
( http://www.freebsd.org/cgi/query-pr.cgi?pr=183227 )

for which you provided a fix,
just appeared again in r262690.
I updated the PR.

I think it might be related to
http://www.freebsd.org/cgi/query-pr.cgi?pr=187816
because both happened while building the same
2 moc related ports.

Thanks

Anton

[Anton Shterenlikht]

Post by Anton Shterenlikht
Hi Marcel
=20
Just to let you know that the panic
ia64/183227: panic: uma_zfree: Freeing to non free bucket index
( http://www.freebsd.org/cgi/query-pr.cgi?pr=3D183227 )
=20
for which you provided a fix,
just appeared again in r262690.
I updated the PR.
=20
I think it might be related to
http://www.freebsd.org/cgi/query-pr.cgi?pr=3D187816
because both happened while building the same
2 moc related ports.
=20

Thanks,
I ran into it myself. I'm running with the attached patch.

Ok, I'll give it a go.

Thanks as always!

Anton

[Marcel Moolenaar]

Post by Anton Shterenlikht
Hi Marcel
Just to let you know that the panic
ia64/183227: panic: uma_zfree: Freeing to non free bucket index
( http://www.freebsd.org/cgi/query-pr.cgi?pr=183227 )
for which you provided a fix,
just appeared again in r262690.
I updated the PR.
I think it might be related to
http://www.freebsd.org/cgi/query-pr.cgi?pr=187816
because both happened while building the same
2 moc related ports.

Thanks,

I ran into it myself. I'm running with the attached patch.
It makes PTE updates more atomic. It appears that this is
really what's causing some of the "weird" panics.

Note that I have still observed page faults, even when
running with the patch. I can easily reproduce it when
trying to run X. The key is that X actually doesn't run
and gets restarted continuously. And it's that that
triggers the panic. Such panic looks like:

#13 0x9ffc000000a47bb0 in trap (vector=<value optimized out>, tf=0xa0000000be813000) at ../../../ia64/ia64/trap.c:562
#14 0x9ffc000000008a00 in ivt_Data_TLB ()
#15 0x9ffc0000009b9c11 in uma_zalloc_arg (zone=0x0, udata=0x0, flags=0) at ../../../vm/uma_core.c:2152
#16 0x9ffc0000005b5e80 in malloc (size=<value optimized out>, mtp=0x9ffc000000d40598, flags=2) at uma.h:336
#17 0x9ffc0000006825f0 in cloneuio (uiop=0xa0000000be813360) at ../../../kern/subr_uio.c:384
#18 0x9ffc0000007520b0 in vn_io_fault (fp=0xe000000015b17450, uio=0xa0000000be813360, active_cred=0xe000000014fc8400, flags=0, td=0xe000000012a7e4b0) at ../../../kern/vfs_vnops.c:969
#19 0x9ffc0000006985a0 in dofilewrite (td=0xe000000012a7e4b0, fd=2, fp=0xe000000015b17450, auio=0xa0000000be813360, offset=-1, flags=0) at file.h:307
#20 0x9ffc000000698a50 in kern_writev (td=0xe000000012a7e4b0, fd=2, auio=0xa0000000be813360) at ../../../kern/sys_generic.c:467
#21 0x9ffc000000698d10 in sys_write (td=0xe000000012a7e4b0, uap=0xa0000000be8134e8) at ../../../kern/sys_generic.c:382
#22 0x9ffc000000a46bd0 in syscall (tf=<value optimized out>) at subr_syscall.c:133

I've added or revived KTR tracing to help get a clear
picture of the events...

FYI,