lkml.org 
[lkml]   [2009]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectPossible Suspend to Ram bug?
Date
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]
\
 
 \ /
  Last update: 2009-07-10 13:01    [W:0.070 / U:20.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site