Skip to content

Invalid matching rule for display causes i915 oops when Intel HD Graphics P4000 in Ivy Bridge Xeon is probed

  • System architechture: amd64
  • Kernel version: 6.4.4-1-amd64 from Debian
  • Linux distribution: Debian testing
  • Machine: HP Z220 SFF Workstation
  • Display connector: HDMI via DP

Detailed phenomenon described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042517, booting a GNU/Linux with kernel version 6.4.4+ on a desktop computer with cougar or panther point mainboard equipped with Intel Xeon CPU E3-1225v2 or 1245v2, 1275v2 would always trigger this issue. This bug seemed to be introduced by https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-5-matthew.d.roper@intel.com, in which the matching rule in intel_display_device_probe() cannot differentiate Intel HD Graphics P4000 in Ivy Bridge Xeon (PCI:8086:016a) from INTEL_IVB_Q_IDS(NULL) in drivers/gpu/drm/i915/display/intel_display_device.c, making it return NULL for Intel HD Graphics P4000, causing the oops for NULL pointer dereference in intel_device_info_driver_create() in drivers/gpu/drm/i915/intel_device_info.c.

Furthermore, in drivers/gpu/drm/i915/i915_pci.c, ivb_q_info has no real difference from ivb_d_gt2_info, so is INTEL_QUANTA_VGA_DEVICE (PCI:8086:016a:152d:8990) really different from ordinary Intel HD Graphics P4000 (PCI:8086:016a)? If they are actually the same, we can also treat them identically. If not, it seems that we had better use subvendor and subdevice to differentiate them.

Edited by Mad Horse
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information