From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755608Ab2CLNii (ORCPT ); Mon, 12 Mar 2012 09:38:38 -0400 Received: from mout6.freenet.de ([195.4.92.96]:57135 "EHLO mout6.freenet.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755395Ab2CLNih (ORCPT ); Mon, 12 Mar 2012 09:38:37 -0400 Message-ID: <4F5DFBD5.90205@01019freenet.de> Date: Mon, 12 Mar 2012 14:36:21 +0100 From: Andreas Hartmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Firefox/10.0.2 SeaMonkey/2.7.2 MIME-Version: 1.0 To: Jiri Kosina CC: richard -rw- weinberger , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org Subject: Re: Corrupted files after suspend to disk References: <201202162251.47063.rjw@sisk.pl> <201202170016.14313.rjw@sisk.pl> <4F574113.8030906@01019freenet.de> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jiri Kosina schrieb: > On Wed, 7 Mar 2012, Andreas Hartmann wrote: > >>> On my system kernel suspend *seems* to work. >>> I've seen no corrupted files so far. >>> >>> But sometimes the resume is failing. (One out of 5 resumes fails). >>> I was unable to get any kernel output. >>> >>> So I'm not sure whether this is the same issue >>> or another one. :-\ >> >> I'm pretty sure that this is the same issue. What you are telling >> correlates with my research here. >> I even got resumes where the machine came up again, but nothing could be >> done (it wasn't possible to switch of the password secured screen saver >> any more - login at the shell wasn't possible, too, because the started >> bash crashed), > > This is happening to me as well. Something like 1 resume out of 5 goes > wrong this very same way. > > This is thinkpad x200s. > > All the userspace is segfaulting all over the place (most frequently in > libselinux for some reason). > > I am not able to verify the 'drop_caches' theory, as I can't invoke a > single command that wouldn't crash. I'm checking after every resume for broken files (via md5sum check). If you are lucky, only irrelevant files are damaged. But you are right, with 3.2 (or was it 3.3?), the drop_caches theory doesn't work at all for me (if it isn't by chance). Regards, Andreas