Re: [linux-pm] intermittent suspend problem again

Re: [linux-pm] intermittent suspend problem again

[Ferenc Wagner]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> On Saturday 28 November 2009, Ferenc Wagner wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>> 
>>> On Wednesday 18 November 2009, Ferenc Wagner wrote:
>>>
>>>> Ferenc Wagner <wferi@niif.hu> writes:
>>>> 
>>>>> Since I've instrumented s2disk and the hibernation path, no freeze
>>>>> happened during hibernating the machine.
>>>> 
>>>> Not until I removed the delays from hibernation_platform_enter(), which
>>>> were put there previously to get step-by-step feedback.  Removing them
>>>> again resulted in a freeze in short course, maybe just two hibernations
>>>> later.  The instrumentation shows it stuck in dpm_suspend_start(PMSG_HIBERNATE).
>>>> Does it mean that some device driver is at fault?
>>>
>>> A driver or one of the platform hooks.
>>>
>>>> I'll check if it always fails at the same point (although tracing into
>>>> dpm_suspend_start isn't pure fun because of the multitude of devices it
>>>> loops over).  Is there any way to get printk output from that phase?
>>>
>>> Compile with CONFIG_PM_VERBOSE (it does mean exactly that).
>> 
>> The last message now was:
>> 
>> e100: 0000:02:08.0: hibernate, may wakeup
>> 
>> Looks like hibernating the e100 driver is unstable.
>
> Can you verify that by trying to hibernate without the e100 driver?

Not really, as I still can't reliable reproduce the issue.  Since I'm
running with suspend loglevel = 8, it's happened only twice (in a row),
with seemingly exact same console output.  Some earlier freezes also
happened in dpm_suspend_start, at least.  However, I can certainly add
e100 to SUSPEND_MODULES under /etc/pm/config.d, and continue running
with that.  Or I can try stress-testing the module, but not sure, how.
Interestingly, git log v2.6.31.. -- e100.c is tiny, but 8fbd962e affects
the suspend/resume routines through e100_up.  This could explain the
timing-sensitive nature of the issue.  I took the liberty to change the
Cc list, maybe linux-netdev can lend us a hand.
-- 
Regards,
Feri.

Re: [linux-pm] intermittent suspend problem again

[Ferenc Wagner]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> On Tuesday 01 December 2009, Ferenc Wagner wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>> 
>>> On Sunday 29 November 2009, Ferenc Wagner wrote:
>>>
>>>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>>> 
>>>>> On Saturday 28 November 2009, Ferenc Wagner wrote:
>>>>>
>>>>>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>>>>> 
>>>>>>> Compile with CONFIG_PM_VERBOSE (it does mean exactly that).
>>>>>> 
>>>>>> The last message now was:
>>>>>> 
>>>>>> e100: 0000:02:08.0: hibernate, may wakeup
>>>>>> 
>>>>>> Looks like hibernating the e100 driver is unstable.
>>>>>
>>>>> Can you verify that by trying to hibernate without the e100 driver?
>>>> 
>>>> Not really, as I still can't reliable reproduce the issue.  Since I'm
>>>> running with suspend loglevel = 8, it's happened only twice (in a row),
>>>> with seemingly exact same console output.  Some earlier freezes also
>>>> happened in dpm_suspend_start, at least.  However, I can certainly add
>>>> e100 to SUSPEND_MODULES under /etc/pm/config.d, and continue running
>>>> with that.
>>>
>>> That's what I'd do.
>> 
>> That worked out mosty OK (no freeze in quite some hibernation cycles),
>> but I'm continuing testing it.
>
> Great, please let me know how it works out.

Will do.  On the negative side, this tends to confuse NetworkManager.

>> On the other hand, I reverted 8fbd962e3, recompiled and replaced the
>> module, and got the freeze during hibernation.  And that was the bulk of
>> the changes since 2.6.31...  I'll revert the rest and test again, but
>> that seems purely cosmetic, so no high hopes.
>> 
>>> In addition to that, you can run multiple hibernation/resume cycles in
>>> a tight loop using the RTC wakealarm.
>> 
>> I'll do so, as soon as I find a way to automatically supply the dm-crypt
>> passphrase... or even better, learn to hibernate to ramdisk from the
>> initramfs. :)
>
> Well, you don't need to use swap encryption for _testing_. :-)

