Hi I hope this information is sufficient to debug my problem, though itunfortunately is somewhat incomplete. I took two pictures of the OOPSwith my mobile phone, but unfortunately the picture of the upper part isso blurred that it is unreadable. Apparently I have to be in a hurrygetting out of the door for this to happen. Here is what I got from thelower part Call Trace: __blkdev_put swsusp_write hibernate state_store state_store state_store kobj_attr_store sysfs_write_file sysfs_write_file vfs_write sys_write sysenter_do_callCode: ......EIP: [<...>] iput---[ end trace ........................... ]--- There is a lot of blanks here that I should be able provide on requestas well. The problem occured in my third attempt in quick succession to suspendto disk. The first two did not succeed due to insufficient free swap. Igot 768 MB ram and a ~1 GB swap partition. I believe top said somethinglike Mem: 3xxxxxk used and Swap: 6xxxxxk used before the third attemptto suspend to disk. The system that was running had at least one successful suspend to diskand restore the day before and I also use it sucessfully on a dailybasis. I believe I've seen the same crash before with a 2.6.27 or earlierkernel, but I was in a hurry getting out of the door back then as I washere. Circumstances was the same though, with already successful suspendto disk and the crash appearing during second or third attempt tosuspend to disk in quick succession. I guess I should be able to reproduce the crash with some efforts, butI'd like to hear your thoughts on this before I do that. Filesystems are reiserfs. Simon Holm Thøgersen _______________________________________________linux-pm mailing listlinux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.linux-foundation.org/mailman/listinfo/linux-pm
