Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 04 Nov 2019 00:30:00 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 241697] kernel panic on loading of i915kms.ko if custom kernel w/ MAXCPU < 256
Message-ID:  <bug-241697-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241697

            Bug ID: 241697
           Summary: kernel panic on loading of i915kms.ko if custom kernel
                    w/ MAXCPU < 256
           Product: Base System
           Version: 12.1-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: kumba@gentoo.org

Discovered that in both 12.0-RELEASE-p11 and 12.1-RC2-p0, on an Intel NUC8i=
5BEH
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 0x7c000000, 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 =3D 2
time =3D 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.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-241697-227>