Discovered that in both 12.0-RELEASE-p11 and 12.1-RC2-p0, on an Intel NUC8i5BEH with Intel Iris Graphics, if one is running a custom kernel where "options MAXCPU" is a value lower than the default of 256, loading i915kms.ko on boot (via kld_list in /etc/rc.conf), the system will panic. Partial bootlog is below, manually transcribed from an image I took of the screen: Loading kernel modules: drmn0: <drmn> on vgapci0 vgapci0: child drmn0 requested pci_enable_io vgapci0: child drmn0 requested pci_enable_io <5>[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19). <6>[drm] Found 128MB of eDRAM Failed to add WC MTRR for [0x80000000-0x8fffffff]: -22; performance may suffer<6>[drm] Got stolen memory base rx7c000000, size 0x4000000 <6>[drm] Supports vblank timestamp caching Rev 2 (21.10.2013). <6>[drm] Driver supports precise vblank timestap query. <6>[drm] Connector eDP-1: get mode from tunables: <6>[drm] - kern.vt.fb.modes.eDP-1 <6>[drm] - kern.vt.fb.default_mode panic: Invalid CPU in callout 256 cpuid = 2 time = 1572817693 KDB: stack backtrace: #0 0xffffffff8089cc47 at kdb_backtrace+0x67 #1 0xffffffff80850276 at vpanic+0x136 #2 0xffffffff80850133 at panic+0x43 #3 0xffffffff8086ad9a at callout_reset_sbt_on+0x36a #4 0xffffffff825c3dcb at linux_queue_delayed_work_on+0x1db #5 0xffffffff8249749b at intel_dp_init_connector+0x8bb #6 0xffffffff82471195 at intel_ddi_init+0x365 #7 0xffffffff82484a88 at intel_modeset_init+0x1038 #8 0xffffffff82424b49 at i915_driver_load+0x14f9 #9 0xffffffff825be7d2 at linux_pci_attach+0x432 #10 0xffffffff8088b021 at device_attach+0x3e1 #11 0xffffffff8088d478 at bus_generic_driver_added+0xa8 #12 0xffffffff8088933a at devclass_driver_added+0x7a #13 0xffffffff8088929a at devclass_add_driver+0x16a #14 0xffffffff825bdf86 at _linux_pci_register_driver+0xf6 #15 0xffffffff8244f7fe at i915kms_evh+0x2e #16 0xffffffff8082f3a4 at module_register_init+0xa4 #17 0xffffffff8082208f at linker_load_module+0xb3f Workaround for now is to remove any change to MAXCPU from the custom kernel config, or boot with the GENERIC kernel.
Thank you for the report Joshua Is the issue also reproducible with drm-kmod from ports? See 12.0-RELEASE release notes [1]: https://www.freebsd.org/releases/12.0R/relnotes.html#hardware-graphics
I believe it is. When I initially tested on 12.1-RC2, I followed this mailing list thread here, thinking this thread highlighted my problem: https://www.mail-archive.com/freebsd-stable@freebsd.org/msg138326.html So I built drm-fbsd12.0-kmod-4.16.g20191024 via ports as a package (as well as gpu-firmware-kmod-g20191015), then installed that package to get it working on 12.1-RC2 (needed because I'm building a Kodi box and need EVDEV for working bluetooth mouse/keyboard via a mini keyboard device). Before I rebuilt my kernel w/o MAXCPU, it'd crash virtually the exact same way. Just a slight difference in the stack trace where after the call to "intel_dp_init_connector", there's a call to "intel_edp_panel_vdd_sanitize", then the call to "linux_queue_delayed_work_on", which goes on to trigger the panic. After rebuilding the 12.1-RC2 kernel and commenting out MAXCPU, it works fine w/ i915kms.ko from the rebuilt drm-fbsd12.0-kmod package. Even got Kodi up and working (just working on sound output now).
I suspect the drm-kms modules need default values for some kernel parameters, because when building these we don't use the config file used by the kernel. This might be possible to fix, by generating the needed kernel options from the current kernel config file.
FWIW, it took me half a day to realise I was bitten by the same thing on 12.2-STABLE as of today. What works is to compile drm-fbsd12.0-kmod with the same value for MAXCPU as the kernel. A smaller value for the kmod does not help either.
There is a broad issue with out-of-tree kernel modules not picking up kernel configuration options; we need to develop a holistic solution for this.
At work we simply dump: sysctl kern.conftxt and run configure on that to get all the options correct. --HPS