From owner-freebsd-acpi@freebsd.org Tue Jul 14 22:00: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 13C879A1CA1; Tue, 14 Jul 2015 22:00:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E343E10D3; Tue, 14 Jul 2015 22:00:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A0E91B9C9; Tue, 14 Jul 2015 18:00:53 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Cc: Eric McCorkle , Adrian Chadd , "freebsd-mobile@freebsd.org" Subject: Re: Attempting to diagnose suspend/resume issue Date: Tue, 14 Jul 2015 11:19:39 -0700 Message-ID: <2064879.roFGbLrqiq@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.1-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <55A02F9C.2000308@metricspace.net> References: <559F4B70.8060402@metricspace.net> <55A02F9C.2000308@metricspace.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 14 Jul 2015 18:00:53 -0400 (EDT) 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: Tue, 14 Jul 2015 22:00:55 -0000 On Friday, July 10, 2015 04:48:28 PM Eric McCorkle wrote: > Complete dmesg trace attached > > Correction: it looks like it tries to save the state after the power's > been turned off. > > Possibly related: the SD card reader started failing to come back up at > the same patch. Note that while vga0 is later in the suspend, it is actually more of a dummy device on isa0. I think it is sc/vt that actually save/restore the frame buffer. Still, can you add a debug printf in bus_generic_suspend_child() in sys/kern/subr_bus.c to note when DEVICE_SUSPEND() is called for each device (something like 'device_printf(child, "calling device_suspend()\n");' above DEVICE_SUSPEND())? You can also try setting hw.pci.do_power_suspend=0 as a workaround. If that fixes it, then I think it lends credence to your suggestion. Hmm, certainly in the syscons case this is probably just exposing a old bug in that sc0 is hung off of isa0 which is not going to be in the same part of the hierarchy as the "real" VGA device. Usually isa0 is off of isab0 which is often the "last" device on pci0, so normally syscons will suspend after the VGA device is powered down. I think vt(4) should in theory do this better, though it might only do so if you have a drm driver loaded. When drm is loaded and there is a drm-specific vt(4) backend, then it will be suspended as part of the tree under the real VGA device. -- John Baldwin