FreeBSDDesktop / kms-drm

the DRM part of the linuxkpi-based KMS
63 stars 26 forks source link

13.0-CURRENT drm-devel-kmod radeonkms panics #159

Closed grahamperrin closed 3 years ago

grahamperrin commented 5 years ago

This type of panic might be more likely to occur when using OpenGL 3.1 (instead of XRender) as the compositor rendering backend.

Is it a duplicate of #149 or does use of drm-devel-kmod make this issue distinctive?

root@momh167-gjp4-8570p:/var/crash # less core.txt.1
momh167-gjp4-8570p dumped core - see /var/crash/vmcore.1

Tue Jul 16 21:08:47 BST 2019

FreeBSD momh167-gjp4-8570p 13.0-CURRENT FreeBSD 13.0-CURRENT r350027 GENERIC  amd64

panic: general protection fault

Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer     = 0x20:0xffffffff8359396f
stack pointer           = 0x28:0xfffffe0099743570
frame pointer           = 0x28:0xfffffe00997435b0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 2144 (kwin_x11)
trap number             = 9
panic: general protection fault
cpuid = 0
time = 1563307490
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0099743280
vpanic() at vpanic+0x19d/frame 0xfffffe00997432d0
panic() at panic+0x43/frame 0xfffffe0099743330
trap_fatal() at trap_fatal+0x39c/frame 0xfffffe0099743390
trap() at trap+0x6c/frame 0xfffffe00997434a0
calltrap() at calltrap+0x8/frame 0xfffffe00997434a0
--- trap 0x9, rip = 0xffffffff8359396f, rsp = 0xfffffe0099743570, rbp = 0xfffffe00997435b0 ---
dma_fence_is_signaled() at dma_fence_is_signaled+0x2f/frame 0xfffffe00997435b0
reservation_object_wait_timeout_rcu() at reservation_object_wait_timeout_rcu+0xba/frame 0xfffffe0099743650
radeon_gem_wait_idle_ioctl() at radeon_gem_wait_idle_ioctl+0x4d/frame 0xfffffe0099743680
drm_ioctl_kernel() at drm_ioctl_kernel+0xff/frame 0xfffffe00997436c0
drm_ioctl() at drm_ioctl+0x2d3/frame 0xfffffe00997437b0
radeon_drm_ioctl() at radeon_drm_ioctl+0x4d/frame 0xfffffe00997437e0
linux_file_ioctl() at linux_file_ioctl+0x299/frame 0xfffffe0099743840
kern_ioctl() at kern_ioctl+0x28a/frame 0xfffffe00997438b0
sys_ioctl() at sys_ioctl+0x15d/frame 0xfffffe0099743980
amd64_syscall() at amd64_syscall+0x2bb/frame 0xfffffe0099743ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe0099743ab0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8035d731a, rsp = 0x7fffffffd998, rbp = 0x7fffffffd9c0 ---
KDB: enter: panic
Uptime: 51m50s
Dumping 3619 out of 16270 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at /usr/src/sys/amd64/include/pcpu.h:246
246             __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (OFFSETOF_CURTHREAD));
(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu.h:246
#1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:392
#2  0xffffffff80bca900 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:479
#3  0xffffffff80bcad79 in vpanic (fmt=<optimized out>, ap=<optimized out>)
    at /usr/src/sys/kern/kern_shutdown.c:905
#4  0xffffffff80bcaab3 in panic (fmt=<unavailable>)
    at /usr/src/sys/kern/kern_shutdown.c:832
#5  0xffffffff81099ffc in trap_fatal (frame=0xfffffe00997434b0, eva=0)
    at /usr/src/sys/amd64/amd64/trap.c:943
#6  0xffffffff810993fc in trap (frame=0xfffffe00997434b0)
    at /usr/src/sys/amd64/amd64/trap.c:221
#7  <signal handler called>
#8  0xffffffff8359396f in dma_fence_is_signaled ()
   from /boot/modules/linuxkpi_gplv2.ko
#9  0xffffffff8359481a in reservation_object_wait_timeout_rcu ()
   from /boot/modules/linuxkpi_gplv2.ko
#10 0xffffffff834476cd in radeon_gem_wait_idle_ioctl ()
   from /boot/modules/radeonkms.ko
#11 0xffffffff8353364f in drm_ioctl_kernel () from /boot/modules/drm.ko
#12 0xffffffff83533943 in drm_ioctl () from /boot/modules/drm.ko
#13 0xffffffff8344189d in radeon_drm_ioctl () from /boot/modules/radeonkms.ko
#14 0xffffffff83579e09 in linux_file_ioctl_sub (fp=<optimized out>, 
    filp=<optimized out>, fop=<optimized out>, cmd=<optimized out>, data=0x0, 
    td=<optimized out>)
    at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:967
