Messages in this thread | | | From | Thomas Fjellstrom <> | Subject | Possible Suspend to Ram bug? | Date | Fri, 10 Jul 2009 04:58:27 -0600 |
| |
I've recently gotten a new OCZ Vertex 30G SSD and have noticed that it will flip out the second time linux wakes up from "suspend to ram".
The system will run fine for days or weeks, so long as it isn't waking up a second StR.
Here is an example error that I get from the device (my root / device):
[42018.455204] sd 0:0:0:0: [sda] Unhandled error code [42018.455208] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [42018.455215] end_request: I/O error, dev sda, sector 12583031 [42018.455221] EXT3-fs error (device sda2): ext3_get_inode_loc: unable to read inode block - inode=391005, block=1572871
At that point using my / fs is pretty much impossible. Every single app fails to launch with an I/O Error, about the only command I can run in that state is "dmesg" in an existing konsole.
I'm currently using 2.6.29-2-amd64 from debian, and am running on a Gigabyte MA790FXT-UD5P, with a AMD Phenom II X4 810 cpu, and 4G ram.
One interesting thing to note, the file system on the Vertex SSD reports as clean to fsck on the next boot, while my /home which is on a Seagate 7200.12 drive reports with several orphaned inodes (every single time). And that's regardless if I use ALT+SYSRQ+S/U to try and sync everything. Also, ALT+SYSRQ+B doesn't work at that point, only ALT+SYSRQ+O or using the system power/reset buttons will work.
I'm attaching the full log I was able to save from dmesg (over nfs, luckily that worked).
-- Thomas Fjellstrom tfjellstrom@shaw.ca [unhandled content-type:application/x-gzip] | |