Quoting Andreas Friedrich (2021-04-30 13:36:35) > On Fri, Apr 30, 2021 at 11:31:47AM +0300, Joonas Lahtinen wrote: > > Hello Joonas, > > thank you for your quick response. > ... > > That is a merge commit, it doesn't itself change anything as there were no > > conflicts. It just indicates that two trees got merged. > ... > > If you are able to provide a bisect to a one patch, please do report it > > as a bug, let's then take it from there. > > I have bisect the kernel 3 times and it always leads me to the wrong > end. Because not every suspend results in a frozen system, maybe I > have marked a 'bisect good' although it was bad. This is most likely the problem. You should try each suggested commit enough times to gain confidence in if it's good or bad build. > What I surely can say is, that kernel 5.11.16 works fine and 5.12-rc1 > (v5.12-rc1-dontuse) does not. > > However, on the bisecting path I saw the following commits: > [41a9c75d0acf23f33f012d3f9535de9e9b631051] drm/i915/gem: Move stolen node into GEM object union > [d82afcf9caaac26ce2642511115bca9dacf30f41] Merge tag 'drm-intel-gt-next-2021-01-21-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next > [885e1938452fc7fc37a3051d76e1ddb7ead099fa] drm/i915/gvt: statically set F_CMD_WRITE_PATCH flag > [a2dd2ff50cde3cbbeecec72225bb18582b291f14] drm/i915/gt: Skip over completed active execlists, again > [02dd2b12a685944c4d52c569d05f636372a7b6c7] drm/i915/gvt: unify lri cmd handler and mmio handlers > [69b4b99842201bc24c98ba66b922d8879e190483] drm/i915/gvt: Add missing forward decl of intel_vgpu for HDRTEST > [c071a6c0fef0fade787d827c7fc0e07481512326] Merge tag 'gvt-gt-next-2021-01-18' of https://github.com/intel/gvt-linux into drm-intel-gt-next As Zhenyu mentioned, you don't even have GVT module enabled, so most of those are guaranteed to be incorrectly bisected. And there are two merge commits with no conflicts (== no code change). Bisect should end so that the previous commit is good, and the new commit is bad. If there are no code changes in the commit, there's no way it can be the commit that is really the culprit. Without a proper bisect, it'll be quite difficult to start the triage on our side. > So I think it's a drm-i915 issue. I have communicated with David > Airlie (airlied@xxxxxxxxxx) and he also bets on an i915 bug. It's very possible that it can be i915 bug. What you can try is to blacklist i915 module and operate the system with SSH and see if the latest kernel still freezes? Also, please try drm-tip kernel and see if it fixed there. > > https://01.org/linuxgraphics/documentation/how-report-bugs > > Following https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs > I can give you the following infos: > - After calling 'echo mem > /sys/power/state' the system gets frozen > (the screen is dimmed but the CPU fan is still running). The > system is inaccessible from remote. The only way to get it working > again is to hard power off and on. > - One out of 5 suspend tries will cause the issue, mostly the first one. > - Notebook: Old Toshiba Tecra A10 from 2009. > - x86_64, 5.12-rc1, Debian GNU/Linux 10 (buster), see dmidecode.txt.gz > and 5.12.config.gz > - Because the system is frozen, I cannot read /sys/class/drm/card0/error > before rebooting. > > Please let me know if I can do anyting else to solve the problem. Please do file a bug on the issue tracker as requested: https://gitlab.freedesktop.org/drm/intel/issues/ Regards, Joonas _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
