I have the impression that causing something to wait just before restoring the display will fix this. I hope this new bugreport will make it easier for whoever wrote the multi-threaded decompression code to find the bug. Note: I previously reported this as problem that required acpi=off to resume in Bug #806315 Perhaps something needs to be syncrhonised before the display is finally restored. The fact that maxcpus=1 prevents resume crashing seems to imply that the multi-threading code in resume has a bug. Resume should always work after pm-hibernate, without requiring maxcpus=1
Sometimes resumes successfully sometimes crashes (just before final screen refresh), after indicating decompression using 3 threads.Īlways resumes successfully, after decompressing with 1 thread. Resuming successfully with maxcpu=1 happens 100% of the time. (I have had the same problem with all recent kernels.)įailing to resume after hibernate is random - but more often than not it fails. Version-Release number of selected component (if applicable): Previously I used acpi=off to enable successful resume, but since maxcpus=1 is more specific and seems to make resume totally reliable I thought I should start a new bugreport. Without maxcpus=1 I find that resume works fine until just before the desktop is refreshed (100% decompression) and after that it just shuts down automatically and does a full reboot - but with no record of what went wrong. So I tried using maxcpus=1 for resume from hibernate, and that so far totally reliably allows resume to complete. I used to do this, successfully with acpi=off, but then I discovered that one effect of that was using only one cpu during resume.
Resume/Thaw however crashes unless I add an extra parameter to grub boot menu after pm-hibernate. Pm-hibernate now regularly shuts down for me, and has done since about March 2012.
0 kommentar(er)
