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. Thanks, Greg Ociepka
