From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 3 22:54:32 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id DEA5AC0C; Tue, 3 Sep 2013 22:54:31 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <5226681D.5010101@FreeBSD.org> Date: Tue, 03 Sep 2013 18:52:13 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130814 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Baldwin Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) References: <521D03AE.3050709@sics.se> <201309031228.30717.jhb@freebsd.org> <52264291.7000509@FreeBSD.org> <201309031647.47650.jhb@freebsd.org> In-Reply-To: <201309031647.47650.jhb@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 22:54:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-09-03 16:47:47 -0400, John Baldwin wrote: > 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. Please do. >>> 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. Normally, I expect a device tree like this to do properly suspend/resume with *drm1*: nexus0 acpi0 pcib0 pci0 hostb0 pcib1 pci1 vgapci0 vgapm0 dpms0 drm0 ... isab0 isa0 sc0 vga0 ... Not sure about i915kms.ko. >>> 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. > :) And you said the almost exact same thing but okayed at the time. :-) > 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. It's a bug. > 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). Please try to make syscons resume first. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJmgdAAoJECXpabHZMqHOh6kH/RpRVeXz3n8eb72PMfZ1eQDy 2LBn/NCpxbRAHhNkwclLqCorQp6CDAEM1iO4IJMgUG4BrRYcrGUybM7kHDGn5Oy3 7qLkXmu1TmBGwFndHMZ8VaqLsUV2mgKG1DLgCCEp2NG3szOuSgg1KwBaZuT1OUhm TtJIWyuuwWld+DAaBaJJqCTJun6s3rpddXIEKj/2R+f4q99cjLt5I5qel+goArE+ yym4VrkY0S1Fn3Vj5+Nv8WMXlTgknIymsEg7fNJ9RDBGDPZ11l5DLztLjj+UfvIL K6L3+AMNJ58HRA/PibPIGNgI0WXUDJ/KSNN0A44RIItiYwTxJSh482PkghlrLE4= =jHx2 -----END PGP SIGNATURE-----