Message-ID: <87d43wlrbu.fsf@spindle.srvr.nix>
Date:	Thu, 05 Nov 2009 19:11:33 +0000
From:	Nix <nix@...eri.org.uk>
To:	"TuxOnIce users' list" <tuxonice-users@...ts.tuxonice.net>
Cc:	Richard Purdie <rpurdie@...ys.net>,
	Linux-Kernel-Mailing-List <linux-kernel@...r.kernel.org>
Subject: Re: [TuxOnIce-users] An assortment of TuxOnIce resume panics on a Radeon KMS-running system in 2.6.31.5, lzo-related?

On 5 Nov 2009, Nigel Cunningham uttered the following:

>> It's odd that it manifested as a decompressor failure. I suppose if
>> something corrupts the data en route to or from the disk you might see
>> this? (wild speculation: maybe ordinary swapping happened on top of it,
>> though this seems rather unlikely).
>
> Well, if I've got an error in the algorithm for deciding which device to
> read/write next (this is what I've been modifying), it makes sense.

Ew. Yeah, that would cause all *sorts* of problems :)

I just turned off all but one swap partition and did some hibernate/resume
rounds. The first four worked fine, but on the fifth, well, at the end of
the cache restoration phase (tuxonice_userui had kicked up and was at 100%),
it said

'Read of data failed --- press SPACE to continue'

and when I did so:

kernel panic: Read chunk returned (1)
Reboot in 5 seconds...

(followed by, uh, no reboot)

Different symptoms, not sure if it's a different bug.

>> I'm impressed with how well ToI works, btw: it must have saved me about
>> twenty quid in power costs on this desktop box already and I've only
>> been using it for a couple of months. I was even more impressed that
>> nothing went wrong when I started using KMS, once I'd boosted the
>> reserved pages enough: took a while to figure out the cause of those
>> crashes, though. Maybe you should print a very loud message when the
>> number of reserved pages that haven't been consumed drops below some
>> smallish number, if it's detectable, 'cos right now exceeding it
>> generally results in a crash at suspension time and newbies like me
>> can't tell the cause easily...
>
> Not having a big enough allowance for drivers' memory allocations
> shouldn't cause problems. There's code in place to automatically back
> out and retry with a larger allocation and then abort if that doesn't
> work, and I've never had a report of it not working before now. (You'll
> see messages in dmesg if this happens). If you have userui enabled, it
> will also tell you it's restarting and why.

Er, yeah, well, sort of. What I saw was that immediately after 'Atomic
copy/restore' (just after the screen flashes to black as KMS is
suspended), the progress bar flips back to zero: it briefly states
'Preparing image, try I' (which isn't something it says at the start of
the hibernate run), and restarts the hibernation process: upon
resumption the extra_pages count has risen (to 34613 in my case). I'm
not sure 'Preparing image, try I' really says what's going on, not least
since it's actually try II :)

(I had a strange failure a couple of days ago where it did that and then
the second atomic copy/restore basically soft-froze: the keyboard worked
and tuxonice_userui responded to keys like R and ESC by changing the
state of the screen, but it never left what it claimed was atomic
copy/restore and aborts of hibernation never came back to me. After ten
minutes I just turned the box off...)


It's peculiar, too. I suspect I ran out of extra pages in this case, so
it auto-restarted, but what I see in /sys/power/tuxonice/debug_info is

- Extra pages    : 610 used/34613.

Now the kernel-configured extra page allowance is 20000, so it's plainly
boosted it... but to then use only 610 of them? Weird. I'm happy to
boost it (at least I am as long as these pages are only reserved during
hibernation), but still it's strange.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists