Description of problem:
Entering standby is always problematic on my Dell Inspiron 1501 laptop,
upgrading to F9 may have re-anabled it. Closing the lid after a cold boot, on
resume the ext3 filesystem(s) are massively corrupted, to the point of being
Version-Release number of selected component (if applicable):
F9 with recent kernel upgrade
The problem occurred on F8, hence why I explicitly disabled suspend.
Steps to Reproduce:
1. Install F8/F9
2. Enter standby
3. Resume from standby. Root fs is too corrupted to mount. e2fsck recovers
thousands of numbered files and directories in lost+found
Massive corruption of ext3 partition(s)
What may be of use is the RAM config, the BIOS scans to around 2700MB then
jumps over the 4000MB mark and continues scanning to around 5500MB, reporting
a total of 4000MB RAM (which is actual RAM installed, in two 2GB DIMMs)
the RAM config thing is probably just skipping over a hole in the lower 4gb for
PCI address space (the rest of your ram is remapped above 4gb). It's likely
unrelated to the problem.
What would be interesting would be the output of dmesg after the corruption, but
that would mean you having to trash the disk again..
next time it happens, dmesg > /dev/fd0 and dump it to a floppy. (retrieve it
afterwards with strings /dev/fd0)
Suspect we want
Ah, I am indeed using KVM, so the IOMMU is active, not sure if my screen driver
is using GART though (since fglrx is not available for F9).
It seems the report of massive corruption (on this occasion) to my filesystem
are premature. While the root filesystem was unmountable (not merely _dirty_),
the data partition was recovered from journal playback without complaint. e2fsck
reported of my root partition something to the effect: "Journal flag not set but
journal has data"
This is the same error I used to get in previous (massively corrupt)
incarnations of the problem. Perhaps I was just lucky this time, perhaps since
I'm not using an accelerated 3D driver I'm not pumping huge quantities of data
through the GART.
Either way, having an unmountable filesystem after coming out of standby is a
_bad thing_. Interestingly, it is always the filesystem, never my LVM. If I have
the time, I'll try to do a boot off only snapshots, to see whether the
corruption (by that I mean the guilty party writing garbage, if it is the iommu
problem) is in the ext3 driver, the lvm driver or the sata driver.
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. 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 '9'.
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 9'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 9 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:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.