lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 4 Oct 2010 10:47:15 +0200
From:	Martin Steigerwald <Martin@...htvoll.de>
To:	linux-pm@...ts.linux-foundation.org
Cc:	Nigel Cunningham <nigelc@...a.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"TuxOnIce-devel" <tuxonice-devel@...onice.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [linux-pm] Swsusp patches applied to suspend-2.6#linux-next

Am Montag 04 Oktober 2010 schrieb Martin Steigerwald:
> Am Samstag 02 Oktober 2010 schrieb Martin Steigerwald:
> > Am Montag 27 September 2010 schrieb Nigel Cunningham:
> > > Hi again Rafael.
> > 
> > Hi Nigel and Rafael,
> > 
> > > As discussed, here are the patches, modified to apply against your
> > > current linux-next tree. A new first patch splits compression
> > > support out into its own file, removing the need to have two
> > > versions of the load_image and save_image routines, minimising the
> > > changes to the remainder of the patches and making things cleaner
> > > than would otherwise be the case.
> > > 
> > > On my laptop, single-threaded compression actually slows writing
> > > down from 175MB/s to around 100-120MB/s (depending on how well the
> > > image compresses). Reading speed improves from 218MB/s to around
> > > 245MB/s. I expect that multithreaded writing would bring the
> > > writing (and reading) speeds back up. It's on my swsusp to do list
> > > :)
> > 
> > Testing this now
> > (2.6.36-rc4-tp42-suspend-next-vmembase-0-00253-gab9b069- dirty).
> 
> Two times I had the rather strange issue that the machine booted
> freshly instead of resuming! First I thought I maybe didn't wait until
> the image was saved, before turning the laptop off. But now it
> happened a second time and also the ThinkPad T42 has a battery in it,
> thus it should always be able to complete writing the image.
> 
> For resuming I found this in the syslog:
> 
> Oct  4 09:19:10 shambhala kernel: end_request: I/O error, dev fd0,
> sector 0
> Oct  4 09:19:10 shambhala kernel: PM: Starting manual resume from disk
> Oct  4 09:19:10 shambhala kernel: PM: Resume from partition 8:2
> Oct  4 09:19:10 shambhala kernel: PM: Checking hibernation image.
> Oct  4 09:19:10 shambhala kernel: PM: Error -22 checking image file
> Oct  4 09:19:10 shambhala kernel: PM: Resume from disk failed.
> Oct  4 09:19:10 shambhala kernel: PM: Marking nosave pages:
> 000000000009f000 - 0000000000100000
> Oct  4 09:19:10 shambhala kernel: PM: Basic memory bitmaps created
> Oct  4 09:19:10 shambhala kernel: PM: Basic memory bitmaps freed
> 
> What does error -22 mean?
> 
> For hibernating:
> 
> Oct  4 00:13:09 shambhala ifplugd(eth0)[15127]: Link beat lost.
> Oct  4 00:13:10 shambhala NetworkManager[2146]: <info> (eth0): carrier
> now OFF (device state 1)
> Oct  4 00:13:12 shambhala ifplugd(eth0)[15127]: Exiting.
> Oct  4 00:13:14 shambhala postfix/master[2589]: reload -- version
> 2.7.1, configuration /etc/postfix
> Oct  4 00:13:14 shambhala dhclient: Internet Systems Consortium DHCP
> Client 4.1.1-P1
> Oct  4 00:13:14 shambhala dhclient: Copyright 2004-2010 Internet
> Systems Consortium.
> Oct  4 00:13:14 shambhala dhclient: All rights reserved.
> Oct  4 00:13:14 shambhala dhclient: For info, please visit
> https://www.isc.org/software/dhcp/
> Oct  4 00:13:14 shambhala dhclient:
> Oct  4 00:13:14 shambhala dhclient: Listening on
> LPF/eth0/00:11:25:46:ec:a5
> Oct  4 00:13:14 shambhala dhclient: Sending on
> LPF/eth0/00:11:25:46:ec:a5
> Oct  4 00:13:14 shambhala dhclient: Sending on   Socket/fallback
> Oct  4 00:13:15 shambhala dhclient: DHCPRELEASE on eth0 to 10.0.0.9
> port 67
> Oct  4 00:13:18 shambhala kernel: PM: Marking nosave pages:
> 000000000009f000 - 0000000000100000
> Oct  4 00:13:18 shambhala kernel: PM: Basic memory bitmaps created
> Oct  4 00:13:18 shambhala kernel: PM: Syncing filesystems ... done.
> Oct  4 09:19:10 shambhala kernel: imklog 4.6.4, log source = /proc/kmsg
> started.
> Oct  4 09:19:10 shambhala rsyslogd: [origin software="rsyslogd"
> swVersion="4.6.4" x-pid="1964" x-info="http://www.rsyslog.com"]
> (re)start Oct  4 09:19:10 shambhala kernel: r hub
> Oct  4 09:19:10 shambhala kernel: usbcore: registered new device driver
> usb
> 
> Which is not complete. It seems the last log messages prior to
> hibernating have not fully been written by rsyslog.
> 
> Whats going on there? I didn't see this with Nigel's patches without
> the readahead patch. But then now I am testing suspend next + his
> patches, which may well contain other patches, as far as I understand.
> 
> Any change to test with some newer state of suspend-next?
> 
> Rafael did you integrate Nigel's patches in your tree?

Hmmm, there might be a similarity  between these:

In both times it happened after I made at least one suspend to ram cycle. 
Yesterday I plugged the laptop to my hi-fi and forget to switch on the 
power extension lead. Thus KDE's Power management suspended to RAM after 
15 minutes of inactivity.

So maybe suspend to RAM interferes somehow.

Additionally I tend to get Radeon DRM KMS graphics corruption with that 
kernel. And even a complete lockup once.

I think I will try 2.6.35-rc5 or whatever is latest with Nigel's patches 
from Nigel's for-rafael branch in order to isolate whether what I see is 
an issue with Nigel's patches or with any of the other stuff in suspend-
next.

Unless to have some newer stuff for me to test with.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)

Powered by blists - more mailing lists