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 irrecoverable. Version-Release number of selected component (if applicable): F9 with recent kernel upgrade How reproducible: 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 Actual results: Massive corruption of ext3 partition(s) Expected results: Normal standby/resume Additional info: 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 http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=6703f6d10dcd3316e03641a5ecaa6c8a04374d98
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.