Messages in this thread | | | Subject | Re: [TuxOnIce-users] An assortment of TuxOnIce resume panics on a Radeon KMS-running system in 2.6.31.5, lzo-related? | From | Nix <> | Date | Thu, 05 Nov 2009 19:11:33 +0000 |
| |
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.
| |