Bug 248441

Comment 1 Kubilay Kocak 2020-08-03 00:04:56 UTC

Thank you for your report. Can you please include additional information, including:

- uname -a output
- /var/run/dmesg.boot output (as an attachment)
- pciconf -lv output (as an attachment)
- pkg version -v output (as an attachment)
- /boot/loader.conf output (as an attachment)
- Backtrace (ideally) or screenshot of the crash/panic

Created attachment 216979 [details]
dmesg.boot

dmesg.boot

Created attachment 216980 [details]
rc.conf

rc.conf

Created attachment 216981 [details]
loader.conf

loader.conf

Created attachment 216982 [details]
pciconf -lv

pciconf -lv

Created attachment 216983 [details]
pkg version -v

pkg version -v

(In reply to Kubilay Kocak from comment #1)

$ uname -a
FreeBSD giahung.freebsd.local 11.4-RELEASE-p1 FreeBSD 11.4-RELEASE-p1 #0: Tue Jul  7 08:51:03 UTC 2020     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

(In reply to Kubilay Kocak from comment #1)

Core file, too big for attachment so I upload it here: https://gofile.io/d/5zfvCp

I don't know how to examine it. Please let me know if it contains sensitive information (e.g: my passwords) so I could know to change my passwords. Thanks.

p/s: for safety, after the bug is fixed, I will delete that file.

Comment 9 Jan Beich 2020-08-03 10:54:06 UTC

(In reply to gh_origin from comment #2)
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 02
> fault virtual address	= 0xfffffe7140c840d8
> fault code		= supervisor read data, page not present
> instruction pointer	= 0x20:0xffffffff82ca5882
> stack pointer	        = 0x28:0xfffffe02327e8140
> frame pointer	        = 0x28:0xfffffe02327e8160
> code segment		= base rx0, limit 0xfffff, type 0x1b
> 			= DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags	= interrupt enabled, resume, IOPL = 0
> current process		= 806 (kldload)
> trap number		= 12
> panic: page fault
> cpuid = 1
> KDB: stack backtrace:
> #0 0xffffffff80b431d5 at kdb_backtrace+0x65
> #1 0xffffffff80afd2de at vpanic+0x15e
> #2 0xffffffff80afd173 at panic+0x43
> #3 0xffffffff80f75fc5 at trap_fatal+0x365
> #4 0xffffffff80f76019 at trap_pfault+0x49
> #5 0xffffffff80f756ce at trap+0x27e
> #6 0xffffffff80f5532f at calltrap+0x8
> #7 0xffffffff82cb4ad6 at reservation_object_get_fences_rcu+0x76
> #8 0xffffffff82b2d5d8 at i915_gem_object_wait+0x78
> #9 0xffffffff82b31d10 at i915_gem_object_set_cache_level+0xc0
> #10 0xffffffff82b32119 at i915_gem_object_pin_to_display_plane+0x49
> #11 0xffffffff82b72f66 at intel_pin_and_fence_fb_obj+0x136
> #12 0xffffffff82b86f9e at intel_modeset_init+0xdde
> #13 0xffffffff82b2a090 at i915_driver_load+0x1330
> #14 0xffffffff82ca4a4d at linux_pci_attach+0x4cd
> #15 0xffffffff80b35708 at device_attach+0x398
> #16 0xffffffff80b37258 at bus_generic_driver_added+0x88
> #17 0xffffffff80b33449 at devclass_driver_added+0x39

Did you install drm-fbsd11.2-kmod via binary packages (from pkg.freebsd.org)? If so rebuild from ports. FreeBSD doesn't promise KBI (not ABI) compatibility between minor versions (e.g., 11.3-RELEASE-p1 and 11.3-RELEASE-p999 are compatible but 11.3 and 11.4 are not) but the binary packages are built for the oldest supported release of a given branch (e.g., 11.3 until 2020-09-30 for /stable/11).

(In reply to gh_origin from comment #5)
> vgapci0@pci0:0:2:0:	class=0x030000 card=0x78171462 chip=0x04128086 rev=0x06 hdr=0x00

0x0412 is Haswell which is supported by both in-base drm2 (aka /boot/kernel/i915kms.ko) and drm-kmod (aka /boot/modules/i915kms.ko). Note, in-base drm2 is pretty old thus doesn't support VAAPI and DRI3.

$ fgrep -r 0x0412 /usr/src/sys/dev/drm*
sys/dev/drm2/i915/i915_drv.c:   INTEL_VGA_DEVICE(0x0412, &intel_haswell_d_info), /* GT2 desktop */
sys/dev/drm2/drm_pciids.h:      {0x8086, 0x0412, 0, "Intel Haswell (GT2 desktop)"}, \

$ cd /usr/ports/graphics/drm-fbsd11.2-kmod
$ make clean patch BATCH=
$ fgrep -r 0x0412 `make -V WRKSRC`
.../kms-drm-d7d433d/include/drm/i915_pciids.h:     INTEL_VGA_DEVICE(0x0412, info), /* GT2 desktop */ \

(In reply to gh_origin from comment #3)
> #kld_list="/boot/kernel/i915kms.ko"

How did you load i915kms then? If location isn't explicitly specified then module is resolved according to kern.module_path (sysctl) order.

Build from ports worked fine. Thanks everyone for helped me. I think I would close the bug now.