From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 3 21:04:39 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A47479E1; Tue, 3 Sep 2013 21:04:39 +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 ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5DAE729B5; Tue, 3 Sep 2013 21:04:39 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 37363B981; Tue, 3 Sep 2013 17:04:38 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) Date: Tue, 3 Sep 2013 16:47:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <521D03AE.3050709@sics.se> <201309031228.30717.jhb@freebsd.org> <52264291.7000509@FreeBSD.org> In-Reply-To: <52264291.7000509@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201309031647.47650.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Sep 2013 17:04:38 -0400 (EDT) Cc: Laura Marie Feeney , freebsd-acpi@freebsd.org, Kevin Oberman , Gleb Smirnoff , "Sergey A. Osokin" , =?iso-8859-1?q?Jean-S=E9bastien?= =?iso-8859-1?q?_P=E9dron?= X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 21:04:39 -0000 On Tuesday, September 03, 2013 4:12:01 pm Jung-uk Kim wrote: > On 2013-09-03 12:28:30 -0400, John Baldwin wrote: > > On Sunday, September 01, 2013 3:51:47 pm Adrian Chadd wrote: > >> (cc jkim) > >> > >> Hi! Would you mind taking a look at the -acpi list posts with > >> this subject? It looks like a lot of the video suspend/resume > >> issues on these thinkpads boil down to the VESA driver code. If > >> it's disabled, (at least) x11 resume works. > >> > >> Would you be able to help us track down what's going on? > >> > >> Thanks! > > > > Most likely vga_suspend()/vga_resume() in sys/isa/vga_isa.c is > > calling vidd_save_state() and vidd_load_state() which in the VESA > > case map to the _save_state() and _load_state() methods in > > sys/dev/fb/vesa.c. > > Unfortunately, I don't really know where it actually fails because I > do not have *any* Intel GPUs to test. If vesa.c is really causing > trouble, vesa_bios_post() in vesa_load_state() may be the culprit, > however. I can try narrowing it down. > > These methods look fairly sane to me, so it's probably either a > > BIOS bug, or the fact that KMS is bypassing the BIOS, so when KMS > > is active we should perhaps disable the VESA BIOS. > > AFAIK, KMS does not play nice with syscons(4) ATM, e.g., syscons does > automatic VT switching and it may need to be turned off. Again, it is > just my guess. Well, I don't have to do that, just having no VESA in the kernel results in resume working fine in X. It seems that the i915drm driver is doing something to explicitly enable the backlight on the LCD btw. > > However, one thing that might help is that this is being called at > > a "random" time rather than when vgapci0 is being suspended and > > resumed. Actually, it looks like jkim fixed this via the vgapm > > driver, except I have no vgapm0 device on my laptop. > > If you don't have vgapm0, its BIOS is not setting PCIB_BCR_VGA_ENABLE > bit to its bridge. Often times, that means it is "legacy free" stuff. > > > I wonder if it's supposed to be device_get_unit() instead of > > device_get_flags() in the vgapm identify routine? > > No. With multiple GPUs, it is (was?) the only way to find the "boot > display" because unit number is not always 0. Although dumbbell added > vga_pci_is_boot_display() in current, this interface should be kept > for 9.x. Hmm, so there is magic to set this I guess? Ah, I see it now in vga_pci.c. That does seem gross compared to an ivar or some such. :) In my case btw, x86bios_match_device() doesn't work because the BIOS ROM has a PCI device ID of 0x0106 while the device itself is 0x0126. Even with that hacked so I force vgapm0 and dpms0 to attach, I still can't resume in console mode, and resume in X refuses to wakeup with VESA in the kernel (hitting the power button doesn't make it wakeup). -- John Baldwin