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

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

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.