Re: [regression] Re: Linux 6.12.75

Vitaly Chikunov
2026-04-15T12:24:10Z

Thorsten, Sasha,

On Tue, Apr 14, 2026 at 06:24:38PM +0300, Vitaly Chikunov wrote:
> 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")

Applying this commit to v6.12.81 does not resolve the regress. Thus, I
would suggest reverting commits 26a40327c25c and 8f6848b2f6ea.

Thanks,

>
> 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