Closed grahamperrin closed 3 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
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.:
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 #
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
$ 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
Now using kld_list="radeonkms"
.
A shot from after the panic:
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.
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.
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.
From https://gitter.im/FreeBSDDesktop/Lobby/archives/2020/09/20?at=5f67c00dc1d1a53705b5932d yesterday evening:
… good news: in recent months, both
drm-devel-kmod
anddrm-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
anddrm-devel-kmod
.…
No comparable panic in recent months.
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?…
Environment
HP EliteBook 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