linux-kernel - Possible Suspend to Ram bug?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <200907100458.27410.tfjellstrom@shaw.ca>
Date:	Fri, 10 Jul 2009 04:58:27 -0600
From:	Thomas Fjellstrom <tfjellstrom@...w.ca>
To:	linux-kernel@...r.kernel.org
Subject: Possible Suspend to Ram bug?

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@...w.ca

Download attachment "error.log.gz" of type "application/x-gzip" (6895 bytes)