Re: Reboot after hibernate failed to restore to previous session.
On 04/14/2015 04:30 PM, Rick Stevens wrote:
On 04/14/2015 02:18 PM, Heinz Diehl wrote:
> 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..).
Can you check and see what your actual swap space is? The new Fedora
seems to set up a swap space that's 50% of your memory space. If that's
what you've got, then a suspend to disk is going to die as it uses swap
to save an image of your memory and all you have is half the space you
need. Bad news.
I have 16GB swap, and 8GB RAM.
So, what you suspect is not the case.