From owner-freebsd-acpi@freebsd.org Thu Sep 3 17:51:25 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 702929C982C; Thu, 3 Sep 2015 17:51:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E5DB3DCD; Thu, 3 Sep 2015 17:51:23 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA02826; Thu, 03 Sep 2015 20:51:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ZXYfR-0008Uf-8c; Thu, 03 Sep 2015 20:51:21 +0300 Subject: Re: acpi suspend debugging techniques? To: Adrian Chadd , Garrett Cooper , John Baldwin References: <55E3F098.9060806@FreeBSD.org> Cc: FreeBSD Current , "freebsd-acpi@freebsd.org" , freebsd-x11@FreeBSD.org From: Andriy Gapon X-Enigmail-Draft-Status: N1110 Message-ID: <55E88860.8020404@FreeBSD.org> Date: Thu, 3 Sep 2015 20:50:24 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 17:51:25 -0000 On 31/08/2015 11:53, Adrian Chadd wrote: > Try disabling hardware one at a time. Ie, unload usb; unload wifi; > leave kms loaded for mostly obvious reasons. Adrian, Garrett, thank you very much for your tips. Turned out that it was radeonkms that was causing the problem :-) BTW, here is another tool for the toolkit: on sufficiently recent system devctl suspend and devctl resume can be used to test individual drivers. So, I noticed that I could suspend/resume drmn0 device just fine but with vgapci0 I had a trouble suspending. One thing led to another and here is a patch that seems to fix the problem for me: ------------------------------------------------------------------------------- commit fecb5e8a90631f06600d87165cc8b6de3e035dfc Author: Andriy Gapon Date: Thu Sep 3 17:24:23 2015 +0300 radeon_suspend_kms: don't mess with pci state that's managed by the bus The pci bus driver handles the power state and configuration state saving and restoring for its child devices. diff --git a/sys/dev/drm2/radeon/radeon_device.c b/sys/dev/drm2/radeon/radeon_device.c index e5c676b11ed47..73b2f4c51ada2 100644 --- a/sys/dev/drm2/radeon/radeon_device.c +++ b/sys/dev/drm2/radeon/radeon_device.c @@ -1342,14 +1342,10 @@ int radeon_suspend_kms(struct drm_device *dev) radeon_agp_suspend(rdev); - pci_save_state(device_get_parent(dev->dev)); #ifdef FREEBSD_WIP if (state.event == PM_EVENT_SUSPEND) { /* Shut down the device */ pci_disable_device(dev->pdev); -#endif /* FREEBSD_WIP */ - pci_set_powerstate(dev->dev, PCI_POWERSTATE_D3); -#ifdef FREEBSD_WIP } console_lock(); #endif /* FREEBSD_WIP */ @@ -1380,10 +1376,6 @@ int radeon_resume_kms(struct drm_device *dev) #ifdef FREEBSD_WIP console_lock(); -#endif /* FREEBSD_WIP */ - pci_set_powerstate(device_get_parent(dev->dev), PCI_POWERSTATE_D0); - pci_restore_state(device_get_parent(dev->dev)); -#ifdef FREEBSD_WIP if (pci_enable_device(dev->pdev)) { console_unlock(); return -1; ------------------------------------------------------------------------------- However, I am not sure about an exact mechanism of the hard system hang that I experienced without the patch. BTW, I noticed that only very few drivers make explicit calls to pci_set_powerstate and pci_save_state/pci_restore_state. sys/dev/usb/controller/ohci_pci.c looks like a good use of pci_set_powerstate. sys/dev/ixgbe/if_ix.c looks like an incorrect / redundant use of the functions. -- Andriy Gapon