Created attachment 182481 [details]
since kernel version 4.1 (4.1.1, 4.1.2) shortly (5-10s) after a resume from s2ram, the system freezes. See attached log. This bug is reproducible.
What was the last kernel version that didn't have this problem? Does it also happen with 4.1.0? Can you bisect?
The last working kernel version is 4.0.x, I'm back on 4.0.8 right now. It also does happen with 4.1.0. I'll try to do a bisect.
Sorry for the delay, I tried a bisect:
git bisect start 'v4.0..v4.1' 'drivers/gpu/drm'
# good: [39a8804455fb23f09157341d3ba7db6d7ae6ee76] Linux 4.0
git bisect good 39a8804455fb23f09157341d3ba7db6d7ae6ee76
# bad: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1
git bisect bad b953c0d234bc72e8489d3bf51a276c5c4ec85345
# good: [b5f1c97f944482e98e6e39208af356630389d1ea] drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg
git bisect good b5f1c97f944482e98e6e39208af356630389d1ea
# good: [2611015c7511106719bae904cac459383c55ffef] drm/exynos: mixer: add 2x scaling to mixer_graph_buffer
git bisect good 2611015c7511106719bae904cac459383c55ffef
# good: [362ff251390f3d1f8fe94666f4fc4e5876381114] drm/radeon/audio: don't enable packets until the end
git bisect good 362ff251390f3d1f8fe94666f4fc4e5876381114
# good: [d10ebb9f136669a1e9fa388fc450bf1822c93dd5] drm/exynos: fb: use drm_format_num_planes to get buffer count
git bisect good d10ebb9f136669a1e9fa388fc450bf1822c93dd5
# bad: [7c0411d2fabc2e2702c9871ffb603e251158b317] drm/radeon: partially revert "fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling"
git bisect bad 7c0411d2fabc2e2702c9871ffb603e251158b317
After finding the first bad commit I'm stuck with:
Bisecting: 12 revisions left to test after this (roughly 4 steps)
error: Your local changes to the following files would be overwritten by checkout:
(In reply to Michael Long from comment #3)
> Bisecting: 12 revisions left to test after this (roughly 4 steps)
> error: Your local changes to the following files would be overwritten by
You need to remove your local modifications. Save them first if you still need them. If you need the local modifications for bisecting, you can apply them again after git bisect checked out the next commit to test.
I managed to proceed with the bisect process but it doesn't lead to another bad commit.
After that I restarted the bisection but this time without limiting to a sub-tree. This time e640a280ccb9c448a3d9d522ea730ce00efa8cf0 (Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux) was the first bad commit, but continuing also did not reveal another bad commit.
I'm not really familiar with the process, so I might do something fundamentally wrong but I will try again.
But I found out the following:
For testing around with KVM-based vga-passthrough, I've installed three different GPUs in my system:
AMD Radeon HD 5430 card for the host (using radeon)
AMD Radeon HD 5570 card for VM1 (using radeon) or another NVIDIA based card (using nouveau)
NVIDIA GTX 980 card for VM2 (no driver bound)
Hence the GTX 980 is not supported well, it is stubbed out via kernel parameter pci-stub.ids=...., the other cards were bound to a driver when they are not used with KVM/qemu.
The problem ONLY arises when more than 2 GPUs are installed (my guess is seen by vgaarb) and at least 2 GPUs are bound to a driver, e.g. radeon or nouveau.
If both cards are stubbed out the resume problem does not occur. I could do this as a temporary workaround but then I run into this bug here: https://bugs.freedesktop.org/show_bug.cgi?id=88773
I'm absolutely aware that this is corner case but still, it works with 4.0.9.
"No more bad commits" isn't necessarily a problem. Just keep testing the commits you get from running "git bisect good/bad" according to the test result with the previous commit, until the process is finished and it prints out which commit seems to have introduced the problem.
FWIW, it's better not to limit the bisection to a sub-tree.
I tried several times to bisect this problem but it is an incredible task for me. Between the bisection steps I had a variety of other hangs and freezes not related to drm.
In the meantime I've also tested 4.2 kernel extensively and so far the original problem is gone. Occasionally (1 out of 20 resumes) instead of the KDE unlock screen the last console output is shown but no traces of error messages or backtraces. I leave it like that. Thx for your time anyway.