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.
Created attachment 8340 [details] 2.6.17 kernel boot log
Created attachment 8341 [details] kernel config
Created attachment 8342 [details] lspci -vv
I haven't experienced the problem since applying the patch mentioned in the description of this bugzilla-report.
Re: Comment #14: I take that back, it still happens occasionally. The latest incident was with 2.6.17.7. So I guess that patch really doesn't do any good.
Sorry, the previous comment should be Re: Comment #4.
libata recently received overhaul in suspend/resume department. Can you try libata-tj patch[1] against 2.6.17.4 or 2.6.18-rc3? [1] http://home-tj.org/files/libata-tj-stable/libata-tj-2.6.17.4-20060710.tar.bz2
Do you have a patch against 2.6.17.7 (latest stable) ? I could try it and report back, but it's a little cumbersome for me to downgrade to 2.6.17.4 right now, since I'm at work. I tried the patch against 2.6.17.7, and I suspect some parts of it are already in 2.6.17.7 (patch detects previously applied stuff).
Sorry, not yet. I'll make an updated version but can't say when.
Is the problem still there in 2.6.18-mmX kernel?
Since this bug was reported, I've switched to using the standard Ubuntu Dapper distro kernel (2.6.15-based), switched distro _and_ I've switched hardware (new laptop). But, for the sake of this bug report, I will try 2.6.18-mm2 (using the the config attached here) on my old laptop. I am, however, not able to re-create the old sitation completely because of different suspend/resume scripts, etc (Ubuntu's suspend/resume scripts are quite sophisticated compared to what I used earlier on Fedora Core). Note that the 2.6.15-based Dapper kernel does *not* exhibit the SATA problem on resume on my old laptop (the hardware used when this bug was first reported). I've not invested any time in finding out what patches they might have for SATA-suspend, etc, etc (it just works nicely:).
I think this bug should be closed now and a new one opened if need be.
I have no means of reproducing it any more (updated all my installations to Ubuntu Edgy). However, Edgy has a 2.6.17-based kernel, and I have never had troubles suspending any of my SATA-laptops. So I think it can safely be closed.