Re: [regression] Re: Linux 6.12.75

Vitaly Chikunov
2026-04-14T15:24:46Z

Thorsten, Sasha,

On Tue, Apr 14, 2026 at 04:57:38PM +0300, Vitaly Chikunov wrote:
> On Tue, Apr 14, 2026 at 03:17:38AM +0300, Vitaly Chikunov wrote:
> > On Mon, Apr 13, 2026 at 05:17:30PM +0300, Vitaly Chikunov wrote:
> > > On Mon, Apr 13, 2026 at 01:33:18PM +0200, Thorsten Leemhuis wrote:
> > > > On 4/2/26 10:44, Vitaly Chikunov wrote:
> > > > >
> > > > > 1. I cannot find this commit posted on lore.kernel.org to report to
> > > > > exact patch.
> > > > >
> > > > > | From: Matt Roper <matthew.d.roper@intel.com>
> > > > > | Date: Tue, 10 Sep 2024 16:47:29 -0700
> > > > > | Subject: [PATCH 6.12/sisyphus] drm/xe: Switch MMIO interface to take xe_mmio
> > > > > | instead of xe_gt
> > > > > |
> > > > > | [ Upstream commit a84590c5ceb354d2e9f7f6812cfb3a9709e14afa ]
> > > > > |
> > > > > | Since much of the MMIO register access done by the driver is to non-GT
> > > > > | registers, use of 'xe_gt' in these interfaces has been a long-standing
> > > > > | design flaw that's been hard to disentangle.
> > > > > [...]
> > > > >
> > > > > 2. After this patch applied to 6.12.75 there is kernel NULL pointer
> > > > > dereference BUG on MSI MAG H670 12th Gen Intel(R) Core(TM) i5-12600K
> > > > > with ASRock Intel Arc B580 Challenger [Alchemist], 12GB:
> > > > > [...]
> > > > > The commit is found not by a git bisect (since it's reported by end
> > > > > user and I cannot reproduce it on my hardware) but (by analyzing dmesg)
> > > > > with:
> > > > > [...]
> > > > > Then finding the suspecting commit:
> > > > >
> > > > > $ git log --oneline -G'XE_LUNARLAKE' v6.12.74..v6.12.75
> > > > > 26a40327c25c drm/xe: Switch MMIO interface to take xe_mmio instead of xe_gt
> > > > >
> > > > > 6.18 and above are not affected by the bug. Also, they have another commit
> > > > > modifying the line which is not present in 6.12 branch:
> > > > > [...]
> > > > > Related drm/xe bug report https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7661
> > > > Nobody reacted to this and it seems the gitlab ticket is stalled, too.
> > > > So let me ask: can this be resolved by reverting 26a40327c25c in 6.12.y?
> >
> > It's turned out these two commits are revertible together:
> >
> > 8f6848b2f6ea ("drm/xe/mmio: Avoid double-adjust in 64-bit reads")
> > 26a40327c25c ("drm/xe: Switch MMIO interface to take xe_mmio instead of xe_gt")
> >
> > I am going to ask the users to test this.
>
> After testing revert of these two commits, users report that regress
> does not appear, kernel boots without panic and there is no video artifacts.

After analyzing the problem slightly deeper, it seems that there is
uninitialized mmio.tile issue. Which is fixed in mainline commit

58548b91101f ("drm/xe: Defer gt->mmio initialization until after multi-tile setup")

The commit also have tag:

Fixes: fa599b8c95a7 ("drm/xe: Populate GT's mmio iomap from tile during init")

The commit fa599b8c95a7 is picked into 6.12.75 as 0b433e086b9f, but the
fix is not. Piking it may be the better way to fix the regression than
the revert of the two aforementioned commits.

I will try to pick the fix, test, and report if it resolves the regress.

Thanks,

>
> So, I kindly ask to revert them from 6.12.y branch if they aren't
> critical.
>
> Thanks,
>
> >
> > Thanks,
> >
> > >
> > > As of me, this is not easy to revert, as it depends on many other
> > > commits, and git does not have tooling to determine all dependant
> > > commits for revert. I hope someone from drm subsystem notices this to
> > > work on it, or Sasha can pull missing commits or revert this (obviously,
> > > he have tooling for this, but I was unable to find it). [I found
> > > obsolete references to deps but is seems not used for years and Python
> > > git-deps tool seems broken.]
> > >
> > > What I found is, offending commit is picked due to
> > >
> > > Stable-dep-of: 4a9b4e1fa52a ("drm/xe/mmio: Avoid double-adjust in 64-bit reads")
> > >
> > > Which, perhaps, needs to be reverted.
> > >
> > > Offending commit 26a40327c25c is not tracked in lore.
> > > It's part of 9 piece patchset, perhaps they are logically dependent too,
> > > so need to be reverted together.
> > >
> > > The possible fix is part of 6 piece patchset, which does not cherry-pick
> > > easily due to conflicts.
> > >
> > > If someone can produce correct fix we can participate in the tests.
> > >
> > > Thanks,
> > >
> > > >
> > > > Ciao, Thorsten