Re: port-i386/53364: System crashes soon after X server is started with viadrm driver

[Andrius V <vezhlys%gmail.com@localhost>]

The following reply was made to PR port-i386/53364; it has been noted by GNATS.

From: Andrius V <vezhlys%gmail.com@localhost>
To: matthew green <mrg%eterna.com.au@localhost>
Cc: gnats-bugs%netbsd.org@localhost, port-i386-maintainer%netbsd.org@localhost, 
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: port-i386/53364: System crashes soon after X server is started
 with viadrm driver
Date: Thu, 21 Jun 2018 01:01:18 +0300

 Hi,
 
 With LOCKDEBUG enabled it crashed in a different place:
 
 from dmesg:
 panic: mutex_vector_enter,517: uninitialized lock (lock=0xc375edc4,
 from=c0722a2e)
 
 bt:
 0xc011dfce in maybe_dump (howto=260) at ../../../../arch/i386/i386/machdep.c:789
 789     ../../../../arch/i386/i386/machdep.c: No such file or directory.
 #0  0xc011dfce in maybe_dump (howto=260) at
 ../../../../arch/i386/i386/machdep.c:789
 #1  cpu_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at
 ../../../../arch/i386/i386/machdep.c:810
 #2  0xc088b342 in vpanic (fmt=fmt@entry=0xc0c77808 "%s,%zu:
 uninitialized lock (lock=%p, from=%08x)",
     ap=ap@entry=0xdb74bbcc "\350\327\274\300\005\002") at
 ../../../../kern/subr_prf.c:342
 #3  0xc088b3cc in panic (fmt=fmt@entry=0xc0c77808 "%s,%zu:
 uninitialized lock (lock=%p, from=%08x)") at
 ../../../../kern/subr_prf.c:258
 #4  0xc0884759 in lockdebug_lookup (where=3228707374, lock=0xc375edc4,
 line=517, func=0xc0bcd7e8 <__func__.6248> "mutex_vector_enter")
     at ../../../../kern/subr_lockdebug.c:201
 #5  lockdebug_wantlock (func=0xc0bcd7e8 <__func__.6248>
 "mutex_vector_enter", line=517, lock=0xc375edc4, where=3228707374,
 shared=0)
     at ../../../../kern/subr_lockdebug.c:438
 #6  0xc0851d9c in mutex_vector_enter (mtx=mtx@entry=0xc375edc4) at
 ../../../../kern/kern_mutex.c:517
 #7  0xc0722a2e in via_dmablit_grab_slot (engine=1, blitq=0xc375ed78)
 at ../../../../external/bsd/drm/dist/bsd-core/via_dmablit.c:670
 #8  via_dmablit (xfer=0xdb74beac, dev=0xc36a4400) at
 ../../../../external/bsd/drm/dist/bsd-core/via_dmablit.c:723
 #9  via_dma_blit (dev=dev@entry=0xc36a4400,
 data=data@entry=0xdb74beac, file_priv=file_priv@entry=0xc3efe0d4)
     at ../../../../external/bsd/drm/dist/bsd-core/via_dmablit.c:791
 #10 0xc071c46f in drm_ioctl (kdev=46080, cmd=3223872590,
 data=0xdb74beac, flags=67, p=0xc38a8000)
     at ../../../../external/bsd/drm/dist/bsd-core/drm_drv.c:1059
 #11 0xc087c17f in cdev_ioctl (dev=46080, cmd=3223872590,
 data=0xdb74beac, flag=67, l=0xc38a8000) at
 ../../../../kern/subr_devsw.c:938
 #12 0xc08e5fa6 in spec_ioctl (v=0xdb74bd9c) at
 ../../../../miscfs/specfs/spec_vnops.c:891
 #13 0xc08de5fc in VOP_IOCTL (vp=vp@entry=0xc3de0e38,
 command=command@entry=3223872590, data=data@entry=0xdb74beac,
 fflag=67, cred=0xc461c480)
     at ../../../../kern/vnode_if.c:610
 #14 0xc08d7d4e in vn_ioctl (fp=0xc4612400, com=3223872590,
 data=0xdb74beac) at ../../../../kern/vfs_vnops.c:768
 #15 0xc0894614 in sys_ioctl (l=0xc38a8000, uap=0xdb74bf68,
 retval=0xdb74bf60) at ../../../../kern/sys_generic.c:671
 ---Type <return> to continue, or q <return> to quit---
 #16 0xc0147225 in sy_call (rval=0xdb74bf60, uap=0xdb74bf68,
 l=0xc38a8000, sy=0xc0e2a358 <sysent+1080>) at
 ../../../../sys/syscallvar.h:65
 #17 sy_invoke (code=54, rval=0xdb74bf60, uap=0xdb74bf68, l=0xc38a8000,
 sy=0xc0e2a358 <sysent+1080>) at ../../../../sys/syscallvar.h:94
 #18 syscall (frame=0xdb74bfa8) at ../../../../arch/x86/x86/syscall.c:144
 #19 0xc010063d in Xsyscall ()
 #20 0xdb74bfa8 in ?? ()
 Backtrace stopped: previous frame inner to this frame (corrupt stack?)
 784     in ../../../../arch/i386/i386/machdep.c
 eax            <unavailable>
 ecx            <unavailable>
 edx            <unavailable>
 ebx            0x104    260
 esp            0xdb74bb74       0xdb74bb74
 ebp            0xdb74bb8c       0xdb74bb8c
 esi            0x8      8
 edi            0xdb74bbcc       -613106740
 eip            0xc011dfce       0xc011dfce <cpu_reboot+370>
 
 P.S. Currently it seems that issue is likely a duplicate of
 kern/48434. For some reason Xorg is starting now properly but fails on
 switch to vt or during shutdown (which tries to do the same I guess).
 
 On Mon, Jun 18, 2018 at 5:21 AM, matthew green <mrg%eterna.com.au@localhost> wrote:
 >> #7  0xc085141b in mutex_oncpu (owner=4294967280) at
 >> ../../../../kern/kern_mutex.c:551
 >
 > i see why the fault occurs:
 >
 > here owner = 0xfffffff0.  that seems bogus because it should
 > be a pointer.  and l_cpu is offset 12 in struct lwp:
 >
 >     413 mutex_oncpu(uintptr_t owner)
 >     [ ... ]
 >     416         lwp_t *l;
 >     [ ... ]
 >     428         l = (lwp_t *)MUTEX_OWNER(owner);
 >     429         ci = l->l_cpu;
 >
 > so that explains the 0xfffffffc fault address.
 >
 > the real question is why is this invalid.  it should be valid.
 >
 >> #8  mutex_vector_enter (mtx=0xc370edc4) at ../../../../kern/kern_mutex.c:560
 >> #9  0xc0722bee in via_dmablit_grab_slot (engine=1, blitq=0xc370ed78)
 >> at ../../../../external/bsd/drm/dist/bsd-core/via_dmablit.c:670
 >> #10 via_dmablit (xfer=0xdc161eac, dev=0xc3652400) at
 >> ../../../../external/bsd/drm/dist/bsd-core/via_dmablit.c:723
 > [ ... ]
 >> (gdb) print blitq->dev
 >> $26 = (struct drm_device *) 0xc3652400
 >> (gdb) print blitq->cur_blit_handle
 >> $27 = 0
 >> (gdb) print blitq->done_blit_handle
 >
 > BTW, you could probably use "print *blitq" here, to view the whole
 > structure.  if you "set print pretty" first, it will be readable ;)
 >
 >> Is there anything more I can provide? Thank you.
 >
 > at this point, i suspect that we have a locking issue and the
 > first step here is normally to build a kernel with LOCKDEBUG
 > enabled and see what happens.  it hopefully will crash earlier
 > and with more information about what is wrong.
 >
 > thanks!
 >
 >
 > .mrg.