Most recent kernel where this bug did not occur: 2.6.17.2
Distribution: Ubuntu Linux
Hardware Environment: Dell Precision M20 laptop, pretty much the same as Dell 
Latitude D610. Has PATA drive @ SATA controller, same for DVD+-RW drive. 
Controller runs in libata mode, not AHCI and is not switchable within BIOS. The 
chipset is i915. Dedicated ati firegl v3100 graphics. Hitachi HTS726060M9AT00 
drive, rev. MH4O.

Software Environment: I am suspending with powerwsave daemon, that executes 
some scripts before suspending. The kernel .config file that I used for 
compilation is here: http://pastebin.ca/76289

Problem Description: After resuming from S3 it sometimes (about once per 3 
resumes) happens that I get lots of following errors in syslog:

kernel: sd 0:0:0:0: SCSI error: return code = 0x40000
kernel: end_request: I/O error, dev sda, sector 2309162

A much richier excerpt from syslog is here: http://pastebin.ca/74009 . Please 
note that this one could be taken while running under 2.6.17 kernel with fglrx 
and madwifi, but exactly the same error is when running 2.6.17.2 with radeon 
opensource driver and no madwifi loaded, so the binary drivers seem not to be 
the case. I tried it, trust me. I was just unable to read syslog file (while 
beeing in this buggy resume state) anymore since I taken the above excerpt, 
that's why the syslog provided is not the most accurate one. Probably the 
syslog was not in the cache before suspending, so I was not able to access it 
after resuming. 

The problem is not only about these errors though, I cannot access disk drive 
at all. All the data I see on the disk is from disk cache in memory and the 
rest seems gone. When trying to access some disk data that is not in the cache, 
I get errors, something like: "command: i/o error", and the corresponding 
syslog entry, like the one above. For me it looks like the disk is not spin up 
after rebooting, though it is for sure - I can hear it spinning. To get the 
things back to normal I have to reboot, or rather turn it completely off and 
back on, since printing `init 6` or pressing power button prints errors, too. 
Also, hdparm prints i/o scsi errors, when trying to suspend the drive for 
example. This is why I think the bug is libata related.

This behaviour was not here as for 2.6.16, though I used to get some problems, 
too, and these could possibly be related. It sometimes wouldn't suspend at all, 
because the disk drive wouldn't spin down. It'd then print some ATA abnormal 
status errors, multiple times. I had to manually turn the power off. It also 
wouldn't print the `ACPI: PCI interrupt for device 0000:03:01.0 disabled` in 
that case, that it _normally_ used to print soon before suspending and just 
after the disk actually spined down.

Steps to reproduce: suspend and resume multiple times, probably while running 
on battery, since I think the bug happens more often then. I am sure this bug 
is specific to this hardware configuration.