linux-kernel - Re: [TuxOnIce-users] An assortment of TuxOnIce resume panics on a Radeon KMS-running system in 2.6.31.5, lzo-related?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 05 Nov 2009 11:34:42 +1100
From:	Nigel Cunningham <ncunningham@...a.org.au>
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?

Hi.

Nix wrote:
> On 4 Nov 2009, Nigel Cunningham told this:
> 
>> Hi.
>>
>> Thanks for your bug report.
>>
>> I'd say it's a bug in the TuxOnIce code. How recent a version are you
>> running? (It's been a while since I bumped the version number, so saying
>> 3.0.1 doesn't mean much any more). Is it recent git?
> 
> 4eddd0d169ddd285b9d7afdcbbfc1a85b870f5ea from your tuxonice 2.6.31 tree,
> (merged, as mentioned, with Dave Airlie's drm-next branch).
> 
> I think that's the latest, right?

No, it's not. But it's prior to where I committed the swap priority
support changes that I was thinking were the cause of your issue.

>> Would you also let me know how your storage is configured - file
>> allocator? swap allocator? More than one swap device? priorities? (I've
> 
> Swap allocator, striped equal-priority swap on two physical disks
> (otherwise occupied entirely with an md1 array):

Okay. Would you be able to try with just one swap device enabled
(temporarily) and see if that makes a difference? It should work with
two at the commit you mentioned, but perhaps I'm forgetting something.

>              total       used       free     shared    buffers     cached
> Mem:      12301216    1238928   11062288          0     111228     440956
> -/+ buffers/cache:     686744   11614472
> Swap:     25189904          0   25189904
> mutilate 2 ~% cat /proc/swaps
> Filename                                Type            Size    Used    Priority
> /dev/sda2                               partition       12594952        0       0
> /dev/sdb2                               partition       12594952        0       0
> 
> (yes, I know it was mad to define swap as 2xRAM on this machine, but I
> have disk space coming out of my ears and have no idea what to do with it :) )
> 
> Swap was barely in use when I suspended (and it's even less in use now
> relatively recently post-reboot).
> 
>> been doing work in this area recently, and so suspect that it might be
>> the cause).
> 
> 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.

> 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.

Regards,

Nigel
--
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/