kern/151091: JMicron JMB363 unusable after S3 suspend/resume
Bernd Heller
bdheller at users.sourceforge.net
Wed Sep 29 22:40:04 UTC 2010
>Number: 151091
>Category: kern
>Synopsis: JMicron JMB363 unusable after S3 suspend/resume
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Sep 29 22:40:03 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Bernd Heller
>Release: 8.1
>Organization:
>Environment:
FreeBSD helios.home.lan 8.1-RELEASE FreeBSD 8.1-RELEASE #21: Thu Sep 30 00:18:01 CEST 2010 root at helios.home.lan:/usr/obj/usr/src/sys/HELIOS amd64
>Description:
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.
>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.
>Fix:
I have a hack that seems to lead in the right direction, but no patch quality code yet.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list