I have experienced this using the normal ata drivers, and the new
ATA/AHCI/CAM integration. I have done all tests only with AHCI/CAM
from now on.

I have been trying to get my JMB363 SATA controller to be usable after
putting the machine into S3 with acpiconf. The result in the logs after
resume looks like this:

kernel: ahci0: AHCI controller reset failure

Comparing the PCI registers before and after shows that not the entire
state is restored. So fixing the problem seemed easy enough: save and
restore the registers in the driver *_suspend/*_restore functions. The
main problem however is, that those are called AFTER the AHCI driver
has executed the reset. The call chain seems to go like this:

pci_resume()
ahci_resume()
ahci_ctrl_reset()
ata_jmicron_resume()

I only got a first rudimentary hack to work by modifying ahci_resume()
such, that it first calls bus_generic_resume() and then does the reset().
I have absolutely no idea if that has any other side effects. Someone who
knows these systems in depth should have a look though.

Fix: 

I have a hack that seems to lead in the right direction, but no patch
quality code yet.
How-To-Repeat: Use a system with a JMB363 controller. Put the system to sleep with
"acpiconf -s 3". On resume try to access the disks: no go.