Bug 241697 - i915kms: Kernel panic loading module on custom kernel w/ MAXCPU < 256 (Invalid CPU in callout 256)
Summary: i915kms: Kernel panic loading module on custom kernel w/ MAXCPU < 256 (Invali...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
Keywords: crash, i915, needs-qa
Depends on:
Reported: 2019-11-04 00:30 UTC by Joshua Kinard
Modified: 2019-11-14 21:46 UTC (History)
3 users (show)

See Also:
koobs: mfc-stable12?
koobs: mfc-stable11?


Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Kinard 2019-11-04 00:30:00 UTC
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.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2019-11-04 01:40:04 UTC
Thank you for the report Joshua

Is the issue also reproducible with drm-kmod from ports?

See 12.0-RELEASE release notes [1]:

Comment 2 Joshua Kinard 2019-11-04 04:44:59 UTC
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:

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).
Comment 3 Hans Petter Selasky freebsd_committer 2019-11-04 07:24:46 UTC
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.