#15 linux_file_ioctl (fp=<optimized out>, cmd=<optimized out>, 
    data=<optimized out>, cred=<optimized out>, td=<optimized out>)
    at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:1560
#16 0xffffffff80c3adba in fo_ioctl (fp=<optimized out>, com=<optimized out>, 
    data=0xffffffff81fc21a8 <w_locklistdata+206312>, active_cred=0xdeadc001, 
    td=<optimized out>) at /usr/src/sys/sys/file.h:333
#17 kern_ioctl (td=<optimized out>, fd=<optimized out>, com=2148033636, 
    data=0xffffffff81fc21a8 <w_locklistdata+206312> "")
    at /usr/src/sys/kern/sys_generic.c:800
#18 0xffffffff80c3aabd in sys_ioctl (td=0xfffff8004c67f000, 
    uap=0xfffff8004c67f3c8) at /usr/src/sys/kern/sys_generic.c:712
#19 0xffffffff8109ab2b in syscallenter (td=0xfffff8004c67f000)
    at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:144
#20 amd64_syscall (td=0xfffff8004c67f000, traced=0)
    at /usr/src/sys/amd64/amd64/trap.c:1180
#21 <signal handler called>
#22 0x00000008035d731a in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffffffd998
(kgdb) 

Environment

HP EliteBook 8570p

root@momh167-gjp4-8570p:~ # pciconf -lv | grep -B 3 -A 1 -i display
vgapci0@pci0:1:0:0:     class=0x030000 card=0x17a9103c chip=0x68411002 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Thames [Radeon HD 7550M/7570M/7650M]'
    class      = display
    subclass   = VGA
root@momh167-gjp4-8570p:~ # 

KDE Plasma Version: 5.16.3 KDE Frameworks Version: 5.59.0 Qt Version: 5.12.2 Kernel Version: 13.0-CURRENT OS Type: 64-bit Processors: 4 × ACPI CPU Memory: 15.9 GiB of RAM

root@momh167-gjp4-8570p:~ # pkg query '%o %v %R' gpu-firmware-kmod drm-devel-kmod
graphics/gpu-firmware-kmod g20190620 unknown-repository
graphics/drm-devel-kmod 5.0.g20190710 unknown-repository
root@momh167-gjp4-8570p:~ # 
grahamperrin commented 5 years ago

This type of panic might be more likely to occur when using OpenGL 3.1 (instead of XRender) as the compositor rendering backend.

Maybe ignore that thought.

