NetBSD Problem Report #53364
From www@NetBSD.org Thu Jun 14 08:18:28 2018
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 076757A1D7
for <gnats-bugs@gnats.NetBSD.org>; Thu, 14 Jun 2018 08:18:28 +0000 (UTC)
Message-Id: <20180614081821.CBAB67A261@mollari.NetBSD.org>
Date: Thu, 14 Jun 2018 08:18:21 +0000 (UTC)
From: vezhlys@gmail.com
Reply-To: vezhlys@gmail.com
To: gnats-bugs@NetBSD.org
Subject: System crashes soon after X server is started with viadrm driver
X-Send-Pr-Version: www-1.0
>Number: 53364
>Category: port-i386
>Synopsis: System crashes soon after X server is started with viadrm driver
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: port-i386-maintainer
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Jun 14 08:20:01 +0000 2018
>Closed-Date: Tue Jul 10 18:03:39 +0000 2018
>Last-Modified: Tue Jul 10 18:03:39 +0000 2018
>Originator: Andrius V
>Release: 8.0 RC1
>Organization:
>Environment:
>Description:
On my VT310-DP motherboard (CN400+VIA VT8237R, UniChrome Pro) I rebuilt the kernel with viadrm driver and started Xorg server (using startx). It starts, you can see graphics environment for few seconds, then system hangs and finally reboots. Crash dump is being generated on next reboot. The issue is not unique to 8 branch. I was facing the same problem on NetBSD 7 as well.
dmesg from crash dump
viadrm0: interrupting at ioapic0 pin 16
uvm_fault(0xc0e8c300, 0xfffff000, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip 0xc08486e6 cs 0x8 eflags 0x13286 cr2 0xfffffffc ilevel 0 esp 0xdbde5c60
curlwp 0xc3fb1800 pid 107 lid 1 lowest kstack 0xdbde42c0
panic: trap
cpu0: Begin traceback...
vpanic(c0bde197,dbde5b38,dbde5bb4,c01201df,c0bde197,dbde5bc0,dbde5bc0,1,dbde42c0,13286) at netbsd:vpanic+0x121
snprintf(c0bde197,dbde5bc0,dbde5bc0,1,dbde42c0,13286,fffffffc,0,dbde5c60,0) at netbsd:snprintf
trap() at netbsd:trap+0xc80
--- trap (number 6) ---
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
drm_ioctl(b400,0,c028644e,dbde5eac,43,c3fb1800,c3fb1800,c028644e,c0e14240,43) at netbsd:drm_ioctl+0x2fc
cdev_ioctl(b400,0,c028644e,dbde5eac,43,c3fb1800,b400,c445a770,c43dc7c0,c445a770) at netbsd:cdev_ioctl+0xbe
spec_ioctl(dbde5d9c,c37af114,c44c6a00,c0bc2dd0,c445a770,c028644e,dbde5eac,43,c43e1480,c028644e) at netbsd:spec_ioctl+0x8b
VOP_IOCTL(c445a770,c028644e,dbde5eac,43,c43e1480,c44589a0,ae800000,c4458aa8,c3764d40,0) at netbsd:VOP_IOCTL+0x3e
vn_ioctl(c43dc7c0,c028644e,dbde5eac,1100000,dbde5f10,c3764d40,dbde5ed0,c081e6aa,28,dbde5eac) at netbsd:vn_ioctl+0x91
sys_ioctl(c3fb1800,dbde5f68,dbde5f60,c3764d40,c3764d40,dbde5f60,dbde5f68,36,0,0) at netbsd:sys_ioctl+0xfc
syscall() at netbsd:syscall+0x1d1
--- syscall (number 54) ---
b42950e7:
cpu0: End traceback...
Type "apropos word" to search for commands related to "word"...
Reading symbols from netbsd.2...(no debugging symbols found)...done.
(gdb) target kvm netbsd.2.core
0xc011dac5 in cpu_reboot ()
From gdb:
#0 0xc011dac5 in cpu_reboot ()
#1 0xc087fa72 in vpanic ()
#2 0xc087fafc in panic ()
#3 0xc01201df in trap ()
#4 0xc0116e48 in alltraps ()
#5 0xdbde5bc0 in end ()
#6 0xc0870010 in cpufreq_register ()
#7 0xc0848813 in mutex_vector_enter ()
#8 0xc071a7be in via_dma_blit ()
#9 0xc07141ff in drm_ioctl ()
#10 0xc08720bf in cdev_ioctl ()
#11 0xc08da506 in spec_ioctl ()
#12 0xc08d2b5c in VOP_IOCTL ()
#13 0xc08cc280 in vn_ioctl ()
#14 0xc0888974 in sys_ioctl ()
#15 0xc0146f41 in syscall ()
#16 0xc010062d in Xsyscall ()
#17 0xdbde5fa8 in end ()
#18 0xba4b00b3 in _KERNEL_OPT_WS_KERNEL_FG ()
#19 0x000000ab in _KERNEL_OPT_WSDISPLAY_SCROLLBACK_LINES ()
#20 0x0025001f in gdt_desc ()
#21 0xba4b001f in _KERNEL_OPT_WS_KERNEL_FG ()
#22 0xc028644e in rtwn_ioctl ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>How-To-Repeat:
Rebuild kernel with viadrm driver.
Boot system with the kernel
startx
>Fix:
>Release-Note:
>Audit-Trail:
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
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.
From: Andrius V <vezhlys@gmail.com>
To: matthew green <mrg@eterna.com.au>
Cc: gnats-bugs@netbsd.org, port-i386-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
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> wrote:
> The following reply was made to PR port-i386/53364; it has been noted by GNATS.
>
> From: matthew green <mrg@eterna.com.au>
> To: gnats-bugs@NetBSD.org
> Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org
> 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> 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.
From: matthew green <mrg@eterna.com.au>
To: Andrius V <vezhlys@gmail.com>
Cc: gnats-bugs@netbsd.org, port-i386-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: re: port-i386/53364: System crashes soon after X server is started with viadrm driver
Date: Mon, 18 Jun 2018 12:21:31 +1000
> #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.
From: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-i386/53364: System crashes soon after X server is started
with viadrm driver
Date: Mon, 18 Jun 2018 06:18:25 +0000
Please try the newer drm via driver.
#viadrmums* at drm?
From: Andrius V <vezhlys@gmail.com>
To: matthew green <mrg@eterna.com.au>
Cc: gnats-bugs@netbsd.org, port-i386-maintainer@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
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> 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.
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-i386/53364: System crashes soon after X server is started
with viadrm driver
Date: Thu, 21 Jun 2018 01:08:00 +0300
--000000000000361486056f1a08c2
Content-Type: text/plain; charset="UTF-8"
Hi,
I have tried viadrmums before, and yes, it works better and pretty stable
compared to viadrm (I wasn't sure which was is more up to date though).
Nevertheless, I believe it may be still useful to find the cause of this
particular bug if it won't take too much effort.
On Mon, Jun 18, 2018 at 9:20 AM, <coypu@sdf.org> wrote:
> The following reply was made to PR port-i386/53364; it has been noted by
GNATS.
>
> From: coypu@sdf.org
> To: gnats-bugs@NetBSD.org
> Cc:
> Subject: Re: port-i386/53364: System crashes soon after X server is
started
> with viadrm driver
> Date: Mon, 18 Jun 2018 06:18:25 +0000
>
> Please try the newer drm via driver.
> #viadrmums* at drm?
>
>
--000000000000361486056f1a08c2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"auto">Hi,<br>
<br>
I have tried viadrmums before, and yes, it works better and pretty stable c=
ompared to viadrm (I wasn't sure which was is more up to date though). =
Nevertheless, I believe it may be=C2=A0still useful to find the cause of t=
his particular bug if it won't take too much effort.<br></div><br>
<br>
On Mon, Jun 18, 2018 at 9:20 AM,=C2=A0 <<a href=3D"mailto:coypu@sdf.org"=
rel=3D"noreferrer noreferrer" target=3D"_blank">coypu@sdf.org</a>> wrot=
e:<br>
> The following reply was made to PR port-i386/53364; it has been noted =
by GNATS.<br>
><br>
> From: <a href=3D"mailto:coypu@sdf.org" rel=3D"noreferrer noreferrer" t=
arget=3D"_blank">coypu@sdf.org</a><br>
> To: gnats-bugs@NetBSD.org<br>
> Cc:<br>
> Subject: Re: port-i386/53364: System crashes soon after X server is st=
arted<br>
>=C2=A0 with viadrm driver<br>
> Date: Mon, 18 Jun 2018 06:18:25 +0000<br>
><br>
>=C2=A0 Please try the newer drm via driver.<br>
>=C2=A0 #viadrmums*=C2=A0 =C2=A0 =C2=A0at drm?<br>
><br>
><br>
<br>
</div>
--000000000000361486056f1a08c2--
From: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-i386/53364: System crashes soon after X server is started
with viadrm driver
Date: Fri, 22 Jun 2018 22:44:44 +0000
Any strong reason to want viadrm?
I am under the impression it is the same driver except not working (and I'd like to delete it)
and using the older, conflicting drm code.
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-i386/53364: System crashes soon after X server is started
with viadrm driver
Date: Sat, 23 Jun 2018 09:59:06 +0300
On Sat, Jun 23, 2018 at 1:50 AM, <coypu@sdf.org> wrote:
> The following reply was made to PR port-i386/53364; it has been noted by GNATS.
>
> From: coypu@sdf.org
> To: gnats-bugs@NetBSD.org
> Cc:
> Subject: Re: port-i386/53364: System crashes soon after X server is started
> with viadrm driver
> Date: Fri, 22 Jun 2018 22:44:44 +0000
>
> Any strong reason to want viadrm?
> I am under the impression it is the same driver except not working (and I'd like to delete it)
> and using the older, conflicting drm code.
>
>
Hi,
No, there is no reason. I was only thinking if the bug itself was
really only viadrm related. Other than that deleting it seems to be a
valid option.
From: matthew green <mrg@eterna.com.au>
To: Andrius V <vezhlys@gmail.com>
Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Subject: re: port-i386/53364: System crashes soon after X server is started with viadrm driver
Date: Mon, 25 Jun 2018 15:06:00 +1000
> No, there is no reason. I was only thinking if the bug itself was
> really only viadrm related. Other than that deleting it seems to be a
> valid option.
if viadrmums works, i think we should probably do that.
.mrg.
From: "Maya Rashish" <maya@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53364 CVS commit: src
Date: Tue, 10 Jul 2018 17:01:44 +0000
Module Name: src
Committed By: maya
Date: Tue Jul 10 17:01:44 UTC 2018
Modified Files:
src/distrib/sets/lists/man: mi
src/distrib/sets/lists/modules: md.i386
src/doc: CHANGES
src/share/man/man4: Makefile drm.4
src/sys/arch/amd64/conf: ALL GENERIC
src/sys/arch/i386/conf: ALL GENERIC
src/sys/external/bsd/drm/conf: files.drm
src/sys/external/bsd/drm/dist/bsd-core: drm_pciids.h
src/sys/external/bsd/drm/dist/scripts: create_lk_drm.sh
create_lk_gpu.sh
src/sys/external/bsd/drm/dist/shared-core: drm_pciids.txt
src/sys/modules: Makefile
Removed Files:
src/sys/external/bsd/drm/dist/bsd-core: via_dmablit.c via_dmablit.h
via_drv.c
src/sys/external/bsd/drm/dist/bsd-core/via: Makefile
src/sys/external/bsd/drm/dist/shared-core: via_3d_reg.h via_dma.c
via_drm.h via_drv.h via_ds.c via_ds.h via_irq.c via_map.c via_mm.c
via_mm.h via_verifier.c via_verifier.h via_video.c
src/sys/modules/viadrm: Makefile viadrm.ioconf
Log Message:
Remove viadrm(4), superseded by viadrmums.
Aside from viadrm using older drm code, it's also dysfunctional right now.
See PR port-i386/53364.
To generate a diff of this commit:
cvs rdiff -u -r1.1595 -r1.1596 src/distrib/sets/lists/man/mi
cvs rdiff -u -r1.78 -r1.79 src/distrib/sets/lists/modules/md.i386
cvs rdiff -u -r1.2406 -r1.2407 src/doc/CHANGES
cvs rdiff -u -r1.656 -r1.657 src/share/man/man4/Makefile
cvs rdiff -u -r1.15 -r1.16 src/share/man/man4/drm.4
cvs rdiff -u -r1.90 -r1.91 src/sys/arch/amd64/conf/ALL
cvs rdiff -u -r1.493 -r1.494 src/sys/arch/amd64/conf/GENERIC
cvs rdiff -u -r1.440 -r1.441 src/sys/arch/i386/conf/ALL
cvs rdiff -u -r1.1180 -r1.1181 src/sys/arch/i386/conf/GENERIC
cvs rdiff -u -r1.7 -r1.8 src/sys/external/bsd/drm/conf/files.drm
cvs rdiff -u -r1.8 -r1.9 src/sys/external/bsd/drm/dist/bsd-core/drm_pciids.h
cvs rdiff -u -r1.2 -r0 src/sys/external/bsd/drm/dist/bsd-core/via_dmablit.c
cvs rdiff -u -r1.1 -r0 src/sys/external/bsd/drm/dist/bsd-core/via_dmablit.h
cvs rdiff -u -r1.8 -r0 src/sys/external/bsd/drm/dist/bsd-core/via_drv.c
cvs rdiff -u -r1.3 -r0 src/sys/external/bsd/drm/dist/bsd-core/via/Makefile
cvs rdiff -u -r1.1.1.1 -r1.2 \
src/sys/external/bsd/drm/dist/scripts/create_lk_drm.sh \
src/sys/external/bsd/drm/dist/scripts/create_lk_gpu.sh
cvs rdiff -u -r1.3 -r1.4 \
src/sys/external/bsd/drm/dist/shared-core/drm_pciids.txt
cvs rdiff -u -r1.1.1.1 -r0 \
src/sys/external/bsd/drm/dist/shared-core/via_3d_reg.h \
src/sys/external/bsd/drm/dist/shared-core/via_ds.h \
src/sys/external/bsd/drm/dist/shared-core/via_mm.h
cvs rdiff -u -r1.4 -r0 src/sys/external/bsd/drm/dist/shared-core/via_dma.c \
src/sys/external/bsd/drm/dist/shared-core/via_drv.h \
src/sys/external/bsd/drm/dist/shared-core/via_irq.c
cvs rdiff -u -r1.2 -r0 src/sys/external/bsd/drm/dist/shared-core/via_drm.h \
src/sys/external/bsd/drm/dist/shared-core/via_ds.c \
src/sys/external/bsd/drm/dist/shared-core/via_verifier.h \
src/sys/external/bsd/drm/dist/shared-core/via_video.c
cvs rdiff -u -r1.3 -r0 src/sys/external/bsd/drm/dist/shared-core/via_map.c \
src/sys/external/bsd/drm/dist/shared-core/via_mm.c \
src/sys/external/bsd/drm/dist/shared-core/via_verifier.c
cvs rdiff -u -r1.205 -r1.206 src/sys/modules/Makefile
cvs rdiff -u -r1.3 -r0 src/sys/modules/viadrm/Makefile
cvs rdiff -u -r1.1 -r0 src/sys/modules/viadrm/viadrm.ioconf
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Tue, 10 Jul 2018 18:03:39 +0000
State-Changed-Why:
Removed viadrm. Thanks for the report!
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home