From owner-freebsd-current@freebsd.org Thu Sep 3 22:18:55 2015 Return-Path: Delivered-To: freebsd-current@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 2673A9CAD13; Thu, 3 Sep 2015 22:18:55 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 141992EC; Thu, 3 Sep 2015 22:18:55 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id D0F431429; Thu, 3 Sep 2015 22:18:52 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: acpi suspend debugging techniques? To: Andriy Gapon , Adrian Chadd , Garrett Cooper , John Baldwin References: <55E3F098.9060806@FreeBSD.org> <55E88860.8020404@FreeBSD.org> Cc: "freebsd-acpi@freebsd.org" , FreeBSD Current , freebsd-x11@FreeBSD.org From: Jung-uk Kim X-Enigmail-Draft-Status: N1110 Message-ID: <55E8C74C.2080207@FreeBSD.org> Date: Thu, 3 Sep 2015 18:18:52 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E88860.8020404@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 22:18:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/03/2015 13:50, Andriy Gapon wrote: > 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. AFAICT, the whole suspend/resume code looks incomplete and very messy. In fact, I'll be very surprised if it ever worked. :-( Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV6MdGAAoJEHyflib82/FGJ68H/2W6IfhDrtciL2LmA67T0VHU Nagp1Oghp+JDw/iVB28Sxf/EXptsZKUeKvSYYilIFHsl/d/+uPvhbaxLVWUSyhGe C5vVCbSkyRwnz3I5iiMab9Ou+VFTVqHhNLgrCFfDvjeHssbIkD7+bEuldWyqOIFH rvvvZ8qGebVV7jcfU3lVVUz3tNwLwgdtVPuZIohxc8M7n1pE185hnUa1b37pytC9 btrCYLstGRNBbaD530iMN0bXM02aWgUTbf9cVH31nYduQaYOPYe/JgNKLzbmJ0gL JIhGh4eubyR4W2SonRsg1ahHHzSr1pe1o7TVuU+2G1fycz4GSLoFWzYnSTxDMc4= =IAfV -----END PGP SIGNATURE-----