This panic occurred with XRender. IIRC after I copied Control-C from Geany, aiming to paste to Waterfox (can't recall whether I got as far as the keyboard shortcut for the paste):

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x90e
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff8359396f
stack pointer           = 0x28:0xfffffe00b1b17100
frame pointer           = 0x28:0xfffffe00b1b17140
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 2185 (kwin_x11:rcs0)
trap number             = 12
panic: page fault
cpuid = 0
time = 1563355469
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00b1b16dc0
vpanic() at vpanic+0x19d/frame 0xfffffe00b1b16e10
panic() at panic+0x43/frame 0xfffffe00b1b16e70
trap_fatal() at trap_fatal+0x39c/frame 0xfffffe00b1b16ed0
trap_pfault() at trap_pfault+0x62/frame 0xfffffe00b1b16f20
trap() at trap+0x2b4/frame 0xfffffe00b1b17030
calltrap() at calltrap+0x8/frame 0xfffffe00b1b17030
--- trap 0xc, rip = 0xffffffff8359396f, rsp = 0xfffffe00b1b17100, rbp = 0xfffffe00b1b17140 ---
dma_fence_is_signaled() at dma_fence_is_signaled+0x2f/frame 0xfffffe00b1b17140
reservation_object_add_shared_fence() at reservation_object_add_shared_fence+0x113/frame 0xfffffe00b1b17190
ttm_eu_fence_buffer_objects() at ttm_eu_fence_buffer_objects+0x81/frame 0xfffffe00b1b171d0
radeon_cs_parser_fini() at radeon_cs_parser_fini+0x52/frame 0xfffffe00b1b17200
radeon_cs_ioctl() at radeon_cs_ioctl+0x8c6/frame 0xfffffe00b1b17680
drm_ioctl_kernel() at drm_ioctl_kernel+0xff/frame 0xfffffe00b1b176c0
drm_ioctl() at drm_ioctl+0x2d3/frame 0xfffffe00b1b177b0
radeon_drm_ioctl() at radeon_drm_ioctl+0x4d/frame 0xfffffe00b1b177e0
linux_file_ioctl() at linux_file_ioctl+0x299/frame 0xfffffe00b1b17840
kern_ioctl() at kern_ioctl+0x28a/frame 0xfffffe00b1b178b0
sys_ioctl() at sys_ioctl+0x15d/frame 0xfffffe00b1b17980
amd64_syscall() at amd64_syscall+0x2bb/frame 0xfffffe00b1b17ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe00b1b17ab0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8035d731a, rsp = 0x7fffdeff5eb8, rbp = 0x7fffdeff5ee0 ---
KDB: enter: panic
Uptime: 1h51m19s
Dumping 1696 out of 16270 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at /usr/src/sys/amd64/include/pcpu.h:246
246             __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (OFFSETOF_CURTHREAD));
(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu.h:246
#1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:392
#2  0xffffffff80bca900 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:479
#3  0xffffffff80bcad79 in vpanic (fmt=<optimized out>, ap=<optimized out>)
    at /usr/src/sys/kern/kern_shutdown.c:905
#4  0xffffffff80bcaab3 in panic (fmt=<unavailable>)
    at /usr/src/sys/kern/kern_shutdown.c:832
#5  0xffffffff81099ffc in trap_fatal (frame=0xfffffe00b1b17040, eva=2318)
    at /usr/src/sys/amd64/amd64/trap.c:943
#6  0xffffffff8109a062 in trap_pfault (frame=0xfffffe00b1b17040, 
    usermode=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:767
#7  0xffffffff81099644 in trap (frame=0xfffffe00b1b17040)
    at /usr/src/sys/amd64/amd64/trap.c:443
#8  <signal handler called>
#9  0xffffffff8359396f in dma_fence_is_signaled ()
   from /boot/modules/linuxkpi_gplv2.ko
#10 0xffffffff83593bc3 in reservation_object_add_shared_fence ()
   from /boot/modules/linuxkpi_gplv2.ko
#11 0xffffffff835aa7c1 in ttm_eu_fence_buffer_objects ()
   from /boot/modules/ttm.ko
#12 0xfffff8016c5f3c48 in ?? ()
#13 0xfffffe00b1b174e0 in ?? ()
#14 0x0000000000000000 in ?? ()
(kgdb) 

KDE Plasma Version: 5.16.3 KDE Frameworks Version: 5.60.0 Qt Version: 5.12.2

grahamperrin commented 5 years ago

For around two weeks I used drm-legacy-kmod without difficulty.

Around 2019-09-27 I updated the OS to r350368.

When I retried drm-devel-kmod, a panic occurred very soon after logging in to KDE. Whilst launching a handful of applications:

root@momh167-gjp4-8570p:/var/crash # less core.txt.7
momh167-gjp4-8570p dumped core - see /var/crash/vmcore.7

Fri Aug  2 08:58:02 BST 2019

FreeBSD momh167-gjp4-8570p 13.0-CURRENT FreeBSD 13.0-CURRENT r350368 GENERIC  amd64

panic: general protection fault

…

Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...

Unread portion of the kernel message buffer:

Fatal trap 9: general protection fault while in kernel mode
cpuid = 2; apic id = 02
instruction pointer     = 0x20:0xffffffff8344388b
stack pointer           = 0x28:0xfffffe009f240040
frame pointer           = 0x28:0xfffffe009f240070
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 3
current process         = 7095 (X:rcs0)
trap number             = 9
panic: general protection fault
cpuid = 2
time = 1564732320
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009f23fd50
vpanic() at vpanic+0x19d/frame 0xfffffe009f23fda0
panic() at panic+0x43/frame 0xfffffe009f23fe00
trap_fatal() at trap_fatal+0x39c/frame 0xfffffe009f23fe60
trap() at trap+0x6c/frame 0xfffffe009f23ff70
calltrap() at calltrap+0x8/frame 0xfffffe009f23ff70
--- trap 0x9, rip = 0xffffffff8344388b, rsp = 0xfffffe009f240040, rbp = 0xfffffe009f240070 ---
radeon_fence_signaled() at radeon_fence_signaled+0x2b/frame 0xfffffe009f240070
radeon_sa_bo_new() at radeon_sa_bo_new+0x251/frame 0xfffffe009f2401d0
radeon_ib_get() at radeon_ib_get+0x2f/frame 0xfffffe009f240210
radeon_cs_ioctl() at radeon_cs_ioctl+0x23c/frame 0xfffffe009f240690
drm_ioctl_kernel() at drm_ioctl_kernel+0xff/frame 0xfffffe009f2406d0
drm_ioctl() at drm_ioctl+0x2d3/frame 0xfffffe009f2407c0
radeon_drm_ioctl() at radeon_drm_ioctl+0x4d/frame 0xfffffe009f2407f0
linux_file_ioctl() at linux_file_ioctl+0x299/frame 0xfffffe009f240850
kern_ioctl() at kern_ioctl+0x291/frame 0xfffffe009f2408b0
sys_ioctl() at sys_ioctl+0x15d/frame 0xfffffe009f240980
amd64_syscall() at amd64_syscall+0x2bb/frame 0xfffffe009f240ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe009f240ab0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800ce335a, rsp = 0x7fffdfffdeb8, rbp = 0x7fffdfffdee0 ---
KDB: enter: panic
Uptime: 47m34s
Dumping 1122 out of 16270 MB:..2%..12%..22%..32%..42%..52%..62%..72%..82%..92%

__curthread () at /usr/src/sys/amd64/include/pcpu.h:246
246             __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (OFFSETOF_CURTHREAD));
(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu.h:246
#1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:392
#2  0xffffffff80bcadd0 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:479
#3  0xffffffff80bcb249 in vpanic (fmt=<optimized out>, ap=<optimized out>)
    at /usr/src/sys/kern/kern_shutdown.c:905
#4  0xffffffff80bcaf83 in panic (fmt=<unavailable>)
    at /usr/src/sys/kern/kern_shutdown.c:832
#5  0xffffffff8109af9c in trap_fatal (frame=0xfffffe009f23ff80, eva=0)
    at /usr/src/sys/amd64/amd64/trap.c:943
#6  0xffffffff8109a39c in trap (frame=0xfffffe009f23ff80)
    at /usr/src/sys/amd64/amd64/trap.c:221
#7  <signal handler called>
#8  0xffffffff8344388b in radeon_mst_encoder_prepare ()
   from /boot/modules/radeonkms.ko
#9  0x0000000000002000 in ?? ()
#10 0xfffff8000358a800 in ?? ()
#11 0x0000000000000ae0 in ?? ()
#12 0xfffffe0097e75f88 in ?? ()
#13 0xfffff8000388a4c0 in ?? ()
#14 0xfffffe0097e75ec8 in ?? ()
#15 0xfffffe009f2401d0 in ?? ()
#16 0xffffffff8345b201 in radeon_gem_prime_vmap ()
   from /boot/modules/radeonkms.ko
#17 0xfffffe009f2400a0 in ?? ()
#18 0x0000000000000000 in ?? ()
(kgdb) 

…

I reverted from devel to legacy,

root@momh167-gjp4-8570p:~ # pkg rquery '%o %v %R' drm-devel-kmod xf86-video-ati
graphics/drm-devel-kmod 5.0.g20190722_1 FreeBSD
graphics/drm-devel-kmod 5.0.g20190722_1 poudriere
x11-drivers/xf86-video-ati 19.0.1,1 FreeBSD
root@momh167-gjp4-8570p:~ # pkg query '%o %v %R' drm-legacy-kmod xf86-video-ati-legacy
graphics/drm-legacy-kmod g20190709 poudriere
x11-drivers/xf86-video-ati-legacy 7.9.0_3,1 FreeBSD
root@momh167-gjp4-8570p:~ # 

KDE Plasma Version: 5.16.3 KDE Frameworks Version: 5.60.0 Qt Version: 5.12.2

Might it help to know more about actions before each panic?

On this occasion the panic occurred moments after I keyed Return at an Unlock Keyring dialogue at Remmina launch time, e.g.:

image

grahamperrin commented 4 years ago

https://gitter.im/FreeBSDDesktop/Lobby?at=5da56df1870fa33a4df5c835 (2019-10-15):

Incidentally both -current- and -devel- have become usable, compared to the system crash-tastic era …

– and in response:

… There's been some changes to the VM subsystem that might have changed stuff.

Unfortunately, two days later, two panics within a short period of time so I again I have reverted to non-recommended drm-legacy-kmod.

Prior to reversion:

$ date ; uname -v
Thu Oct 17 13:07:35 BST 2019
FreeBSD 13.0-CURRENT #33 r352942: Wed Oct  2 05:26:54 BST 2019     root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
$ uptime
 1:07PM  up 7 mins, 1 user, load averages: 0.27, 0.49, 0.26
$ pkg query '%o %v %R' drm-devel-kmod gpu-firmware-kmod mesa-dri xf86-video-ati 
graphics/drm-devel-kmod 5.0.g20190828 poudriere
graphics/gpu-firmware-kmod g20190825 unknown-repository
graphics/mesa-dri 18.3.2_7 poudriere
x11-drivers/xf86-video-ati 19.0.1,1 poudriere
$ 

A later overview of the two panics:

root@momh167-gjp4-8570p:/var/crash # date ; uname -v
Fri Oct 18 05:48:50 BST 2019
FreeBSD 13.0-CURRENT #33 r352942: Wed Oct  2 05:26:54 BST 2019     root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
root@momh167-gjp4-8570p:/var/crash # ls -hlrt
total 5873092
-rw-r--r--  1 root  wheel     5B Dec 13  2018 minfree
-rw-r--r--  1 root  wheel   451K Aug  2 08:58 core.txt.7
-rw-------  1 root  wheel   442B Sep 25 09:19 info.5
-rw-------  1 root  wheel   936M Sep 25 09:20 vmcore.5
-rw-r--r--  1 root  wheel    96K Sep 25 09:20 core.txt.5
-rw-------  1 root  wheel   442B Sep 25 09:27 info.6
-rw-------  1 root  wheel   1.3G Sep 25 09:28 vmcore.6
-rw-r--r--  1 root  wheel   154K Sep 25 09:29 core.txt.6
-rw-------  1 root  wheel   399B Sep 27 09:48 info.8
-rw-------  1 root  wheel   1.6G Sep 27 09:49 vmcore.8
-rw-r--r--  1 root  wheel   467K Sep 27 09:49 core.txt.8
-rw-------  1 root  wheel   487B Oct  6 09:11 info.9
-rw-------  1 root  wheel   4.2G Oct  6 09:12 vmcore.9
-rw-r--r--  1 root  wheel   689K Oct  6 09:13 core.txt.9
-rw-------  1 root  wheel   487B Oct  7 21:54 info.0
-rw-------  1 root  wheel   2.3G Oct  7 21:54 vmcore.0
-rw-r--r--  1 root  wheel   569K Oct  7 21:55 core.txt.0
-rw-------  1 root  wheel   501B Oct  7 23:02 info.1
-rw-------  1 root  wheel   2.1G Oct  7 23:03 vmcore.1
-rw-r--r--  1 root  wheel   609K Oct  7 23:03 core.txt.1
-rw-------  1 root  wheel   487B Oct 13 09:21 info.2
-rw-------  1 root  wheel   2.5G Oct 13 09:23 vmcore.2
-rw-r--r--  1 root  wheel   399K Oct 13 09:23 core.txt.2
-rw-------  1 root  wheel   488B Oct 17 11:58 info.3
-rw-------  1 root  wheel   4.5G Oct 17 12:01 vmcore.3
-rw-r--r--  1 root  wheel   600K Oct 17 12:02 core.txt.3
-rw-r--r--  1 root  wheel     2B Oct 17 13:01 bounds
-rw-------  1 root  wheel   488B Oct 17 13:01 info.4
-rw-------  1 root  wheel   1.8G Oct 17 13:02 vmcore.4
lrwxr-xr-x  1 root  wheel     6B Oct 17 13:02 info.last -> info.4
lrwxr-xr-x  1 root  wheel     8B Oct 17 13:02 vmcore.last -> vmcore.4
-rw-r--r--  1 root  wheel   437K Oct 17 13:03 core.txt.4
root@momh167-gjp4-8570p:/var/crash # cat info.3
Dump header from device: /dev/ada0p3
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 4830154752
  Blocksize: 512
  Compression: none
  Dumptime: Thu Oct 17 11:50:21 2019
  Hostname: momh167-gjp4-8570p
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 13.0-CURRENT #33 r352942: Wed Oct  2 05:26:54 BST 2019
    root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
  Panic String: page fault
  Dump Parity: 2086851954
  Bounds: 3
  Dump Status: good
root@momh167-gjp4-8570p:/var/crash # cat info.4
Dump header from device: /dev/ada0p3
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 1959669760
  Blocksize: 512
  Compression: none
  Dumptime: Thu Oct 17 12:56:35 2019
  Hostname: momh167-gjp4-8570p
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 13.0-CURRENT #33 r352942: Wed Oct  2 05:26:54 BST 2019
    root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
  Panic String: page fault
  Dump Parity: 3799242098
  Bounds: 4
  Dump Status: good
root@momh167-gjp4-8570p:/var/crash # 
grahamperrin commented 4 years ago

Sensitivity of /var/crash/core.txt.* file content : freebsd – please, can anyone answer this?

I mean, I'd like to share the two most recent files in their entireties but I don't know whether it's appropriate to do so.

TIA

grahamperrin commented 4 years ago

The two panics described at https://github.com/FreeBSDDesktop/kms-drm/issues/159#issuecomment-543504383

core.txt.3 (redacted).txt

core.txt.4 (redacted).txt

grahamperrin commented 4 years ago
$ date ; uname -v
Tue Oct 29 03:09:51 GMT 2019
FreeBSD 13.0-CURRENT #35 r354082: Sat Oct 26 00:25:05 BST 2019     root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 
$ uptime
 3:09AM  up 41 mins, 5 users, load averages: 0.66, 0.80, 0.78
$ pkg query '%o %v %R' drm-devel-kmod gpu-firmware-kmod mesa-dri xf86-video-ati 
graphics/drm-devel-kmod 5.0.g20191023 poudriere
graphics/gpu-firmware-kmod g20191015 unknown-repository
graphics/mesa-dri 18.3.2_7 poudriere
x11-drivers/xf86-video-ati 19.0.1,1 FreeBSD
$ 

kld_list="/boot/modules/radeonkms.ko"

This panic occurred after maybe a day of uptime.

(A prior session used drm-current-kmod with kld_list="radeonkms".)

At the time of the panic I was recording the screen on DisplayPort-1 (a Philips 271P4) whilst uploading to https://put.re/ in home-built Waterfox Classic 56.2.14 (20191007063316). In a nearby tab in the same window I was editing a comment in Reddit, with a preference for old Reddit.

Dump header from device: /dev/ada0p3
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 2524463104
  Blocksize: 512
  Compression: none
  Dumptime: Tue Oct 29 02:21:16 2019
  Hostname: momh167-gjp4-8570p
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 13.0-CURRENT #35 r354082: Sat Oct 26 00:25:05 BST 2019
    root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
  Panic String: page fault
  Dump Parity: 244891749
  Bounds: 6
  Dump Status: good

core.txt.6.txt


Now using kld_list="radeonkms".

A shot from after the panic:

2019-10-29 02:41:29 Session Manager

abishai commented 4 years ago

radeonkms is highly instable on my 12.1 machine (not a regression, 12.0 had the same panics as well). legacy driver is stable Usually I have 2 panics per day.

Fatal trap 12: page fault while in kernel mode
cpuid = 11; apic id = 0b
fault virtual address   = 0x5
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff82d644be
stack pointer           = 0x28:0xfffffe00907581f8
frame pointer           = 0x28:0xfffffe0090758230
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1215 (Xorg:rcs0)
trap number             = 12
panic: page fault
cpuid = 11
time = 1572384610
KDB: stack backtrace:
#0 0xffffffff80be78d7 at kdb_backtrace+0x67
#1 0xffffffff80b9b4b3 at vpanic+0x1a3
#2 0xffffffff80b9b303 at panic+0x43
#3 0xffffffff81074bff at trap_fatal+0x35f
#4 0xffffffff81074c59 at trap_pfault+0x49
#5 0xffffffff8107427e at trap+0x29e
#6 0xffffffff8104f625 at calltrap+0x8
#7 0xffffffff82cb46ba at radeon_cs_ioctl+0xa4a
#8 0xffffffff82dafca6 at drm_ioctl_kernel+0xf6
#9 0xffffffff82daff41 at drm_ioctl+0x281
#10 0xffffffff82df1bd4 at linux_file_ioctl+0x204
#11 0xffffffff80c04e9d at kern_ioctl+0x26d
#12 0xffffffff80c04bbe at sys_ioctl+0x15e
#13 0xffffffff810756d9 at amd64_syscall+0x369
#14 0xffffffff8104ff0d at fast_syscall_common+0x101

Probably, this one is reported long-long time ago.

BSDer commented 4 years ago

Hi @grahamperrin , is this booting with BIOS or EFI?

I am trying to track this down and it seems there are cases where BIOS boot causes troubles and EFI boot does not. Thank you.

grahamperrin commented 3 years ago

With apologies for the late reply: if I recall correctly, it was typically UEFI without CSM.

I might have occasionally tried UEFI with CSM but can't recall doing so.

For what it's worth: I probably have not encountered this type of panic (or #149 for drm-current-kmod) for a few months.

grahamperrin commented 3 years ago

From https://gitter.im/FreeBSDDesktop/Lobby/archives/2020/09/20?at=5f67c00dc1d1a53705b5932d yesterday evening:

good news: in recent months, both drm-devel-kmod and drm-current-kmod seem far less likely to panic for me with 'Thames [Radeon HD 7550M/7570M/7650M]'. So I'd like to close both of these, unless anyone can think of a good reason to keep either one open:

  • FreeBSDDesktop/kms-drm#158 …
  • FreeBSDDesktop/kms-drm#159 for drm-current-kmod and drm-devel-kmod.

grahamperrin commented 3 years ago

No comparable panic in recent months.