Date: Tue, 03 Sep 2013 18:52:13 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: Laura Marie Feeney <lmfeeney@sics.se>, freebsd-acpi@freebsd.org, Kevin Oberman <rkoberman@gmail.com>, Gleb Smirnoff <glebius@freebsd.org>, "Sergey A. Osokin" <osa@freebsd.org>, =?ISO-8859-1?Q?Jean-S=E9bastien_?= =?ISO-8859-1?Q?P=E9dron?= <dumbbell@freebsd.org> Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) Message-ID: <5226681D.5010101@FreeBSD.org> In-Reply-To: <201309031647.47650.jhb@freebsd.org> References: <521D03AE.3050709@sics.se> <201309031228.30717.jhb@freebsd.org> <52264291.7000509@FreeBSD.org> <201309031647.47650.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5226681D.5010101>