[Bugme-new] [Bug 6714] New: Suspend-to-RAM w/SATA slight regression from 2.6.16.20 to 2.6.17

[bugme-daemon at bugzilla.kernel.org]

http://bugzilla.kernel.org/show_bug.cgi?id=6714

           Summary: Suspend-to-RAM w/SATA slight regression from 2.6.16.20
                    to 2.6.17
    Kernel Version: 2.6.17
            Status: NEW
          Severity: normal
             Owner: jgarzik at pobox.com
         Submitter: oyvinst at ifi.uio.no


Most recent kernel where this bug did not occur: 2.6.16.20
Distribution: Fedora Core 4
Hardware Environment: Intel Centrino laptop (single Pentium-m CPU) w/SATA 
controller, Intel chipset (Intel Corporation 82801FBM (ICH6M) SATA Controller 
(rev 04)), 
Software Environment: gcc version 4.0.2 20051125 (Red Hat 4.0.2-8), 
glibc-2.3.6-4

Problem Description:
With 2.6.17 suspend-to-RAM sometimes fails during wakeup with SATA error 
messages and root fs mounted read-only, resulting in an unusable system. 
2.6.16.20 was very stable in this regard, with uptime of many days (10+ last 
time I checked) with multiple suspend/resume cycles every day.

Steps to reproduce: suspend and resume a few times.. Once in a while, the SATA 
subsystem (libata, scsi?) fails resulting in read-only fs after resume. I 
experienced this almost immediately after updating to 2.6.17. I will write 
down relevant kernel log lines when it happens next time, and post it.

I used to manually add this patch to 2.6.16.X:
--- linux-2.6.15-rc2/include/linux/libata.h     2005-11-21 
12:11:53.000000000 -0500
+++ linux/include/linux/libata.h        2005-11-21 12:11:19.000000000 -0500
@@ -634,7 +634,7 @@

 static inline u8 ata_wait_idle(struct ata_port *ap)
 {
-       u8 status = ata_busy_wait(ap, ATA_BUSY | ATA_DRQ, 1000);
+       u8 status = ata_busy_wait(ap, ATA_BUSY | ATA_DRQ, 100000); /* 1000msec 
*/

        if (status & (ATA_BUSY | ATA_DRQ)) {
                unsigned long l = ap->ioaddr.status_addr;

This made resume stable. I've also applied this to 2.6.17, hoping it will make 
it better, but haven't come to a conclusion yet.

Will attach my current dmesg, config and lspci -vv.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.