Crash during suspend to disk

Crash during suspend to disk

[Simon Holm Thøgersen]

Hi

I hope this information is sufficient to debug my problem, though it
unfortunately is somewhat incomplete. I took two pictures of the OOPS
with my mobile phone, but unfortunately the picture of the upper part is
so blurred that it is unreadable. Apparently I have to be in a hurry
getting out of the door for this to happen. Here is what I got from the
lower 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_call
Code: ......
EIP: [<...>] iput
---[ end trace ........................... ]---

There is a lot of blanks here that I should be able provide on request
as well.

The problem occured in my third attempt in quick succession to suspend
to disk. The first two did not succeed due to insufficient free swap. I
got 768 MB ram and a ~1 GB swap partition. I believe top said something
like Mem: 3xxxxxk used and Swap: 6xxxxxk used before the third attempt
to suspend to disk.

The system that was running had at least one successful suspend to disk
and restore the day before and I also use it sucessfully on a daily
basis.

I believe I've seen the same crash before with a 2.6.27 or earlier
kernel, but I was in a hurry getting out of the door back then as I was
here. Circumstances was the same though, with already successful suspend
to disk and the crash appearing during second or third attempt to
suspend to disk in quick succession.

I guess I should be able to reproduce the crash with some efforts, but
I'd like to hear your thoughts on this before I do that.

Filesystems are reiserfs.


Simon Holm Thøgersen

Re: Crash during suspend to disk

[Pavel Machek]

Hi!

> I hope this information is sufficient to debug my problem, though it
> unfortunately is somewhat incomplete. I took two pictures of the OOPS
> with my mobile phone, but unfortunately the picture of the upper part is
> so blurred that it is unreadable. Apparently I have to be in a hurry
> getting out of the door for this to happen. Here is what I got from the
> lower 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_call
> Code: ......
> EIP: [<...>] iput
> ---[ end trace ........................... ]---

Hmm, I'm afraid this is not enough, not even if the blanks are filled.

> I believe I've seen the same crash before with a 2.6.27 or earlier
> kernel, but I was in a hurry getting out of the door back then as I was
> here. Circumstances was the same though, with already successful suspend
> to disk and the crash appearing during second or third attempt to
> suspend to disk in quick succession.
> 
> I guess I should be able to reproduce the crash with some efforts, but
> I'd like to hear your thoughts on this before I do that.

If you can reproduce that, we can probably debug it...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html