I use partition encryption, everything except for /boot is encrypted.
Apropos: does s2disk perform encryption with a temporary key even if I
don't supply and RSA key, to protect mlocked application data from being
present in the swap after restore?
-- 
Thanks,
Feri.

Re: [linux-pm] intermittent suspend problem again

[Rafael J. Wysocki]

On Tuesday 01 December 2009, Ferenc Wagner wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Tuesday 01 December 2009, Ferenc Wagner wrote:
> >> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >> 
> >>> On Sunday 29 November 2009, Ferenc Wagner wrote:
> >>>
> >>>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >>>> 
> >>>>> On Saturday 28 November 2009, Ferenc Wagner wrote:
> >>>>>
> >>>>>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >>>>>> 
> >>>>>>> Compile with CONFIG_PM_VERBOSE (it does mean exactly that).
> >>>>>> 
> >>>>>> The last message now was:
> >>>>>> 
> >>>>>> e100: 0000:02:08.0: hibernate, may wakeup
> >>>>>> 
> >>>>>> Looks like hibernating the e100 driver is unstable.
> >>>>>
> >>>>> Can you verify that by trying to hibernate without the e100 driver?
> >>>> 
> >>>> Not really, as I still can't reliable reproduce the issue.  Since I'm
> >>>> running with suspend loglevel = 8, it's happened only twice (in a row),
> >>>> with seemingly exact same console output.  Some earlier freezes also
> >>>> happened in dpm_suspend_start, at least.  However, I can certainly add
> >>>> e100 to SUSPEND_MODULES under /etc/pm/config.d, and continue running
> >>>> with that.
> >>>
> >>> That's what I'd do.
> >> 
> >> That worked out mosty OK (no freeze in quite some hibernation cycles),
> >> but I'm continuing testing it.
> >
> > Great, please let me know how it works out.
> 
> Will do.  On the negative side, this tends to confuse NetworkManager.
> 
> >> On the other hand, I reverted 8fbd962e3, recompiled and replaced the
> >> module, and got the freeze during hibernation.  And that was the bulk of
> >> the changes since 2.6.31...  I'll revert the rest and test again, but
> >> that seems purely cosmetic, so no high hopes.
> >> 
> >>> In addition to that, you can run multiple hibernation/resume cycles in
> >>> a tight loop using the RTC wakealarm.
> >> 
> >> I'll do so, as soon as I find a way to automatically supply the dm-crypt
> >> passphrase... or even better, learn to hibernate to ramdisk from the
> >> initramfs. :)
> >
> > Well, you don't need to use swap encryption for _testing_. :-)
> 
> I use partition encryption, everything except for /boot is encrypted.

If /boot is big enough, you could use a swap file in /boot for the testing.

> Apropos: does s2disk perform encryption with a temporary key even if I
> don't supply and RSA key, to protect mlocked application data from being
> present in the swap after restore?

It can do that, but you need to provide a key during suspend and resume.

Otherwise it doesn't use a random key, because it would have to store it in
the clear in the image header.

Thanks,
Rafael

s2disk encryption was Re: intermittent suspend problem again

[Pavel Machek]

Hi!

> > >> On the other hand, I reverted 8fbd962e3, recompiled and replaced the
> > >> module, and got the freeze during hibernation.  And that was the bulk of
> > >> the changes since 2.6.31...  I'll revert the rest and test again, but
> > >> that seems purely cosmetic, so no high hopes.
> > >> 
> > >>> In addition to that, you can run multiple hibernation/resume cycles in
> > >>> a tight loop using the RTC wakealarm.
> > >> 
> > >> I'll do so, as soon as I find a way to automatically supply the dm-crypt
> > >> passphrase... or even better, learn to hibernate to ramdisk from the
> > >> initramfs. :)
> > >
> > > Well, you don't need to use swap encryption for _testing_. :-)
> > 
> > I use partition encryption, everything except for /boot is encrypted.
> 
> If /boot is big enough, you could use a swap file in /boot for the testing.
> 
> > Apropos: does s2disk perform encryption with a temporary key even if I
> > don't supply and RSA key, to protect mlocked application data from being
> > present in the swap after restore?
> 
> It can do that, but you need to provide a key during suspend and resume.
> 
> Otherwise it doesn't use a random key, because it would have to store it in
> the clear in the image header.

I believe it can use random key, stored in clear in image
header. Reason is... image header is easier to overwrite than removing
whole image.

That was original motivation for encryption... not having to overwrite
swap data with zeros.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html