Bug 433907 - Suspend to ram (S3) destroys the filesystem
Suspend to ram (S3) destroys the filesystem
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-21 21:40 EST by John Veysey
Modified: 2009-09-15 00:28 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 01:03:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Veysey 2008-02-21 21:40:42 EST
Description of problem:
Hardware: Asus M2A-VM MB, AMD 64 dual core 2x2MB dual channel corsair ram

If I install Fedora Core 8, click on the "suspend" (S3/Suspend to Ram) option
from the gui, the computer suspends. At this point, there are no problems. When
I attempt to resume, there is massive filesystem corruption. It may or may not
resume to a semi-functional state. When it does, the suspend and resume logs
show no errors. The first errors appear when I try to access files that have
been mutilated.

There is not pattern to said corruption. It sometimes affects only some files,
and can be fscked back to life (albeit with lots of corrupted inodes, spread
over the disk). Sometimes it destroys the grub installation.

This is true for pm-suspend and direct access to /sys/power/state and
/proc/acpi/sleep even if the gui is not running.

It occurs in the ram filesystem when booting from the live CD (indicating that
this may not be pata ide driver specific). It occurs using tuxonice (custom
atrpms kernel), swsusp, uswsusp. Found in the default kernel, the latest patch,
and the alpha kernel (2.6.24) from FC9. I reproduced this in Ubuntu, and its
livecd. I reproduced it in the latest stable kernel.org generic kernel.

When the corruption occurs, there is usually no relevant log entry (until it
starts finding the filesystem corruptions). The "resume" can appear to work with
no problems. Hence there is nothing to attach.

This is reproduced with many permutations of possible BIOS parameters, as well
as with 3 different manufacturer provided BIOS'es.

If I reboot after suspend (but without the resume) things are fine.

Key observation: If I remove 2GB of memory, there are no problems whatsoever.
This doesn't depend on which SIMM, and both have passed lengthy memchecks.

This looks like a x86_64 kernel problem, and is certainly not specific to
Fedora. In fact, it could very well be a bug in the MB/BIOS, given that I can
find few others that have had the problem. Nonetheless, it's such a nasty
problem that I felt I should document it here, and hope that you can point me in
the right direction as far as reporting it elsewhere. Thanks!

Version-Release number of selected component (if applicable):


How reproducible: 100%


Steps to Reproduce:
1. Install Fedora
2. Boot
3. Click on Logout --> suspend
  
Actual results:
The filesystem is corrupted beyond repair

Expected results:
Anything else! :)

Additional info:
Comment 1 Bug Zapper 2008-11-26 04:54:42 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Bug Zapper 2009-01-09 01:03:00 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 3 Penelope Fudd 2009-09-15 00:28:28 EDT
Hi..

I've got Fedora 11, and suspend just trashed my filesystems.

System: Toshiba Satellite A200-AH6, 1 Gig of ram, 150Gig hard drive.
Kernel: 2.6.30.5-43.fc11.686.PAE  

This is the first time suspend has trashed my hard drive.  All of the errors appeared to be multiple files claiming ownership of the same blocks.  rpm -V -a reports many md5sum checksum failures.  I'm pleased it still boots.  I'll see if I can redownload the affected rpms and overwrite the corrupted files.

Note You need to log in before you can comment on or make changes to this bug.