On 14.04.2015, John Schmitt wrote: > Using maxcpus=1 in your grub command line is an ugly work-around, I agree. It simply doesn't work.. > However, if your machine is waking up from sleep or hibernate, using > maxcpus=1 on your grub command line is going to apply only until your > frozen system image (that is, the image of your running kernel that was > running on all CPUs) is loaded and run. That is my understanding of the > mechanism. ..exactly because of what you describe here. You're completely right. > The bug appears to be in the process of unfreezing your system > image with multiple processors. Resuming from S2D fails about 3-4 times out of 10, so it could be a race condition somewhere in the SMP or timer-related code, which I'm not at all familiar with. There are quite a few bug reports out there reporting different resume hangs which also resolve by passing maxcpus=1 to the kernel. Didn't try with sched-clock ticks on (CONFIG_NO_HZ=n), and I'm afraid I won't debug this issue any further, since every failure to resume causes fs corruption. On that account, a "git bisect" is not really feasible either. So most probably I'll leave it at that and have to accept that S2D does not work properly here (which is really annoying when you have opened a lot of papers and documents while writing e.g. an article and would like to continue your work where you left the evening before..). -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
