Date: Tue, 03 Sep 2013 16:12:01 -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: <52264291.7000509@FreeBSD.org> In-Reply-To: <201309031228.30717.jhb@freebsd.org> References: <521D03AE.3050709@sics.se> <CAN6yY1uEbQC_Yj=QOs%2B9TTOw_oVBL2TCsiAQWtqPKMu2w9s8CA@mail.gmail.com> <CAJ-Vmokm_EZh4=iC=KHY59bzP336kywn%2BaQU7y0vYpscCR_Rhg@mail.gmail.com> <201309031228.30717.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 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. > 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. > I'd argue that we should be it is a BIOS bug regardless. +1 > 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. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJkKRAAoJECXpabHZMqHOKLwIAKExzuj82Ak05a7KLzrMmqzI +W0jaoRVCWykCGBpBv4CkejiI5+sliZZcJyNVkC73HOxZuW/VMPb70JqJg83WtHH PdiZ0C/MX5zAlkErNYBiZPT9QwbinzUzbEPGRjjHSO+b3GiUSbE3OGQSBsRCEAHQ JI+4N9UFLssswZoYDeeRuD6AE24di2LGmU+OK01FKd8AvnkSI6MD3F3bBr6o1u6+ bJXMyANxG13JMbnn6QfVG02QSDUqTbG/VuQVuVQJ1ZgFjMPHGFeTEfApxa88TAR2 i5WVCGShpQLmwheQVw+yPiEPi0lLPSCiUj/gRjyvrtducZ1zHJ3f4n/kAVeIUls= =H2G/ -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52264291.7000509>