Message-ID: <423B01A3.8090501@gmail.com>
Date: Fri, 18 Mar 2005 17:28:19 +0100
From: =?ISO-8859-1?Q?Erik_Andr=E9n?= <erik.andren@gmail.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org
Subject: Suspend-to-disk woes
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1460
Lines: 28

Hello, I experienced a pretty nasty problem a couple of days back:

I ran 2.6.11-ck1 and built 2.6.11-ck2. The last thing I did before 
booting the new kernel was to suspend-to-disk the old kernel (something 
I usually do as I'm working on this laptop).
I ran the new kernel a couple of days and decided to boot the old kernel 
to do some performance tests. Imagine my dread as the old kernel instead 
of detecting that the system has booted another kernel just reloads the 
old suspend-to-disk image. The result is that after succesfully 
resuming, my harddrive goes bonkers and starts to work. After a couple 
of minutes the whole kernel hangs. I reboot and try to boot the -ck2 
kernel again only to find that the system complains as it finds missing 
nodes. The reisertools try to rebuild the system unsucessully. The 
--rebuild-tree parameter worked but a lot of files were still missing. 
In the end I had to reinstall the whole system as it went so unstable.

My question is: Why isn't there a check before resuming a 
suspend-to-disk image if the system has booted another kernel since the 
suspend to prevent this kind of hassle?
//Regards Erik Andr?n

Please cc me as I'm not on the lkml list yadda yadda

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/