From owner-freebsd-acpi@freebsd.org Thu Sep 3 20:06:54 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 E25889C9285; Thu, 3 Sep 2015 20:06:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE76617A3; Thu, 3 Sep 2015 20:06:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iofb144 with SMTP id b144so695447iof.1; Thu, 03 Sep 2015 13:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IzSRHJC/kS20mN3vHEdDc+ilG/kT7cRWXzG1brudG/I=; b=id+itj0A+ZZAd6iZJ0qrPb2su34CLo+KJ02zDs+nnvXQ+rfFShZMZNZV5c/Mp7OCXA fsTZvN9K5+MErCVeWgrKcyea9zmVbH0pwKVTQ9VnvsAaEzjiFWypOchJovdAPOVE7auk 1z7NoafxaFMvregitq6l29AjMPvrbf0WA9y4YVlXWRyvIJ7mX1C1fVKjePHVDI4mETUr OS8WGJO/w5N1OK2VbDYKqbzjZ9WtiRFCQqT+MyM1p4nuf1KZksWZ+pRaYNo1Rz8KH9VD xKcWQZEmGOWuaPtORWVasd7zsA/JLR94sjxe6AWU7mfryFnWpDO5qZFuwf3lzgPQS7oq jwcg== MIME-Version: 1.0 X-Received: by 10.107.13.75 with SMTP id 72mr1685816ion.75.1441310812837; Thu, 03 Sep 2015 13:06:52 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Thu, 3 Sep 2015 13:06:52 -0700 (PDT) In-Reply-To: <55E88860.8020404@FreeBSD.org> References: <55E3F098.9060806@FreeBSD.org> <55E88860.8020404@FreeBSD.org> Date: Thu, 3 Sep 2015 13:06:52 -0700 Message-ID: Subject: Re: acpi suspend debugging techniques? From: Adrian Chadd To: Andriy Gapon Cc: Garrett Cooper , John Baldwin , FreeBSD Current , "freebsd-acpi@freebsd.org" , freebsd-x11 Content-Type: text/plain; charset=UTF-8 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 20:06:54 -0000 oioo, would you please put that radeon patch into a review? I have an older machine with a radeon card in it that doesn't yet suspend/resume; I can now test it out! -a On 3 September 2015 at 10: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. > > -- > Andriy Gapon