On Fri, Sep 4, 2026 at 11:54 PM Greg Ociepka <[email protected]> wrote: > > On Fri, 4 Sep 2026 04:29:16 +0530, Akhil P Oommen wrote: > > On 8/20/2026 7:14 PM, Greg Ociepka wrote: > [...] > >> We are happy to test patches, run instrumented builds, and provide > >> full journals or devcoredumps - the machine reproduces this every > >> couple of days under normal desktop use. > > > > Does your tree have these fixes: > > https://lore.kernel.org/lkml/[email protected]/t/#u > > Yes, all six of them. I checked each patch of that series against > linux-next (cgit): > > d9108bfdb746 drm/msm/a6xx: Fix stale rpmh votes after suspend > b303e1d52811 drm/msm: Recover HW before retire hung submit > fc7ccbc6174b drm/msm/a6xx: Fix A663 GPUCC register list for state capture > d052d0358fb8 drm/msm/a6xx: Fix A621 GPUCC register list for state capture > bc024d325e98 drm/msm/a6xx: Fix IRQ storm during msm_recovery test > 40b793714ad8 drm/msm: Fix task_struct reference leak in recover_worker > > All of them are already in next-20260730, which is the tree the report > (and the four incidents in it) came from, and they are in > next-20260831 as well, which this machine has been running since the > evening of Sep 3 (7.3.0-rc1-next-20260831, with the same local > platform patches as described in the report, still nothing anywhere > near the GPU, GMU, GDSC or clock paths, plus one unrelated > fs/buffer.c fix). > > So the loop reproduced with these fixes in place. > > For completeness, the timeline since the report: > > - After the report I started running thunderbird, the most frequent > "offending task" of the earlier incidents, with > LIBGL_ALWAYS_SOFTWARE=1 (llvmpipe) as a user-space mitigation. > - The last incident on the next-20260730 tree was on Aug 30, 12:10 > CEST: 689 "hangcheck recover" cycles in one boot, with a different > client as the trigger, so the mitigation did not prevent it. > - Since the switch to next-20260831 on the evening of Sep 3 there has > been no incident, but against a historical rate of one every few > days that short a window does not mean anything yet. > > > Also, could you try limiting the Fmax to < 1Ghz? > > Yes. The OPP table as the kernel sees it here (available_frequencies) > is 310, 410, 572, 760, 820, 915, 1070, 1185, 1350, 1550, 1700 and > 1850 MHz, and max_freq is at 1850000000 as I write this, i.e. the > full range. I will cap it at 915 MHz, the highest step below 1 GHz, > through devfreq at runtime: > > echo 915000000 > /sys/class/devfreq/3d00000.gpu/max_freq > > and keep the machine at that setting under normal use. It is a sysfs > setting, so there is an uncapped window after every boot until it is > re-applied; I will log that window per boot and check any incident > against it, since onset correlated with session restores in the > earlier incidents. Given the historical rate I would like to give it > at least two weeks before concluding anything, and I will report > either way: at the first incident under the cap (with the journal and > trans_stat, reset when the cap went on, so you can see devfreq never > asked for anything above it), or after the observation window if it > stays clean. One caveat: this stacks on top of the kernel bump, so a > clean run would not tell the two apart on its own; if it stays clean > I can go back to the full range on next-20260831 to separate them. > > On Thu, 3 Sep 2026 13:16:47 +0200, Konrad Dybcio wrote: > > On 8/21/26 3:35 PM, Rob Clark wrote: > [...] > >> Fwiw, the kernel I've been using: [1].. but that doesn't have the a16 > >> dts. I need to move forward to something newer, hopefully I'll get to > >> that today. We'll see if I start seeing this issue. Or maybe > >> something x2e vs x2ee is different regarding pmic/supplies? > >> > >> My device doesn't have the highest OPP (1.85ghz), which I think your > >> device does. We might be still missing some power related features > >> that are (more?) needed at higher freq's, or maybe I have a more lucky > >> piece of silicon? Akhil would know more about this. You might try > >> removing the highest OPP in gpu_opp_table (in glymur.dtsi) to see if > >> that improves stability? (Repeat until it is stable if you have the > >> same issues w/ 1.7ghz.) > > > > Greg, have you tried this? > > Not yet, and sorry for the late answer on this. We have not run the > machine with the top OPP(s) removed from the DT for any meaningful > period, so there is no data point from that side; what we did instead > is the mitigation and the kernel bump described above. Rob's guess is > right: this is the X2 Elite Extreme part (UX3607OA), it does have the > 1.85 GHz OPP, and it is currently running with the full range > (max_freq 1850000000, see above). Mesa here is still 26.1.5, the same > as in the report, so it has not been a variable in any of this. > > Rather than removing OPPs from the DT one at a time, I will start with > Akhil's Fmax < 1 GHz test via the runtime cap above, which is > reversible without a rebuild and is also the most direct test of Rob's > "power related features that are (more?) needed at higher freq's" > theory. It is not quite the same thing as dropping the OPP (the GMU > still gets the full table, the GPU just never gets asked for the top > levels), so if the capped run stays clean, walking the cap back up, or > dropping just the top OPP from the DT as Rob suggested, is the natural > next step to find where it starts failing. > > On the x2e vs x2ee question: I have no insight into PMIC or supply > differences between the two parts. If there is anything worth dumping > from this machine on that front (regulator state, the level table the > GMU is given, ...), tell me what and I will collect it. > > The offer stands: at the next incident I will grab the devcoredump of > the first crash state in the loop, before it expires, together with > the full journal of that boot, and I can run instrumented builds or > debug patches on top of next-20260831.
If the issue you hit starts w/ "GMU firmware initialization timed out", like the issue I was hitting, the patch I just sent[1] (and CC'd you on) increases the timeout to a safe value. Could you please try this patch? BR, -R [1] https://lore.kernel.org/all/[email protected]/
