Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Sep 2015 18:18:52 -0400
From:      Jung-uk Kim <jkim@FreeBSD.org>
To:        Andriy Gapon <avg@FreeBSD.org>, Adrian Chadd <adrian.chadd@gmail.com>, Garrett Cooper <yaneurabeya@gmail.com>, John Baldwin <jhb@FreeBSD.org>
Cc:        "freebsd-acpi@freebsd.org" <freebsd-acpi@FreeBSD.org>, FreeBSD Current <freebsd-current@FreeBSD.org>, freebsd-x11@FreeBSD.org
Subject:   Re: acpi suspend debugging techniques?
Message-ID:  <55E8C74C.2080207@FreeBSD.org>
In-Reply-To: <55E88860.8020404@FreeBSD.org>
References:  <55E3F098.9060806@FreeBSD.org> <F685F242-21A2-4063-B5A6-75EA17EFCFC0@gmail.com> <CAJ-Vmo=kAgTx-stpGKQZa1970x-Q5i52mwVaTBV%2B%2BfTo6oxdVg@mail.gmail.com> <55E88860.8020404@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
-----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 <avg@icyb.net.ua> 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-----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55E8C74C.2080207>