Possible Suspend to Ram bug?

[Thomas Fjellstrom <tfjellstrom@shaw.ca>]

[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]

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

[-- Attachment #2: error.log.gz --]
[-- Type: application/x-gzip, Size: 6895 bytes --]