Am Donnerstag 30 September 2010 schrieb Martin Steigerwald: > Hi Nigel and Rafael, > > Am Dienstag 28 September 2010 schrieb Martin Steigerwald: > > Am Samstag 25 September 2010 schrieb Nigel Cunningham: > > > Hi Rafael. > > > > > > Please find attached a slightly updated version of the patchset I > > > sent a few months ago. The main change is that I've prepended and > > > additional patch which lets the user see the speed at which the > > > image is being read and written. This is accomplished by recording > > > the MB/s in a single byte in the image header, and using a couple > > > of __nosavedata variables to get the data back through the atomic > > > restore. I realise the char limits us to 255MB/s at the moment. In > > > future patches, I intend to address this by storing the data in a > > > 'proper' image header (it's a real problem - TuxOnIce reads and > > > writes on the same set up at speeds around 250MB/s). > > > > > > Results on my Dell XPS M1530, which has an SSD hard drive are: > > > > > > With just patch 1 applied: > > > Attempt 1: Write 74MB/s; Read 52MB/s > > > Attempt 2: Write 68MB/s; Read 52MB/s > > > Attempt 3: Write 73MB/s; Read 53MB/s > > > > > > With the whole sequence: > > > Attempt 1: Write 181MB/s; Read 52MB/s > > > Attempt 2: Write 156MB/s; Read 53MB/s > > > Attempt 3: Write 160MB/s; Read 52MB/s > > > > Is doesn't get much stabler than > > > > shambhala:~> grep "PM: Image.*at " /var/log/syslog > > Sep 28 11:32:06 shambhala kernel: PM: Image written at 63 MB/s. > > Sep 28 11:32:06 shambhala kernel: PM: Image read at 32 MB/s. > > Sep 28 11:35:00 shambhala kernel: PM: Image written at 65 MB/s. > > Sep 28 11:35:00 shambhala kernel: PM: Image read at 32 MB/s. > > Sep 28 11:38:43 shambhala kernel: PM: Image written at 65 MB/s. > > Sep 28 11:38:43 shambhala kernel: PM: Image read at 33 MB/s. > > Sep 28 11:41:15 shambhala kernel: PM: Image written at 66 MB/s. > > Sep 28 11:41:15 shambhala kernel: PM: Image read at 33 MB/s. > > Sep 28 11:42:57 shambhala kernel: PM: Image written at 66 MB/s. > > Sep 28 11:42:57 shambhala kernel: PM: Image read at 34 MB/s. > > Sep 28 11:45:16 shambhala kernel: PM: Image written at 66 MB/s. > > Sep 28 11:45:16 shambhala kernel: PM: Image read at 34 MB/s. > > Sep 28 12:19:21 shambhala kernel: PM: Image written at 66 MB/s. > > Sep 28 12:19:21 shambhala kernel: PM: Image read at 35 MB/s. > > Sep 28 12:21:35 shambhala kernel: PM: Image written at 65 MB/s. > > Sep 28 12:21:35 shambhala kernel: PM: Image read at 35 MB/s. > > Sep 28 12:23:18 shambhala kernel: PM: Image written at 65 MB/s. > > Sep 28 12:23:18 shambhala kernel: PM: Image read at 35 MB/s. > > Sep 28 12:25:23 shambhala kernel: PM: Image written at 64 MB/s. > > Sep 28 12:25:23 shambhala kernel: PM: Image read at 36 MB/s. > > Sep 28 12:26:55 shambhala kernel: PM: Image written at 65 MB/s. > > Sep 28 12:26:55 shambhala kernel: PM: Image read at 37 MB/s. > > Sep 28 12:28:28 shambhala kernel: PM: Image written at 65 MB/s. > > Sep 28 12:28:28 shambhala kernel: PM: Image read at 37 MB/s. > > > > many attempts. > > > > So - without readahead patch for now - > > > > Tested-By: Martin Steigerwald <Martin@xxxxxxxxxxxx> > > > > on 2.6.36-rc5. > > Well probably it couldn't get more stable than that, but it was able to > get more unstable: > > This morning I got a unable to handle paging request after switching on > my kernel suspended ThinkPad T42. With exactly that kernel with all of > Nigel's patches except for the readahead one. > > http://martin-steigerwald.de/tmp/suspend-patches/unable-to-handle-pagin > g- request-at-resume/ > > IMG_3897.JPG is what I saw first. IMG_3900.JPG came after I pressed > the power button to swich off the machine in order to cold reboot it. > As I left the machine unattended during resume, I did not see what > happened before this. > > On the next attempt the laptop just rebootet instead of trying to > resume from the saved image again. > > I grepped stuff in syslog and found that it seemed to have been able to > write some stuff into syslog prior to the trace: > > Sep 30 00:00:34 shambhala kernel: PM: Marking nosave pages: > 000000000009f000 - 0000000000100000 > Sep 30 00:00:34 shambhala kernel: PM: Basic memory bitmaps created > Sep 30 00:00:34 shambhala kernel: PM: Syncing filesystems ... done. > Sep 30 09:13:34 shambhala kernel: Freezing user space processes ... > 00:02:00.0: restoring config space at offset > 0x1 (was 0x2100107, writing 0x2100007) > Sep 30 09:13:34 shambhala kernel: yenta_cardbus 0000:02:00.1: restoring > config space at offset 0xf (was 0x3c0020 > b, writing 0x5c0020b) > Sep 30 09:13:34 shambhala kernel: yenta_cardbus 0000:02:00.1: restoring > config space at offset 0x3 (was 0x824008 > , writing 0x82a810) > Sep 30 09:13:34 shambhala kernel: yenta_cardbus 0000:02:00.1: restoring > config space at offset 0x1 (was 0x210010 > 7, writing 0x2100007) > Sep 30 09:13:34 shambhala kernel: e1000 0000:02:01.0: BAR 0: set to > [mem 0xc0220000-0xc023ffff] (PCI address [0x > c0220000-0xc023ffff] > Sep 30 09:13:34 shambhala kernel: e1000 0000:02:01.0: BAR 1: set to > [mem 0xc0200000-0xc020ffff] (PCI address [0x > c0200000-0xc020ffff] > Sep 30 09:13:34 shambhala kernel: e1000 0000:02:01.0: BAR 2: set to [io > 0x8000-0x803f] (PCI address [0x8000-0x8 > 03f] > Sep 30 09:13:34 shambhala kernel: e1000 0000:02:01.0: restoring config > space at offset 0xf (was 0xff0100, writin > g 0xff010b) > Sep 30 09:13:34 shambhala kernel: e1000 0000:02:01.0: restoring config > space at offset 0x3 (was 0x0, writing 0x4 > 008) > Sep 30 09:13:34 shambhala kernel: e1000 0000:02:01.0: restoring config > space at offset 0x1 (was 0x2300000, writi > ng 0x2300117) > Sep 30 09:13:34 shambhala kernel: PM: early restore of devices complete > after 31.408 msecs > Sep 30 09:13:34 shambhala kernel: BUG: Bad page state in process echo > pfn:73302 > Sep 30 09:13:34 shambhala kernel: page:c24d8040 count:0 mapcount:1 > mapping:(null) index:0x9bf5 > Sep 30 09:13:34 shambhala kernel: page flags: > 0x80100078(uptodate|dirty| lru|active|swapbacked) > Sep 30 09:13:34 shambhala kernel: Pid: 18599, comm: echo Not tainted > 2.6.36-rc5-tp42-hiber-wri-accel-vmembase-0- > 00133-g3394a84-dirty #1 > Sep 30 09:13:34 shambhala kernel: Call Trace: > Sep 30 09:13:34 shambhala kernel: [<c10ac8d3>] bad_page+0x83/0xd0 > Sep 30 09:13:34 shambhala kernel: [<c10ad541>] > free_pages_prepare+0x131/0x170 > Sep 30 09:13:34 shambhala kernel: [<c10aef98>] > free_hot_cold_page+0x28/0x140 > Sep 30 09:13:34 shambhala kernel: [<c10af0e5>] __free_pages+0x35/0x40 > Sep 30 09:13:34 shambhala kernel: [<c10727e6>] swsusp_free+0xa6/0x100 > Sep 30 09:13:34 shambhala kernel: [<c10719f3>] > hibernation_snapshot+0x123/0x290 > Sep 30 09:13:34 shambhala kernel: [<c1070b76>] ? > freeze_processes+0x56/0xa0 > Sep 30 09:13:34 shambhala kernel: [<c1071c45>] hibernate+0xe5/0x210 > Sep 30 09:13:34 shambhala kernel: [<c10704f0>] ? state_store+0x0/0xb0 > Sep 30 09:13:34 shambhala kernel: [<c1070596>] state_store+0xa6/0xb0 > Sep 30 09:13:34 shambhala kernSep 30 09:25:08 shambhala kernel: imklog > 4.6.4, log source = /proc/kmsg started. I didn't see this one again so far. Still I wonder what that might have been. Any hints? Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
