(In reply to comment #31)
> Now that the proper fallback handling is on track, have we attempted to
> bisect where the underlying root-cause (ring init failure on resume) was
> made much worse? I guess on some older kernels this worked better.
I am afraid this is close to impossible.
The frequency of the problem happening fluctuates *a lot* between different kernel.
- I am pretty sure that I've *never ever* seen it happening on 3.7 kernel, and it has been excercised a lot on the system in question
- Around 3.13, this seems to happen in a rather "time to time" manner (say once in 40 resumes, but with rather large standard deviation)
- with current Linus' tree and with the drm tree as well, this happens super-reliably on almost every resume from hibernation
I don't have enough data from the kernels in between to be able claim the ratio reliably.
I am afraid this pretty much implies that bisecting this reliably would consume incredible amount of time and might still produce unreliable result.
(In reply to comment #31)
> Now that the proper fallback handling is on track, have we attempted to
> bisect where the underlying root-cause (ring init failure on resume) was
> made much worse? I guess on some older kernels this worked better.
I am afraid this is close to impossible.
The frequency of the problem happening fluctuates *a lot* between different kernel.
- I am pretty sure that I've *never ever* seen it happening on 3.7 kernel, and it has been excercised a lot on the system in question
- Around 3.13, this seems to happen in a rather "time to time" manner (say once in 40 resumes, but with rather large standard deviation)
- with current Linus' tree and with the drm tree as well, this happens super-reliably on almost every resume from hibernation
I don't have enough data from the kernels in between to be able claim the ratio reliably.
I am afraid this pretty much implies that bisecting this reliably would consume incredible amount of time and might still produce unreliable result.