From: Martin Steigerwald <Martin@lichtvoll.de>
To: linux-pm@lists.linux-foundation.org
Cc: "TuxOnIce-devel" <tuxonice-devel@tuxonice.net>,
LKML <linux-kernel@vger.kernel.org>,
Nigel Cunningham <nigelc@hera.kernel.org>
Subject: Re: [linux-pm] unable to handle paging request at resume (was: Re: [TuxOnIce-devel] Nigel's current for-rafael queue)
Date: Sat, 2 Oct 2010 18:51:48 +0200 [thread overview]
Message-ID: <201010021851.49116.Martin@lichtvoll.de> (raw)
In-Reply-To: <201009300952.20273.Martin@lichtvoll.de>
[-- Attachment #1: Type: Text/Plain, Size: 7495 bytes --]
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@Lichtvoll.de>
> >
> > 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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2010-10-02 16:51 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-25 4:16 Nigel's current for-rafael queue Nigel Cunningham
2010-09-25 4:16 ` [PATCH 01/22] Record & display i/o speed post resume Nigel Cunningham
2010-09-25 4:16 ` [PATCH 02/22] Hibernation: Swap iteration functions Nigel Cunningham
2010-09-25 4:16 ` [PATCH 03/22] Hibernation: Move root_swap declaration Nigel Cunningham
2010-09-25 4:16 ` [PATCH 04/22] Hibernation: Add mass swap allocation routine Nigel Cunningham
2010-09-25 4:16 ` [PATCH 05/22] Hibernation: Switch to preallocating swap Nigel Cunningham
2010-09-25 21:24 ` Rafael J. Wysocki
2010-09-25 21:32 ` Nigel Cunningham
2010-09-25 22:22 ` Rafael J. Wysocki
2010-09-25 4:16 ` [PATCH 06/22] Hiberation: Fix speed display Nigel Cunningham
2010-09-25 4:16 ` [PATCH 07/22] Hibernation: Generic extents support Nigel Cunningham
2010-09-25 4:16 ` [PATCH 08/22] Hibernation: Iterate over sectors not swap entries Nigel Cunningham
2010-09-25 4:16 ` [PATCH 09/22] Hibernation: Stop passing swap_map_handle struct Nigel Cunningham
2010-09-25 4:16 ` [PATCH 10/22] Hibernation: Stop passing bio_chain around Nigel Cunningham
2010-09-25 4:16 ` [PATCH 11/22] Hibernation: Move block i/o fns to block_io.c Nigel Cunningham
2010-09-25 4:16 ` [PATCH 12/22] Hibernation: Partial page I/O support Nigel Cunningham
2010-09-25 4:16 ` [PATCH 13/22] Hibernation: Extent save/load routines Nigel Cunningham
2010-09-25 22:12 ` Rafael J. Wysocki
2010-09-25 4:16 ` [PATCH 14/22] Hibernation: Store block extents at start of image Nigel Cunningham
2010-09-25 4:16 ` [PATCH 15/22] Hibernation: Use block extents for reading image Nigel Cunningham
2010-09-25 4:16 ` [PATCH 16/22] Remove first_sector from swap_map_handle Nigel Cunningham
2010-09-25 4:16 ` [PATCH 17/22] Hibernation: Replace bio chain Nigel Cunningham
2010-09-25 4:17 ` [PATCH 18/22] Hibernation: Remove swap_map_pages Nigel Cunningham
2010-09-25 4:17 ` [PATCH 19/22] Hibernation: Remove wait_on_bio_chain result Nigel Cunningham
2010-09-25 4:17 ` [PATCH 20/22] Hibernation: Prepare for handle.cur removal Nigel Cunningham
2010-09-25 4:17 ` [PATCH 21/22] Hibernation: Remove swap_map structure Nigel Cunningham
2010-09-25 4:17 ` [PATCH 22/22] Hibernation: Remove now-empty routines Nigel Cunningham
2010-09-25 15:04 ` [linux-pm] Nigel's current for-rafael queue Martin Steigerwald
2010-09-25 21:21 ` Nigel Cunningham
2010-09-25 22:19 ` Rafael J. Wysocki
2010-09-25 22:33 ` Nigel Cunningham
2010-09-25 22:36 ` Rafael J. Wysocki
2010-09-28 10:34 ` [TuxOnIce-devel] " Martin Steigerwald
2010-09-30 7:52 ` unable to handle paging request at resume (was: Re: [TuxOnIce-devel] Nigel's current for-rafael queue) Martin Steigerwald
2010-10-02 16:51 ` Martin Steigerwald [this message]
2010-09-28 19:45 ` [TuxOnIce-devel] Nigel's current for-rafael queue Martin Steigerwald
2010-09-28 21:25 ` Nigel Cunningham
2010-09-30 7:56 ` Martin Steigerwald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201010021851.49116.Martin@lichtvoll.de \
--to=martin@lichtvoll.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=nigelc@hera.kernel.org \
--cc=tuxonice-devel@tuxonice.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).