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: Mon, 18 Jun 2018 01:28:16 +0300

 Hi,
 
 Thank you for prompt response. Rebuild the kernel and here is what I've got:
 
 0xc011e20e in maybe_dump (howto=260) at ../../../../arch/i386/i386/machdep.c:789
 789     ../../../../arch/i386/i386/machdep.c: No such file or directory.
 #0  0xc011e20e 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  0xc08887a2 in vpanic (fmt=fmt@entry=0xc0be8f13 "trap",
 ap=ap@entry=0xdc161b38 "\300\033\026\334\300\033\026\334\001") at
 ../../../../kern/subr_prf.c:342
 #3  0xc088882c in panic (fmt=fmt@entry=0xc0be8f13 "trap") at
 ../../../../kern/subr_prf.c:258
 #4  0xc012091f in trap (frame=0xdc161bc0) at
 ../../../../arch/i386/i386/trap.c:325
 #5  0xc0117268 in alltraps ()
 #6  0xdc161bc0 in ?? ()
 #7  0xc085141b in mutex_oncpu (owner=4294967280) at
 ../../../../kern/kern_mutex.c:551
 #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
 #11 via_dma_blit (dev=dev@entry=0xc3652400,
 data=data@entry=0xdc161eac, file_priv=file_priv@entry=0xc3647d2c) at
 ../../../../external/bsd/drm/dist/bsd-core/via_dmablit.c:791
 #12 0xc071c62f in drm_ioctl (kdev=46080, cmd=3223872590,
 data=0xdc161eac, flags=67, p=0xc4784800) at
 ../../../../external/bsd/drm/dist/bsd-core/drm_drv.c:1059
 #13 0xc087acdf in cdev_ioctl (dev=46080, cmd=3223872590,
 data=0xdc161eac, flag=67, l=0xc4784800) at
 ../../../../kern/subr_devsw.c:938
 #14 0xc08e3326 in spec_ioctl (v=0xdc161d9c) at
 ../../../../miscfs/specfs/spec_vnops.c:891
 #15 0xc08db97c in VOP_IOCTL (vp=vp@entry=0xc3cc5058,
 command=command@entry=3223872590, data=data@entry=0xdc161eac,
 fflag=67, cred=0xc459e540) at ../../../../kern/vnode_if.c:610
 #16 0xc08d50ce in vn_ioctl (fp=0xc3dbcb00, com=3223872590,
 data=0xdc161eac) at ../../../../kern/vfs_vnops.c:768
 #17 0xc0891994 in sys_ioctl (l=0xc4784800, uap=0xdc161f68,
 retval=0xdc161f60) at ../../../../kern/sys_generic.c:671
 #18 0xc01474c1 in sy_call (rval=0xdc161f60, uap=0xdc161f68,
 l=0xc4784800, sy=0xc0e26398 <sysent+1080>) at
 ../../../../sys/syscallvar.h:65
 #19 sy_invoke (code=54, rval=0xdc161f60, uap=0xdc161f68, l=0xc4784800,
 sy=0xc0e26398 <sysent+1080>) at ../../../../sys/syscallvar.h:94
 #20 syscall (frame=0xdc161fa8) at ../../../../arch/x86/x86/syscall.c:144
 #21 0xc010063d in Xsyscall ()
 #22 0xdc161fa8 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            0xdc161ae0       0xdc161ae0
 ebp            0xdc161af8       0xdc161af8
 esi            0x0      0
 edi            0xdc161b38       -602531016
 eip            0xc011e20e       0xc011e20e <cpu_reboot+370>
 ..........
 
 (gdb) frame 9
 #9  0xc0722bee in via_dmablit_grab_slot (engine=1, blitq=0xc370ed78)
 at ../../../../external/bsd/drm/dist/bsd-core/via_dmablit.c:670
 670     ../../../../external/bsd/drm/dist/bsd-core/via_dmablit.c: No
 such file or directory.
 (gdb) print blitq->dev
 $26 = (struct drm_device *) 0xc3652400
 (gdb) print blitq->cur_blit_handle
 $27 = 0
 (gdb) print blitq->done_blit_handle
 $28 = 0
 (gdb) print blitq->serviced
 $29 = 0
 (gdb) print blitq->head
 $30 = 0
 (gdb) print blitq->cur
 $31 = 0
 (gdb) print blitq->num_free
 $32 = 7
 (gdb) print blitq->num_outstanding
 $33 = 0
 (gdb) print blitq->end
 $34 = 0
 (gdb) print blitq->aborting
 $35 = 0
 (gdb) print blitq->is_active
 $36 = 0
 (gdb) print blitq->blits
 $37 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
 (gdb) print blitq->blit_lock
 $38 = {u = {mtxa_owner = 4294967280}}
 (gdb) print blitq->blit_queue
 $39 = {0, 0, 0, 0, 0, 0, 0, 0}
 (gdb) print blitq->busy_queue
 $40 = 0
 (gdb) print blitq->wq
 $41 = (struct workqueue *) 0xc3746340
 (gdb) print blitq->work
 $42 = {wk_dummy = 0x0}
 (gdb) print blitq->poll_timer
 $43 = {_c_store = {0x0, 0x0, 0x0, 0x0, 0xc0efe820 <callout_cpu0>, 0x0,
 0x1, 0x11deeba1, 0x0, 0x0}}
 
 Is there anything more I can provide? Thank you.
 
 Regards,
 Andrius V
 
 On Fri, Jun 15, 2018 at 12:00 AM, matthew green <mrg%eterna.com.au@localhost> wrote:
 > The following reply was made to PR port-i386/53364; it has been noted by GNATS.
 >
 > From: matthew green <mrg%eterna.com.au@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 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: Fri, 15 Jun 2018 06:58:13 +1000
 >
 >  > trap type 6 code 0 eip 0xc08486e6 cs 0x8 eflags 0x13286 cr2 0xfffffffc i=
 >  level 0 esp 0xdbde5c60
 >
 >  -> cr2 0xfffffffc
 >
 >  this is a pointer of -4 that faulted.  i wonder if something
 >  is usingo container_of() on a NULL pointer, but i don't see
 >  anything that would do this in viadrm code.
 >
 >  > mutex_oncpu.part.0(c37af114,0,ea000000,0,c0e2cda4,dbde5c68,0,0,dbde5c4c,=
 >  c01386f6) at netbsd:mutex_oncpu.part.0+0x6
 >  > mutex_vector_enter(c3641dc4,200000,c3632000,c3588400,dbde5c8c,c0716e3c,1=
 >  ,dee80000,200000,dbde5c9c) at netbsd:mutex_vector_enter+0x98
 >  > via_dma_blit(c3588400,dbde5eac,c4430134,9000,0,1140010,db55c000,c2f379e4=
 >  ,1,4e) at netbsd:via_dma_blit+0x58
 >  [ ... ]
 >  > #7  0xc0848813 in mutex_vector_enter ()
 >  > #8  0xc071a7be in via_dma_blit ()
 >  > #9  0xc07141ff in drm_ioctl ()
 >
 >  can you build a kernel with makeoptions DEBUG=3D"-g" and then inspect
 >  the "blitq" variable in via_dma_blit()?
 >
 >  thanks.
 >
 >
 >  .mrg.
 >
 
 On Thu, Jun 14, 2018 at 11:58 PM, matthew green <mrg%eterna.com.au@localhost> wrote:
 >> trap type 6 code 0 eip 0xc08486e6 cs 0x8 eflags 0x13286 cr2 0xfffffffc ilevel 0 esp 0xdbde5c60
 >
 > -> cr2 0xfffffffc
 >
 > this is a pointer of -4 that faulted.  i wonder if something
 > is usingo container_of() on a NULL pointer, but i don't see
 > anything that would do this in viadrm code.
 >
 >> mutex_oncpu.part.0(c37af114,0,ea000000,0,c0e2cda4,dbde5c68,0,0,dbde5c4c,c01386f6) at netbsd:mutex_oncpu.part.0+0x6
 >> mutex_vector_enter(c3641dc4,200000,c3632000,c3588400,dbde5c8c,c0716e3c,1,dee80000,200000,dbde5c9c) at netbsd:mutex_vector_enter+0x98
 >> via_dma_blit(c3588400,dbde5eac,c4430134,9000,0,1140010,db55c000,c2f379e4,1,4e) at netbsd:via_dma_blit+0x58
 > [ ... ]
 >> #7  0xc0848813 in mutex_vector_enter ()
 >> #8  0xc071a7be in via_dma_blit ()
 >> #9  0xc07141ff in drm_ioctl ()
 >
 > can you build a kernel with makeoptions DEBUG="-g" and then inspect
 > the "blitq" variable in via_dma_blit()?
 >
 > thanks.
 >
 >
 > .mrg.