nix at esperi
Nov 5, 2009, 11:11 AM
Post #5 of 5
(40 views)
Permalink
|
|
Re: [TuxOnIce-users] An assortment of TuxOnIce resume panics on a Radeon KMS-running system in 2.6.31.5, lzo-related?
[In reply to]
|
|
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[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
