Hi,
On 16/09/2021 05:37, Hugh Dickins wrote:
Two Lenovo ThinkPads, old T420s (2011), newer X1 Carbon 5th gen (2017):
i915 working fine on both up to 5.14, but blank screens booting 5.15-rc1,
kernel crashed in some way.
T420s could be SandyBridge and X1 Carbon KabyLake.
I wanted to say what i915 generations these are, but don't know where
to look - I don't see it in dmesg, even when DRM_I915_DEBUG enabled.
Possibly relevant: builtin kernels, CONFIG_MODULES off, no initrd.
On the older laptop:
First bisection showed first bad commit
41e5c17ebfc2 "drm/i915/guc/slpc: Sysfs hooks for SLPC"
But reverting that still crashed boot with blank screen (and
reverting the two related commits after it made no difference).
Second bisection, starting from 5.15-rc1 bad and 41e5c17ebfc2 "good",
but patching it out each time before building, showed first bad commit
3ffe82d701a4 "drm/i915/xehp: handle new steering options"
That one did not revert cleanly from 5.15-rc1, but reverting
927dfdd09d8c "drm/i915/dg2: Add SQIDI steering" then
1705f22c86fb "drm/i915/dg2: Update steering tables" then
768fe28dd3dc "drm/i915/xehpsdv: Define steering tables" then
3ffe82d701a4 "drm/i915/xehp: handle new steering options"
worked (there was one very easy fixup needed somewhere).
And 5.15-rc1 with those five reversions boots and runs fine...
on that older laptop. But reverting those from the kernel on the
newer laptop did not help at all, still booting with blank screen
(or no more lines shown after the switch from VGA). Put them back.
Bisect results sound suspicious since the steering patches do not come
into play on SandyBridge.
On the newer laptop, bisection showed first bad commit
62eaf0ae217d "drm/i915/guc: Support request cancellation"
And 5.15-rc1 with that reverted boots and runs fine on the newer.
But not on the older laptop?
Given bisect points to this, it may be worth trying to build both
kernels with CONFIG_DRM_I915_REQUEST_TIMEOUT=0 (no reverts) to see what
happens. But first the logs which I'll ask next.
I am hoping that there will be some i915 fixups to come in a later rc!
May be nothing more than uninitialized variables or NULL pointers.
You'll probably want more info from me: please ask, but I'm slow.
Kernel logs with drm.debug=0xe, with the broken black screen state,
would probably answer a lot of questions if you could gather it from
both machines?
Regards,
Tvrtko
