From owner-freebsd-acpi@freebsd.org Sun Mar 13 03:39:50 2016 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 491D5A92D64; Sun, 13 Mar 2016 03:39:50 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (207-172-209-83.c3-0.arl-ubr1.sbo-arl.ma.static.cable.rcn.com [207.172.209.83]) by mx1.freebsd.org (Postfix) with ESMTP id 297C6B9D; Sun, 13 Mar 2016 03:39:49 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9] (unknown [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 5614C144F; Sun, 13 Mar 2016 03:39:43 +0000 (UTC) Subject: Blank screen on resume From: Eric McCorkle Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (13D15) Message-Id: Date: Sat, 12 Mar 2016 22:39:42 -0500 To: freebsd-acpi@freebsd.org, "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 03:39:50 -0000 Hello everyone, It seems I'm plagued by blank screens on resume again on a different laptop.= .. *sigh* I've done quite a bit of diagnostic work on this, and there seem to be some c= lues, but I'm a bit stumped at this point. The following github repo has pa= tches that add extra logging, which has proven useful in my attempts to diag= nose the issue: https://github.com/emc2/freebsd (sorry for distributing patc= hes/logs in this way, but the logs are quite big). Also in this repo, there= 's a pciconf, devinfo, and dmesg file. The dmesg file shows the trace from b= ooting a patched kernel in verbose mode then suspending it. There's two main curiosities in the dmesg trace. The first is that the powe= r state of all the vgapci device seems to be 0 as opposed to 3 during resume= , which was causing acpi_set_powerstate_method to skip resetting its power d= uring resume. I tried a simple patch (you can see it in the patch and its e= ffects in the trace), but that didn't seem to work. A second curiosity is t= hat acpi_pwr_switch_consumer only seems to have an effect during resume. The only other real lead I have is that the display doesn't seem to be activ= e in acpi_video. I'm not sure if this is an artifact of the efifb driver. Lastly, I recall looking into vga bios calls from earlier such efforts. I i= magine there's something similar for efifb, but I've been unable to track do= wn where this is happening. Advice or information on that front would be mu= ch appreciated. Best, Eric=