Re: radeon panics kernels
On Fri, Oct 04, 2019 at 12:17:30PM -0700, Johannes Lundberg wrote: > On Fri, Oct 4, 2019 at 11:39 Steve Kargl > wrote: > > > On Thu, Oct 03, 2019 at 11:52:38PM +0200, Hans Petter Selasky wrote: > > > On 2019-10-03 22:26, Steve Kargl wrote: > > > > > > > > So, your guess of a NULL pointer seems correct. > > > > > > Can you do: > > > > > > set print pretty on > > > print *rdev > > > > > > > This produces close to 3400 lines of output. Do you want me to > > send it to the list or directly to you? > > Please put on gist, pastebin, etc and share the link. > https://pastebin.com/0iHtWP9C -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: radeon panics kernels
On Fri, Oct 4, 2019 at 11:39 Steve Kargl wrote: > On Thu, Oct 03, 2019 at 11:52:38PM +0200, Hans Petter Selasky wrote: > > On 2019-10-03 22:26, Steve Kargl wrote: > > > On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote: > > >> > > >> If you leave the port debug knob for drm-current-kmod AS-IS, I think > you > > >> can get away with: > > >> > > >> make DEBUG_FLAGS="-g" > > >> > > >> Then re-load the vmcore file in GDB/KGDB from ports (!) and add the > > >> symbol files for the modules loaded. Then get the backtrace using bt > > >> command. > > >> > > >> BTW: Did you try drm-devel-kmod for 13-current? > > >> > > > > > > Took a bit of trial and error. If I skip the panic > > > and trap frames (#0 through #8). I find the backtrace > > > that follows by sig. If I move to frame #11, I see > > > > > > (kgdb) frame 11 > > > #11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=) > > > at > /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c:4114 > > > 4114writel(reg, ((void __iomem *)rdev->rmmio) + > RADEON_MM_INDEX); > > > (kgdb) p rdev->rmmio > > > $3 = (void *) 0x0 > > > > > > So, your guess of a NULL pointer seems correct. > > > > Can you do: > > > > set print pretty on > > print *rdev > > > > This produces close to 3400 lines of output. Do you want me to > send it to the list or directly to you? Please put on gist, pastebin, etc and share the link. > > -- > Steve > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: radeon panics kernels
On Thu, Oct 03, 2019 at 11:52:38PM +0200, Hans Petter Selasky wrote: > On 2019-10-03 22:26, Steve Kargl wrote: > > On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote: > >> > >> If you leave the port debug knob for drm-current-kmod AS-IS, I think you > >> can get away with: > >> > >> make DEBUG_FLAGS="-g" > >> > >> Then re-load the vmcore file in GDB/KGDB from ports (!) and add the > >> symbol files for the modules loaded. Then get the backtrace using bt > >> command. > >> > >> BTW: Did you try drm-devel-kmod for 13-current? > >> > > > > Took a bit of trial and error. If I skip the panic > > and trap frames (#0 through #8). I find the backtrace > > that follows by sig. If I move to frame #11, I see > > > > (kgdb) frame 11 > > #11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=) > > at > > /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c:4114 > > 4114writel(reg, ((void __iomem *)rdev->rmmio) + > > RADEON_MM_INDEX); > > (kgdb) p rdev->rmmio > > $3 = (void *) 0x0 > > > > So, your guess of a NULL pointer seems correct. > > Can you do: > > set print pretty on > print *rdev > This produces close to 3400 lines of output. Do you want me to send it to the list or directly to you? -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: radeon panics kernels
On Thu, Oct 03, 2019 at 11:52:38PM +0200, Hans Petter Selasky wrote: > On 2019-10-03 22:26, Steve Kargl wrote: > > On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote: > >> > >> If you leave the port debug knob for drm-current-kmod AS-IS, I think you > >> can get away with: > >> > >> make DEBUG_FLAGS="-g" > >> > >> Then re-load the vmcore file in GDB/KGDB from ports (!) and add the > >> symbol files for the modules loaded. Then get the backtrace using bt > >> command. > >> > >> BTW: Did you try drm-devel-kmod for 13-current? > >> > > > > Took a bit of trial and error. If I skip the panic > > and trap frames (#0 through #8). I find the backtrace > > that follows by sig. If I move to frame #11, I see > > > > (kgdb) frame 11 > > #11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=) > > at > > /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c:4114 > > 4114writel(reg, ((void __iomem *)rdev->rmmio) + > > RADEON_MM_INDEX); > > (kgdb) p rdev->rmmio > > $3 = (void *) 0x0 > > > > So, your guess of a NULL pointer seems correct. > > Can you do: > > set print pretty on > print *rdev > Left work for the day. I'll get this info first thing tomorrow morning. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: radeon panics kernels
On 2019-10-03 22:26, Steve Kargl wrote: On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote: If you leave the port debug knob for drm-current-kmod AS-IS, I think you can get away with: make DEBUG_FLAGS="-g" Then re-load the vmcore file in GDB/KGDB from ports (!) and add the symbol files for the modules loaded. Then get the backtrace using bt command. BTW: Did you try drm-devel-kmod for 13-current? Took a bit of trial and error. If I skip the panic and trap frames (#0 through #8). I find the backtrace that follows by sig. If I move to frame #11, I see (kgdb) frame 11 #11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=) at /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c:4114 4114writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX); (kgdb) p rdev->rmmio $3 = (void *) 0x0 So, your guess of a NULL pointer seems correct. Can you do: set print pretty on print *rdev --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: radeon panics kernels
On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote: > > If you leave the port debug knob for drm-current-kmod AS-IS, I think you > can get away with: > > make DEBUG_FLAGS="-g" > > Then re-load the vmcore file in GDB/KGDB from ports (!) and add the > symbol files for the modules loaded. Then get the backtrace using bt > command. > > BTW: Did you try drm-devel-kmod for 13-current? > Took a bit of trial and error. If I skip the panic and trap frames (#0 through #8). I find the backtrace that follows by sig. If I move to frame #11, I see (kgdb) frame 11 #11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=) at /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c:4114 4114writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX); (kgdb) p rdev->rmmio $3 = (void *) 0x0 So, your guess of a NULL pointer seems correct. -- Steve #9 __raw_writel (v=1932408418, addr=) at /usr/src/sys/compat/linuxkpi/common/include/linux/io.h:111 #10 writel (v=1932408418, addr=) at /usr/src/sys/compat/linuxkpi/common/include/linux/io.h:199 #11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=) at PATH/drivers/gpu/drm/radeon/r100.c:4114 #12 0x817ba613 in r100_mm_rreg (rdev=, reg=, always_indirect=false) at PATH/drivers/gpu/drm/radeon/radeon.h:2481 #13 radeon_fence_read (rdev=, ring=) at PATH/drivers/gpu/drm/radeon/radeon_fence.c:95 #14 radeon_fence_activity (rdev=0xf80135766a70, ring=) at PATH/drivers/gpu/drm/radeon/radeon_fence.c:229 #15 0x817ba6e9 in radeon_fence_process (rdev=0xf80135766a70, ring=0) at PATH/drivers/gpu/drm/radeon/radeon_fence.c:324 #16 radeon_fence_seq_signaled (rdev=, seq=, ring=) at PATH/drivers/gpu/drm/radeon/radeon_fence.c:349 #17 radeon_fence_signaled (fence=0xf801f7a62700) at PATH/drivers/gpu/drm/radeon/radeon_fence.c:438 #18 0x817d2601 in radeon_sa_bo_try_free (sa_manager=) at PATH/drivers/gpu/drm/radeon/radeon_sa.c:163 #19 radeon_sa_bo_new (rdev=0xfe00b07fc000, sa_manager=0xfe00b07fdf18, sa_bo=0xfe00b4380450, size=11168, align=256) at PATH/drivers/gpu/drm/radeon/radeon_sa.c:341 #20 0x817c1a4f in radeon_ib_get (rdev=0xfe00b07fc000, ring=0, ib=0xfe00b4380450, vm=0x0, size=0) at PATH/drivers/gpu/drm/radeon/radeon_ib.c:61 #21 0x817ad6ed in radeon_cs_ib_fill (rdev=, parser=) at PATH/drivers/gpu/drm/radeon/radeon_cs.c:640 #22 radeon_cs_ioctl (dev=, data=, filp=) at PATH/drivers/gpu/drm/radeon/radeon_cs.c:687 #23 0x818a82f5 in drm_ioctl_kernel (linux_file=, func=0x817ad490 , kdata=0xfe00b43806c0, flags=33) at PATH/drivers/gpu/drm/drm_ioctl.c:760 #24 0x818a858a in drm_ioctl (filp=0xf8001ba48e00, cmd=, arg=65536) at PATH/drivers/gpu/drm/drm_ioctl.c:856 #25 0x807cf568 in linux_file_ioctl_sub (fp=, filp=, fop=, cmd=, data=0x0, td=) at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:965 #26 linux_file_ioctl (fp=, cmd=, data=, cred=, td=) at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:1558 #27 0x80643694 in fo_ioctl (fp=, com=3223348326, data=0x8185dd5c, active_cred=0xf8001be3a001, td=) at /usr/src/sys/sys/file.h:341 #28 kern_ioctl (td=0xf8001be3a000, fd=, com=3223348326, data=0x8185dd5c "PATH/drivers/gpu/drm/radeon/r100.c") at /usr/src/sys/kern/sys_generic.c:804 #29 0x80643398 in sys_ioctl (td=0xf8001be3a000, uap=0xf8001be3a3c8) at /usr/src/sys/kern/sys_generic.c:712 #30 0x808b92e5 in syscallenter (td=0xf8001be3a000) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:144 #31 amd64_syscall (td=0xf8001be3a000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1162 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: radeon panics kernels
On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote: > On 2019-10-03 14:59, Steve Kargl wrote: > > On Thu, Oct 03, 2019 at 09:17:32AM +0200, Hans Petter Selasky wrote: > >> On 2019-10-02 23:19, Steve Kargl wrote: > >>> troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.7 > >>> > >>> Wed Oct 2 14:12:38 PDT 2019 > >>> > >> > >> This looks like a simple NULL pointer. > >> > >> Can you re-compile the drm ports module with debugging symbols and then > >> reproduce? > >> > > > > Yes. Is there a ports knob, ie., 'make -DEBUG' for the > > drm ports? Or, do I need to add CFLAGS+=-g to the Makefile? > > > > BTW, this is what I have installed > > > > drm-current-kmod-4.16.g20190927 DRM modules for the linuxkpi-based KMS > > drm-kmod-g20190710 Metaport of DRM modules > > gpu-firmware-kmod-g20190825Firmware modules for the linuxkpi-based KMS > > If you leave the port debug knob for drm-current-kmod AS-IS, I think you > can get away with: > > make DEBUG_FLAGS="-g" > > Then re-load the vmcore file in GDB/KGDB from ports (!) and add the > symbol files for the modules loaded. Then get the backtrace using bt > command. > > BTW: Did you try drm-devel-kmod for 13-current? > No. I let drm-kmod select drm-current-kod. I can trying drm-devel-kmodr. I do have an older graphics card, which required the drm-legacy-kmod port until recently % pciconf -vl ... vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' device = 'Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM]' class = display subclass = VGA -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: radeon panics kernels
On Thu, Oct 03, 2019 at 05:59:20AM -0700, Steve Kargl wrote: > On Thu, Oct 03, 2019 at 09:17:32AM +0200, Hans Petter Selasky wrote: > > On 2019-10-02 23:19, Steve Kargl wrote: > > > troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.7 > > > > > > Wed Oct 2 14:12:38 PDT 2019 > > > > > > > This looks like a simple NULL pointer. > > > > Can you re-compile the drm ports module with debugging symbols and then > > reproduce? > > > > Yes. Is there a ports knob, ie., 'make -DEBUG' for the > drm ports? Or, do I need to add CFLAGS+=-g to the Makefile? > Nevermind. After reading the Makefile, I see that there is an option knob that can be toggled. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: radeon panics kernels
On 2019-10-03 14:59, Steve Kargl wrote: On Thu, Oct 03, 2019 at 09:17:32AM +0200, Hans Petter Selasky wrote: On 2019-10-02 23:19, Steve Kargl wrote: troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.7 Wed Oct 2 14:12:38 PDT 2019 This looks like a simple NULL pointer. Can you re-compile the drm ports module with debugging symbols and then reproduce? Yes. Is there a ports knob, ie., 'make -DEBUG' for the drm ports? Or, do I need to add CFLAGS+=-g to the Makefile? BTW, this is what I have installed drm-current-kmod-4.16.g20190927 DRM modules for the linuxkpi-based KMS drm-kmod-g20190710 Metaport of DRM modules gpu-firmware-kmod-g20190825Firmware modules for the linuxkpi-based KMS If you leave the port debug knob for drm-current-kmod AS-IS, I think you can get away with: make DEBUG_FLAGS="-g" Then re-load the vmcore file in GDB/KGDB from ports (!) and add the symbol files for the modules loaded. Then get the backtrace using bt command. BTW: Did you try drm-devel-kmod for 13-current? --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: radeon panics kernels
On Thu, Oct 03, 2019 at 09:17:32AM +0200, Hans Petter Selasky wrote: > On 2019-10-02 23:19, Steve Kargl wrote: > > troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.7 > > > > Wed Oct 2 14:12:38 PDT 2019 > > > > This looks like a simple NULL pointer. > > Can you re-compile the drm ports module with debugging symbols and then > reproduce? > Yes. Is there a ports knob, ie., 'make -DEBUG' for the drm ports? Or, do I need to add CFLAGS+=-g to the Makefile? BTW, this is what I have installed drm-current-kmod-4.16.g20190927 DRM modules for the linuxkpi-based KMS drm-kmod-g20190710 Metaport of DRM modules gpu-firmware-kmod-g20190825Firmware modules for the linuxkpi-based KMS -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: radeon panics kernels
On 2019-10-02 23:19, Steve Kargl wrote:
troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.7
Wed Oct 2 14:12:38 PDT 2019
This looks like a simple NULL pointer.
Can you re-compile the drm ports module with debugging symbols and then
reproduce?
--HPS
FreeBSD troutmask.apl.washington.edu 13.0-CURRENT FreeBSD 13.0-CURRENT r352812
HPC amd64
panic: page fault
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 10
fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x8177ba1c
stack pointer = 0x28:0xfe00b437ff50
frame pointer = 0x28:0xfe00b437ff70
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 782 (X:rcs0)
trap number = 12
panic: page fault
cpuid = 0
time = 1570050659
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00b437fc00
vpanic() at vpanic+0x19d/frame 0xfe00b437fc50
panic() at panic+0x43/frame 0xfe00b437fcb0
trap_fatal() at trap_fatal+0x394/frame 0xfe00b437fd10
trap_pfault() at trap_pfault+0x4f/frame 0xfe00b437fd70
trap() at trap+0x2a1/frame 0xfe00b437fe80
calltrap() at calltrap+0x8/frame 0xfe00b437fe80
--- trap 0xc, rip = 0x8177ba1c, rsp = 0xfe00b437ff50, rbp =
0xfe00b437ff70 ---
r100_mm_rreg_slow() at r100_mm_rreg_slow+0x3c/frame 0xfe00b437ff70
radeon_fence_activity() at radeon_fence_activity+0x103/frame 0xfe00b437ffd0
radeon_fence_signaled() at radeon_fence_signaled+0x59/frame 0xfe00b4380010
radeon_sa_bo_new() at radeon_sa_bo_new+0x251/frame 0xfe00b4380170
radeon_ib_get() at radeon_ib_get+0x2f/frame 0xfe00b43801b0
radeon_cs_ioctl() at radeon_cs_ioctl+0x25d/frame 0xfe00b4380630
drm_ioctl_kernel() at drm_ioctl_kernel+0xf5/frame 0xfe00b4380680
drm_ioctl() at drm_ioctl+0x27a/frame 0xfe00b4380770
linux_file_ioctl() at linux_file_ioctl+0x298/frame 0xfe00b43807d0
kern_ioctl() at kern_ioctl+0x284/frame 0xfe00b4380840
sys_ioctl() at sys_ioctl+0x158/frame 0xfe00b4380910
amd64_syscall() at amd64_syscall+0x275/frame 0xfe00b4380a30
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00b4380a30
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x200cc95ca, rsp =
0x7fffbfffde98, rbp = 0x7fffbfffdec0 ---
Uptime: 5d1h10m44s
Dumping 1764 out of 16327 MB:..1%..11% (CTRL-C to abort)
..21%..31%..41%..51%..61%..71%..81%..91%
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
(kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:392
#2 0x805e26aa in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:479
#3 0x805e2b09 in vpanic (fmt=, ap=)
at /usr/src/sys/kern/kern_shutdown.c:908
#4 0x805e2903 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:835
#5 0x808b8884 in trap_fatal (frame=0xfe00b437fe90, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:925
#6 0x808b88df in trap_pfault (frame=0xfe00b437fe90,
usermode=, signo=, ucode=)
at /usr/src/sys/amd64/amd64/trap.c:743
#7 0x808b7f71 in trap (frame=0xfe00b437fe90)
at /usr/src/sys/amd64/amd64/trap.c:407
#8
#9 0x8177ba1c in r100_mm_rreg_slow () from /boot/modules/radeonkms.ko
#10 0x817ba613 in radeon_fence_activity ()
from /boot/modules/radeonkms.ko
#11 0x817ba6e9 in radeon_fence_signaled ()
from /boot/modules/radeonkms.ko
#12 0x817d2601 in radeon_sa_bo_new () from /boot/modules/radeonkms.ko
#13 0x817c1a4f in radeon_ib_get () from /boot/modules/radeonkms.ko
#14 0x817ad6ed in radeon_cs_ioctl () from /boot/modules/radeonkms.ko
#15 0x818a82f5 in drm_ioctl_kernel () from /boot/modules/drm.ko
#16 0x818a858a in drm_ioctl () from /boot/modules/drm.ko
#17 0x807cf568 in linux_file_ioctl_sub (fp=,
filp=, fop=, cmd=, data=0x0,
td=)
at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:965
#18 linux_file_ioctl (fp=, cmd=,
data=, cred=, td=)
at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:1558
#19 0x80643694 in fo_ioctl (fp=, com=3223348326,
data=0x8185dd5c, active_cred=0xf8001be3a001,
td=) at /usr/src/sys/sys/file.h:341
#20 kern_ioctl (td=0xf8001be3a000, fd=, com=3223348326,
data=0x8185dd5c
"/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c")
at /usr/src/sys/kern/sys_generic.c:804
#21 0x80643398 in sys_ioctl (td=0xf8001be3a000,
uap=0xf8001be3a3c8) at /usr/src/sys/kern/sys_generic.c:712
#22 0x808b92e5 in syscallenter (td=0xf8001be3a000)
at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:144
#23 amd
radeon panics kernels
troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.7
Wed Oct 2 14:12:38 PDT 2019
FreeBSD troutmask.apl.washington.edu 13.0-CURRENT FreeBSD 13.0-CURRENT r352812
HPC amd64
panic: page fault
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 10
fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x8177ba1c
stack pointer = 0x28:0xfe00b437ff50
frame pointer = 0x28:0xfe00b437ff70
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 782 (X:rcs0)
trap number = 12
panic: page fault
cpuid = 0
time = 1570050659
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00b437fc00
vpanic() at vpanic+0x19d/frame 0xfe00b437fc50
panic() at panic+0x43/frame 0xfe00b437fcb0
trap_fatal() at trap_fatal+0x394/frame 0xfe00b437fd10
trap_pfault() at trap_pfault+0x4f/frame 0xfe00b437fd70
trap() at trap+0x2a1/frame 0xfe00b437fe80
calltrap() at calltrap+0x8/frame 0xfe00b437fe80
--- trap 0xc, rip = 0x8177ba1c, rsp = 0xfe00b437ff50, rbp =
0xfe00b437ff70 ---
r100_mm_rreg_slow() at r100_mm_rreg_slow+0x3c/frame 0xfe00b437ff70
radeon_fence_activity() at radeon_fence_activity+0x103/frame 0xfe00b437ffd0
radeon_fence_signaled() at radeon_fence_signaled+0x59/frame 0xfe00b4380010
radeon_sa_bo_new() at radeon_sa_bo_new+0x251/frame 0xfe00b4380170
radeon_ib_get() at radeon_ib_get+0x2f/frame 0xfe00b43801b0
radeon_cs_ioctl() at radeon_cs_ioctl+0x25d/frame 0xfe00b4380630
drm_ioctl_kernel() at drm_ioctl_kernel+0xf5/frame 0xfe00b4380680
drm_ioctl() at drm_ioctl+0x27a/frame 0xfe00b4380770
linux_file_ioctl() at linux_file_ioctl+0x298/frame 0xfe00b43807d0
kern_ioctl() at kern_ioctl+0x284/frame 0xfe00b4380840
sys_ioctl() at sys_ioctl+0x158/frame 0xfe00b4380910
amd64_syscall() at amd64_syscall+0x275/frame 0xfe00b4380a30
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00b4380a30
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x200cc95ca, rsp =
0x7fffbfffde98, rbp = 0x7fffbfffdec0 ---
Uptime: 5d1h10m44s
Dumping 1764 out of 16327 MB:..1%..11% (CTRL-C to abort)
..21%..31%..41%..51%..61%..71%..81%..91%
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
(kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:392
#2 0x805e26aa in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:479
#3 0x805e2b09 in vpanic (fmt=, ap=)
at /usr/src/sys/kern/kern_shutdown.c:908
#4 0x805e2903 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:835
#5 0x808b8884 in trap_fatal (frame=0xfe00b437fe90, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:925
#6 0x808b88df in trap_pfault (frame=0xfe00b437fe90,
usermode=, signo=, ucode=)
at /usr/src/sys/amd64/amd64/trap.c:743
#7 0x808b7f71 in trap (frame=0xfe00b437fe90)
at /usr/src/sys/amd64/amd64/trap.c:407
#8
#9 0x8177ba1c in r100_mm_rreg_slow () from /boot/modules/radeonkms.ko
#10 0x817ba613 in radeon_fence_activity ()
from /boot/modules/radeonkms.ko
#11 0x817ba6e9 in radeon_fence_signaled ()
from /boot/modules/radeonkms.ko
#12 0x817d2601 in radeon_sa_bo_new () from /boot/modules/radeonkms.ko
#13 0x817c1a4f in radeon_ib_get () from /boot/modules/radeonkms.ko
#14 0x817ad6ed in radeon_cs_ioctl () from /boot/modules/radeonkms.ko
#15 0x818a82f5 in drm_ioctl_kernel () from /boot/modules/drm.ko
#16 0x818a858a in drm_ioctl () from /boot/modules/drm.ko
#17 0x807cf568 in linux_file_ioctl_sub (fp=,
filp=, fop=, cmd=, data=0x0,
td=)
at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:965
#18 linux_file_ioctl (fp=, cmd=,
data=, cred=, td=)
at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:1558
#19 0x80643694 in fo_ioctl (fp=, com=3223348326,
data=0x8185dd5c, active_cred=0xf8001be3a001,
td=) at /usr/src/sys/sys/file.h:341
#20 kern_ioctl (td=0xf8001be3a000, fd=, com=3223348326,
data=0x8185dd5c
"/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c")
at /usr/src/sys/kern/sys_generic.c:804
#21 0x80643398 in sys_ioctl (td=0xf8001be3a000,
uap=0xf8001be3a3c8) at /usr/src/sys/kern/sys_generic.c:712
#22 0x808b92e5 in syscallenter (td=0xf8001be3a000)
at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:144
#23 amd64_syscall (td=0xf8001be3a000, traced=0)
at /usr/src/sys/amd64/amd64/trap.c:1162
#24
#25 0x000200cc95ca in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffbfffde9
