From owner-freebsd-acpi@freebsd.org Mon Aug 31 06:14:24 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 BE5AE9C7843; Mon, 31 Aug 2015 06:14:24 +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 D05F91DDA; Mon, 31 Aug 2015 06:14: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 JAA21791; Mon, 31 Aug 2015 09:14: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 1ZWIMH-0003JC-4a; Mon, 31 Aug 2015 09:14:21 +0300 To: FreeBSD Current , "freebsd-acpi@freebsd.org" From: Andriy Gapon Subject: acpi suspend debugging techniques? X-Enigmail-Draft-Status: N1110 Message-ID: <55E3F098.9060806@FreeBSD.org> Date: Mon, 31 Aug 2015 09:13:44 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 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: Mon, 31 Aug 2015 06:14:24 -0000 I would appreciate any pointers at how to debug an ACPI suspend problem that I have. What I have so far. The system hangs when I try to suspend it and it gets reset by a watchdog. Setting debug.acpi.suspend_bounce=1 does not make any difference, so the hang happens before the final sleep code is executed. I think that the device suspend stage is executed, because disks get spun down and video signals gets cut off. I could enable / add some debug printfs, but I suppose that their output would get lost due to the above. RAM content unfortunately does not survive across the resets. -- Andriy Gapon From owner-freebsd-acpi@freebsd.org Mon Aug 31 06:33:12 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 A5BBC9C40B5; Mon, 31 Aug 2015 06:33:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 78717BC9; Mon, 31 Aug 2015 06:33:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pacrd3 with SMTP id rd3so12552034pac.3; Sun, 30 Aug 2015 23:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6V1aAqH/LQ/aDvNVd8eztDlLUeH2YyQGOtYyZzpAhPE=; b=bOuvciuaAVT+f3RZIK6TCIRcCOqLJ+/vRH5niXE2BtAySzkW0aZW/FcZXwY2JzIFzU BqTTgFf4BIKx0Eh9xvl2owPhNnAVBg+C8/qWmtWQzICRLE7XqiI6NjzhCpzwGWSsxeYV mioqC2oqVJPbSw4XJnhb7FFlUA4L++ZmgwJTutTjusplf+lmKytjJRQsPj7qIO4dsiCI NHSEbhm/b2U+P18yigS/GA7Vb9pPGURYVJYXZk+XSk9h2r7G5HvWRgW+U+fhmVirBtic YHuEgd1TWKCf2FPf0YSJyxYnMR6qbbMdQGaM46Ai7sXSscMpTAzcCXHtXI1GGMFAfm06 eKDA== X-Received: by 10.68.181.34 with SMTP id dt2mr34387997pbc.7.1441002792084; Sun, 30 Aug 2015 23:33:12 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id y8sm13208672pbt.7.2015.08.30.23.33.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Aug 2015 23:33:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: acpi suspend debugging techniques? From: Garrett Cooper In-Reply-To: <55E3F098.9060806@FreeBSD.org> Date: Sun, 30 Aug 2015 23:33:10 -0700 Cc: FreeBSD Current , "freebsd-acpi@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <55E3F098.9060806@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.2104) 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: Mon, 31 Aug 2015 06:33:12 -0000 > On Aug 30, 2015, at 23:13, Andriy Gapon wrote: >=20 >=20 > I would appreciate any pointers at how to debug an ACPI suspend = problem that I have. >=20 > What I have so far. The system hangs when I try to suspend it and it = gets reset > by a watchdog. Setting debug.acpi.suspend_bounce=3D1 does not make = any > difference, so the hang happens before the final sleep code is = executed. I > think that the device suspend stage is executed, because disks get = spun down and > video signals gets cut off. >=20 > I could enable / add some debug printfs, but I suppose that their = output would > get lost due to the above. RAM content unfortunately does not survive = across > the resets. When I last had to do this to figure out what magic formula was required = to get my netbook working, I did something like this: 1. Stripped down the kernel to just the storage driver and core pieces. 2. Loaded all other modules after boot, if necessary. 3. Called zzz with the appropriate ACPI tunables/sysctls set. That got me pointed in the right direction (IIRC it was psm at the = time). What I did to get a real smoking gun was I put printf statements = in subr_bus.c (IIRC) to track device quiescing at suspend and = reawakening at resume. There=E2=80=99s `options BUS_DEBUG` too, which may or may not help. FWIW I found debug.acpi.suspend_bounce less useful, but it still = exercised the quiesce->reawaken cycle, sorta. There=E2=80=99s also `hw.acpi.reset_video` and `debug.acpi.resume_beep`. You might need to hack /etc/rc.resume and /etc/rc.suspend, BTW, = depending on what you discover (switching my vty was definitely required = in order for X11 to come back in a sane manner at resume). Cheers, -NGie= From owner-freebsd-acpi@freebsd.org Mon Aug 31 08:53:19 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 4952E9C6423; Mon, 31 Aug 2015 08:53:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 272861BE2; Mon, 31 Aug 2015 08:53:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iog7 with SMTP id 7so27277505iog.2; Mon, 31 Aug 2015 01:53:18 -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:content-transfer-encoding; bh=1NxR8qSMiSeBVk3N02mMlUd/QAAqowcAAg36VCqCrXw=; b=XVhwQyeghghNEQtE6Z0dfGOOig+h4aqfnemR2k/lSDXuUcOpF3Nje/Y34BcZUCxCRU frv385NjbCNqNivXwhhlj3ZZHerVbY9lXGRUn6RA3Z/lJGgvMGGL4cxlmAGkVGvh5WWL hGQxd+kcCJduhj0Bj3z5Fem4rnC1SByAYztQW0EUXuLNQas4Qv4Alvm7wcULthLsPy3Q Q+lql/XLYOsI/fRdA2pv+HtqffS8wIhtiIqI3nbZK/zFtUHGBVzMv+xOX+QgVWXhAbk+ +zShhUAzWviJmrbr5+l0cxahVAKS+RVPwkWYYbXSw+0/I/Zn66h5nwF6t5PrYY4siDOO OemA== MIME-Version: 1.0 X-Received: by 10.107.131.196 with SMTP id n65mr22517051ioi.75.1441011197566; Mon, 31 Aug 2015 01:53:17 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Mon, 31 Aug 2015 01:53:17 -0700 (PDT) In-Reply-To: References: <55E3F098.9060806@FreeBSD.org> Date: Mon, 31 Aug 2015 01:53:17 -0700 Message-ID: Subject: Re: acpi suspend debugging techniques? From: Adrian Chadd To: Garrett Cooper Cc: Andriy Gapon , FreeBSD Current , "freebsd-acpi@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 31 Aug 2015 08:53:19 -0000 hi, Try disabling hardware one at a time. Ie, unload usb; unload wifi; leave kms loaded for mostly obvious reasons. I hit a few of these which turned out to be an issue in the suspend path of a driver - and once I found it was the USB hardware but the BIOS itself that was hanging - FreeBSD put USB hardware into S3, but the ACPI BIOS requested S2 and just hung if we had USB in S3. :( -adrian On 30 August 2015 at 23:33, Garrett Cooper wrote: > >> On Aug 30, 2015, at 23:13, Andriy Gapon wrote: >> >> >> I would appreciate any pointers at how to debug an ACPI suspend problem = that I have. >> >> What I have so far. The system hangs when I try to suspend it and it ge= ts reset >> by a watchdog. Setting debug.acpi.suspend_bounce=3D1 does not make any >> difference, so the hang happens before the final sleep code is executed.= I >> think that the device suspend stage is executed, because disks get spun = down and >> video signals gets cut off. >> >> I could enable / add some debug printfs, but I suppose that their output= would >> get lost due to the above. RAM content unfortunately does not survive a= cross >> the resets. > > When I last had to do this to figure out what magic formula was required = to get my netbook working, I did something like this: > > 1. Stripped down the kernel to just the storage driver and core pieces. > 2. Loaded all other modules after boot, if necessary. > 3. Called zzz with the appropriate ACPI tunables/sysctls set. > > That got me pointed in the right direction (IIRC it was psm at the time).= What I did to get a real smoking gun was I put printf statements in subr_b= us.c (IIRC) to track device quiescing at suspend and reawakening at resume. > > There=E2=80=99s `options BUS_DEBUG` too, which may or may not help. > > FWIW I found debug.acpi.suspend_bounce less useful, but it still exercise= d the quiesce->reawaken cycle, sorta. > > There=E2=80=99s also `hw.acpi.reset_video` and `debug.acpi.resume_beep`. > > You might need to hack /etc/rc.resume and /etc/rc.suspend, BTW, depending= on what you discover (switching my vty was definitely required in order fo= r X11 to come back in a sane manner at resume). > > Cheers, > -NGie > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " 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 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 From owner-freebsd-acpi@freebsd.org Thu Sep 3 22:18:55 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 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-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 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----- From owner-freebsd-acpi@freebsd.org Thu Sep 3 22:30:29 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 71B499C9346; Thu, 3 Sep 2015 22:30:29 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2EA74B54; Thu, 3 Sep 2015 22:30:28 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id t83MUR5p058405; Thu, 3 Sep 2015 15:30:27 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id t83MUQf7058404; Thu, 3 Sep 2015 15:30:26 -0700 (PDT) (envelope-from david) Date: Thu, 3 Sep 2015 15:30:26 -0700 From: David Wolfskill To: Jung-uk Kim Cc: "freebsd-acpi@freebsd.org" , FreeBSD Current , freebsd-x11@FreeBSD.org Subject: Re: acpi suspend debugging techniques? Message-ID: <20150903223026.GK17650@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Jung-uk Kim , "freebsd-acpi@freebsd.org" , FreeBSD Current , freebsd-x11@FreeBSD.org References: <55E3F098.9060806@FreeBSD.org> <55E88860.8020404@FreeBSD.org> <55E8C74C.2080207@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NiDZvZUadYKQfYjZ" Content-Disposition: inline In-Reply-To: <55E8C74C.2080207@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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 22:30:29 -0000 --NiDZvZUadYKQfYjZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Much trimming, both of older content and recipient addresses -- dhw] On Thu, Sep 03, 2015 at 06:18:52PM -0400, Jung-uk Kim wrote: > ... > AFAICT, the whole suspend/resume code looks incomplete and very messy. > In fact, I'll be very surprised if it ever worked. :-( >=20 > Jung-uk Kim > ... While I bow to your expertise in the area, I point out that I routinely suspend my laptop before putting it in my backpack, then cycling between the shuttle stop and my house during my daily commutes to & from work -- usually running stable/10, but I'm sometimes running head at the time. And I track both stable/10 and head daily on that laptop (in different slices). While I do encounter "issues" from time to time, those are rare enough that I'd call them "unusual." (To quantify that, I think I've had 3 - 5 such incidents since November 2014, while generally commuting 5 days/week.) I'll be happy to test. :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who would murder in the name of God or prophet are blasphemous coward= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --NiDZvZUadYKQfYjZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJV6MoCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7XekQAJykkXmdIWKBIOhEuUFUWGn3 grHQE6FXoV95Ew1ZSaK4rDge6N8QUcOfjl7HX/pZFGMtekRn9oIICz735vRxye1H NWibvgViBfQZkQ7DMcb8X529oeA5C36Uzajfi5l2xj8z762a7moBHyN80+/bCkr6 Kk7BEVq1I5weEy+EFsMDpjVDYf66raOrt61J5f2OaGmHH00Y3J8nPFLP8W7wDXFw zxSwsOBsNhmhzTNDnuV6ymT2btCixUMezQU7mTiMwZO0cUCoHC7YUFRlNqbgI256 GgdmbEYN7P0Eyc/hMYHtShnc2O2qG4lBC03m8gozObpkAKTv3OP1DaUL2VFpJLt1 ul4G9tIPLB3KBt86fs2C0gWYHFp9W5mghp5uX9W33mnp7rJJ1SJ4/ZW+24iqSB3/ PiNHzEZfZ7grUcGqNXzScoS2eIdQ/BRiQX4svmVUEESLR+jIp7wxEl1qllSLWUX9 k/YaKAHeEXx5IgYaqDSCtkHRVZIpOdIzoMc+qLTQprpjgxWDtFwKm7FNQP5Dip7E YjWxeRHWfoWZUZ4wlLLQbHJOQxR4vVG7CFCfeitAPuM/+nqFKzmYay0Bx/EXqnCG 7j3ZIrPm9P6sVMI4KptQat2j9XbZ1In6hQVMNc92n+oLA/aeIfkqSAmoNlwsmQu+ 7yBzzQW/LsPgTryBX00n =vQ6V -----END PGP SIGNATURE----- --NiDZvZUadYKQfYjZ-- From owner-freebsd-acpi@freebsd.org Thu Sep 3 22:38:01 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 931639C9670 for ; Thu, 3 Sep 2015 22:38:01 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) Received: from nm42-vm8.bullet.mail.ne1.yahoo.com (nm42-vm8.bullet.mail.ne1.yahoo.com [98.138.120.214]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C65AF46 for ; Thu, 3 Sep 2015 22:38:01 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441319526; bh=gW14ToBaNIyaEoUc8YSUJP9vT/dadnCCN5xt20n0wI8=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=TgFyVoreKhbdMtFxjUNs9G27icZn2jQNBXIb1j27M2n8InMtUShMRYaGPcMgPDF5COzL/58MuKS/+fXUJ9Kyxf1BfJ+CEJozVD2PBjKJRlm4NuCEfH3437dmb2QPnBwZkUVImNRm+fpg9rFn/3PVdePClGSpV4c6x+02rAuOzT28hcQi+ayOJVvGy9GJRF7UWkMkpLo4u4aebB0KA8cDcLr843qycoUC+AhCyyfENCoT8Wh54EDe/RCzeiM6ZJZ7UKKtDPj/G6ImdKN3bBVuqn2jn9QhDDQfCkLsrJiCqdKPlPZkkbzz2ODvV8hdLG7gNVu5MCr8Jls33p1lRuYplQ== Received: from [127.0.0.1] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 03 Sep 2015 22:32:06 -0000 Received: from [98.138.100.116] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 03 Sep 2015 22:29:19 -0000 Received: from [98.139.170.178] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 03 Sep 2015 22:29:19 -0000 Received: from [98.139.213.9] by tm21.bullet.mail.bf1.yahoo.com with NNFMP; 03 Sep 2015 22:29:19 -0000 Received: from [127.0.0.1] by smtp109.mail.bf1.yahoo.com with NNFMP; 03 Sep 2015 22:29:19 -0000 X-Yahoo-Newman-Id: 541456.34245.bm@smtp109.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-4 X-YMail-OSG: eY53I60VM1l9CNOhUln8nh6hka8AIDQbay84txpX7.bzOum .1kCNUMkLTqynxSYzyEpj4YbGRDd63NhCAfRL__Cq_gfdVSPwCb_XXWIzRyo rkGM5w.qmRfLpBPQti.jSRuaZSHwM5rtJjggcJ9BwKOBEhbGHRSJMKH88w8. KMXgxI3UAt4W4Q16LQ2OllCR_XA0N17ZtLPIoDFuNgOnLEQfLrc62rDqmMzA lLFnm95q7oC0LNjel6JxqOfwu6nXdpZ_mpe.AZShwaYQt2MFMr.ViHnHXVmQ GXr4Ji27zKWhekQZhgEb77Y2zDAFxlwMib2CkIC9eP8Z4hjnGsqUZJ5j3C4I xa2CHMH4Jy9YkUUJS9RSkLHcaG0J9zmB8J2Wl2L.FGzkHHgYZfR8sJY7R6hi GeauGunDyzl0U3KJkWd9HRdkXRu1oJgMt.3g3C2ShZhnR9q.KOMtdIQREufU l1EABgf0gibSE0nI5swqcj7gXBZbUjdm5pY7my53_AQAfnYdAbOLtSns3z4b UfjUVI9bQA4BW2LHMxi_U3Z9A5Ip_Vtq3LAapCZ7WIDcMYQM- X-Yahoo-SMTP: 9sPoSQ2swBBlERuQ.0vs8XLc_MeClW0- Message-ID: <55E8C9BE.2060202@yahoo.com> Date: Thu, 03 Sep 2015 18:29:18 -0400 From: Anthony Jenkins Organization: VTilt Digital, LLC User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Adrian Chadd , Andriy Gapon CC: "freebsd-acpi@freebsd.org" , FreeBSD Current , Garrett Cooper , freebsd-x11 Subject: Re: acpi suspend debugging techniques? References: <55E3F098.9060806@FreeBSD.org> <55E88860.8020404@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 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 22:38:01 -0000 My Radeon card comes back from resume, but the backlight doesn't (it stays off). Think this patch might help with that? I was gonna start a separate thread to ask for help debugging my backlight issue... Thanks, Anthony On 09/03/15 16:06, Adrian Chadd wrote: > 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 > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" -- Anthony Jenkins Software Engineer VTilt Digital, LLC From owner-freebsd-acpi@freebsd.org Thu Sep 3 22:48:50 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 A0B0E9C9B41; Thu, 3 Sep 2015 22:48:50 +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 77571385; Thu, 3 Sep 2015 22:48:49 +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 BAA06504; Fri, 04 Sep 2015 01:48:47 +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 1ZXdJH-0008m9-1D; Fri, 04 Sep 2015 01:48:47 +0300 Subject: Re: acpi suspend debugging techniques? To: Anthony Jenkins References: <55E3F098.9060806@FreeBSD.org> <55E88860.8020404@FreeBSD.org> <55E8C9BE.2060202@yahoo.com> Cc: "freebsd-acpi@freebsd.org" , FreeBSD Current , freebsd-x11 From: Andriy Gapon Message-ID: <55E8CE16.7090309@FreeBSD.org> Date: Fri, 4 Sep 2015 01:47:50 +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: <55E8C9BE.2060202@yahoo.com> Content-Type: text/plain; charset=windows-1252 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 22:48:50 -0000 On 04/09/2015 01:29, Anthony Jenkins wrote: > My Radeon card comes back from resume, but the backlight doesn't (it > stays off). Think this patch might help with that? Likely not, but who knows. > I was gonna start a > separate thread to ask for help debugging my backlight issue... -- Andriy Gapon From owner-freebsd-acpi@freebsd.org Thu Sep 3 22:50:11 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 08EAC9C9D2E; Thu, 3 Sep 2015 22:50:11 +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 E660479C; Thu, 3 Sep 2015 22:50:10 +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 6871824A6; Thu, 3 Sep 2015 22:50:10 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: acpi suspend debugging techniques? To: David Wolfskill , "freebsd-acpi@freebsd.org" , FreeBSD Current , freebsd-x11@FreeBSD.org References: <55E3F098.9060806@FreeBSD.org> <55E88860.8020404@FreeBSD.org> <55E8C74C.2080207@FreeBSD.org> <20150903223026.GK17650@albert.catwhisker.org> From: Jung-uk Kim Message-ID: <55E8CEA2.5030905@FreeBSD.org> Date: Thu, 3 Sep 2015 18:50:10 -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: <20150903223026.GK17650@albert.catwhisker.org> Content-Type: text/plain; charset=windows-1252 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 22:50:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/03/2015 18:30, David Wolfskill wrote: > [Much trimming, both of older content and recipient addresses -- > dhw] > > On Thu, Sep 03, 2015 at 06:18:52PM -0400, Jung-uk Kim wrote: >> ... 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 ... > > While I bow to your expertise in the area, I point out that I > routinely suspend my laptop before putting it in my backpack, then > cycling between the shuttle stop and my house during my daily > commutes to & from work -- usually running stable/10, but I'm > sometimes running head at the time. > > And I track both stable/10 and head daily on that laptop (in > different slices). > > While I do encounter "issues" from time to time, those are rare > enough that I'd call them "unusual." (To quantify that, I think > I've had 3 - 5 such incidents since November 2014, while generally > commuting 5 days/week.) > > I'll be happy to test. :-) I am not saying the patch is wrong. Actually, it is in the right direction. If you can, please test the following patch, too. - --- sys/dev/drm2/radeon/radeon_drv.c (revision 287437) +++ sys/dev/drm2/radeon/radeon_drv.c (working copy) @@ -327,14 +327,14 @@ radeon_suspend(device_t kdev) struct drm_device *dev; int ret; + ret = bus_generic_suspend(kdev); + if (ret) + return (ret); + dev = device_get_softc(kdev); ret = radeon_suspend_kms(dev); - - if (ret) - - return (-ret); - - ret = bus_generic_suspend(kdev); - - - - return (ret); + return (-ret); } static int Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV6M6cAAoJEHyflib82/FGX1UH/0BaQl+/e7Cqc2+3jdcmuusd P8gJBGIFu89+6KsA2J1btQQYO2wwA9tJkpkZx4oi/pT+L+pIqZGx7/w7klsfXvXd gfI0looWxzB5ZALCrzYq50Nk67E9s6iXymRMJ95oyZ2GLkbwLqY6gOStqld7vBuE Z4iEBYHMrDtojd33w/9SRa8zNSpvwXZJliNjhpFd680ApkSO2xN/dIxI/z1JjlEw oquRpvFlR4urqCdhYmKyjoXuR7rYdl0K2imfA7EjL2RFzlFyacS+ny4BqnbvMqzC tMNxYFUOEvxMW+336DKZjiRWgAyfmJiOuoFxRoDiCq42zzjcLF+2gnLlcd4/j+4= =/r95 -----END PGP SIGNATURE----- From owner-freebsd-acpi@freebsd.org Thu Sep 3 22:50:41 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 11F439C9DBA; Thu, 3 Sep 2015 22:50:41 +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 6F28F94F; Thu, 3 Sep 2015 22:50:39 +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 BAA06538; Fri, 04 Sep 2015 01:50:37 +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 1ZXdL3-0008mK-FL; Fri, 04 Sep 2015 01:50:37 +0300 Subject: Re: acpi suspend debugging techniques? To: Jung-uk Kim References: <55E3F098.9060806@FreeBSD.org> <55E88860.8020404@FreeBSD.org> <55E8C74C.2080207@FreeBSD.org> Cc: John Baldwin , "freebsd-acpi@freebsd.org" , FreeBSD Current , freebsd-x11@FreeBSD.org From: Andriy Gapon Message-ID: <55E8CE85.80109@FreeBSD.org> Date: Fri, 4 Sep 2015 01:49:41 +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: <55E8C74C.2080207@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 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 22:50:41 -0000 On 04/09/2015 01:18, Jung-uk Kim wrote: > AFAICT, the whole suspend/resume code looks incomplete and very messy. > In fact, I'll be very surprised if it ever worked. :-( It does seem to work for me with the patch and other people report that the code works for them even without the patch. -- Andriy Gapon From owner-freebsd-acpi@freebsd.org Fri Sep 4 14:29:20 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 943839C986F for ; Fri, 4 Sep 2015 14:29:20 +0000 (UTC) (envelope-from s.tyshchenko@identika.pro) Received: from scale222.ru (scale222.ru [51.254.99.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 427FA12A for ; Fri, 4 Sep 2015 14:29:19 +0000 (UTC) (envelope-from s.tyshchenko@identika.pro) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=scale222.ru; s=default; h=Content-Type:List-Unsubscribe:Message-ID:Sender:From:Date:MIME-Version:Subject:To; bh=yrgp46fg0/z4tD3lHX7dBSLaAUKd4g+8IKxApN4hMuM=; b=OP2iDMjrfcBo462IIjG0vay8h6kJvT1oJ4WD/eM8DY8mK9IHxCxkaAutoLD59etE16g3bvMELNtndJXqnLeCj1AWEbZ53rmEMT3TM/mNOZBGNFq2RIupV6V6Q9971ZlhXL1CAyb06pOkelr9bb+4tUbQ4LT6tWNqyHma9yied2c=; Received: from root by scale222.ru with local (Exim 4.80) (envelope-from ) id 1ZXrzS-0003Us-EO for freebsd-acpi@freebsd.org; Fri, 04 Sep 2015 16:29:18 +0200 To: freebsd-acpi@freebsd.org Subject: Plastic ProductS MIME-Version: 1.0 Date: Fri, 4 Sep 2015 16:29:18 +0200 From: Sergey Tyshchenko Sender: s.tyshchenko@identika.pro Message-ID: <243146900.27121@scale222.ru> X-Priority: 3 X-Mailer: scale222.ru mailer. Ver. 1.1. Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 14:29:20 -0000 TWFudWZhY3R1cmUgb2YgwqBwcmludGVkIHByb2R1Y3RzIGZyb20gQUJTIHBsYXN0aWMsIGFjcnls aWMsIFBFVCBtZXRob2Qgb2YgdmFjdXVtIGZvcm1pbmcuIFNlcmllcyBwcm9kdWN0aW9uIG9mIExl dHRlcnMsIHNpZ25zLCBsaWdodCBib3hlcyAobGlnaHRib3gpLCBQT1MgbWF0ZXJpYWwgZm9yIHJl dGFpbCBjaGFpbnMuRXhhbXBsZXMgb2Ygb3VyIHdvcms6wqBodHRwOi8vaWRlbnRpa2EucHJvL2Nv dW50ZXJfbGluay9wcmVzZW50YXRpb25fZW4ucGRm4oCLDQoJCQkJCQkJCQkJCQkJCQkJCQkJDQoJ CQkJCQkJCQkJCQkJCQkJCQkJDQoJCQkJCQkJCQkJCQkJCQkJCQkJCQ0KCQkJCQkJCQkJCQkJCQkJ CQkJCQkNCgkJCQkJCQkJCQkJCQkJCQkJCQkJDQoJCQkJCQkJCQkJCQkJCQkJCQkJCQ0KCQkJCQkJ CQkJCQkJCQkJCQkJCQkNCgkJCQkJCQkJCQkJCQkJCQkNCgkJCQkJCQkJCQkJCQkJCQkNCgkJCQkJ CQkJCQkJCQkJCQkNCgkJCQkJCQkJCQkJCQkJCQkNCgkJCQkJCQkJCQkJCQkJCQkJDQoJCQkJCQkJ CQkJCQkJCQkJCQkNCgkJCQkJCQkJCQkJCQkJCQkJCQkNCgkJCQkJCQkJCQkJCQkJCQkJCQkJU2Vy Z2V5IFR5c2hjaGVua29DRU8gfMKgSURFTlRJS0EuUFJPVmliZXI6wqArMzgwNTA1NTY2OTY1wqB8 IFdoYXRzQXBwOsKgKzM4MDUwNTU2Njk2NVNreXBlOiB0LnNlcmdleS5tcy50eXNoY2hlbmtvQGlk ZW50aWthLnBybyB8wqBpZGVudGlrYS5wcm8wMzA0MCB8IEdvbG9zaWl2c2t5aSBBdmUuIDcwIHwg b2ZmaWNlIDUwMiB8IEtpZXbCoA==