From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 1 06:42:31 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 105EAC70; Sun, 1 Sep 2013 06:42:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ED3A129F5; Sun, 1 Sep 2013 06:42:29 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA02144; Sun, 01 Sep 2013 09:42:28 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VG1Mh-000HgK-Vk; Sun, 01 Sep 2013 09:42:28 +0300 Message-ID: <5222E19C.9040402@FreeBSD.org> Date: Sun, 01 Sep 2013 09:41:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Mike Harding 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: Sun, 01 Sep 2013 06:42:31 -0000 on 01/09/2013 02:40 Adrian Chadd said the following: > > > > On 31 August 2013 10:35, Mike Harding > wrote: > > I've tracked this down to a single line, details in > http://www.freebsd.org/cgi/query-pr.cgi?pr=181632. Basically, the code is > now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed to run > if idle is disabled. Given that 'hlt' is the idle instruction, this doesn't > seem right. > > > Wow, nice! > > Avg - can we get this fixed? Or just revert this! Thank you for trying to be helpful. But let's not jump to conclusions. BTW, I am following up on the problem in the PR. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 1 15:06:15 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 969D6C22; Sun, 1 Sep 2013 15:06:15 +0000 (UTC) (envelope-from lmfeeney@sics.se) Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1EAEE21F0; Sun, 1 Sep 2013 15:06:14 +0000 (UTC) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id r81F0Qxq005585; Sun, 1 Sep 2013 17:06:11 +0200 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1eg7hk9j4t-1; Sun, 01 Sep 2013 17:06:11 +0200 Received: from [127.0.0.1] (sink.sics.se [193.10.64.88]) (Authenticated sender: lmfeeney@sics.se) by letter.sics.se (Postfix) with ESMTPSA id EE31140115; Sun, 1 Sep 2013 17:06:10 +0200 (CEST) Message-ID: <52235801.8040001@sics.se> Date: Sun, 01 Sep 2013 17:06:41 +0200 From: Laura Marie Feeney User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20110202 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Sergey A. Osokin" Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) References: <521D03AE.3050709@sics.se> <20130830145102.GG32399@FreeBSD.org> <201308301153.23184.jhb@freebsd.org> <20130830215355.GH32399@FreeBSD.org> <522118EB.5090801@sics.se> <20130831054509.GI32399@FreeBSD.org> In-Reply-To: <20130831054509.GI32399@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-01_04:2013-08-30,2013-09-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309010090 Cc: freebsd-acpi@freebsd.org, Gleb Smirnoff X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lmfeeney@sics.se List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 15:06:15 -0000 >>> Gleb and Luara, could you try x11-wm/i3 for suspend/resume trick and check >>> slowdown? >> x11perf data for twm are at http://www.sics.se/~lmfeeney/9.2-RC2 I used firefox and flickr.com as subjective test. After several suspend/resume cycles, scrolling through pictures became noticeably slower. I didn't notice any slowdown before this. The *_after data are from this point. The xperf11 results don't seem very consistent: Some tests run faster before and some after, hopefully the data will be more useful to an X expert. The machine was idle (xterm and xclock only), but not in single user mode. x11perf data for i3wm available shortly, the test takes ~3 hours on X1 Carbon. Laura From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 1 19:51:50 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 7F81A7E5; Sun, 1 Sep 2013 19:51:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 804FF2243; Sun, 1 Sep 2013 19:51:49 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id q55so3111841wes.36 for ; Sun, 01 Sep 2013 12:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MAHfTZAYdL/KvdwOqJROQB8Y7k8FOMg/KsiH7pNSWas=; b=T0+gLqFXtAoytkVqptaYIKrHlri6PzwNMPxzs2QJxUhIQYnbp5cmsC7pom/T9yglxD 5qX5ZKWhUsXbpl4JHxoRTYkqnMANOKw+8tYjeRsCIcQbjqkpL+4nN3nrw7bo1ZazewL8 zTlyD1Uzj9Vv4CnllkUrmP0Z7Z9ZmIl7sukIAtddeVcv7ez6httmSq4F3yjUFHlxSGh9 gTHAbfAZcXQ1sqCT+N7wHp4LSJ5tXQmEanqqZ43LbEld9iREceXZ5VRY1VrcfyjPtyEd zW8dAxorFrEzRLMhfa1gSynAEBzcemjI5eKbTpTmJN7GL6GYw5B1LS9EXBmKbm4sxyqF /9sw== MIME-Version: 1.0 X-Received: by 10.180.37.164 with SMTP id z4mr10767421wij.30.1378065107606; Sun, 01 Sep 2013 12:51:47 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.146.2 with HTTP; Sun, 1 Sep 2013 12:51:47 -0700 (PDT) In-Reply-To: References: <521D03AE.3050709@sics.se> <20130830145102.GG32399@FreeBSD.org> <201308301153.23184.jhb@freebsd.org> <20130830215355.GH32399@FreeBSD.org> <522118EB.5090801@sics.se> <20130831063908.GJ32399@FreeBSD.org> Date: Sun, 1 Sep 2013 12:51:47 -0700 X-Google-Sender-Auth: U_X5CXGgCK7FUcAUI1GD03HqWzo Message-ID: Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) From: Adrian Chadd To: Kevin Oberman , Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Laura Marie Feeney , "freebsd-acpi@freebsd.org" , Gleb Smirnoff , "Sergey A. Osokin" 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: Sun, 01 Sep 2013 19:51:50 -0000 (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! -adrian On 31 August 2013 10:23, Kevin Oberman wrote: > On Sat, Aug 31, 2013 at 9:53 AM, Adrian Chadd wrote: > >> Ok. >> >> I'm glad this is actually working for people. >> >> But now comes the hard bit - figuring out why the VESA driver is breaking >> resume. :( >> >> I actually use VESA text modes in console mode so I'll take a look but I >> can't promise anything. >> >> Who actually has experience with the VESA code and may be able to help? >> Does anyone know? >> >> Thanks, >> >> >> >> -adrian >> >> > Of course this is the real issue. Removing VESA is just a band-aid and > will become a problem once newcons makes it out the door (any day now). > > I'd like to try to figure out the scope of the problem, if possible. In > most (all?) reports, removing VESA has worked on Thinkpads. I think I have > seen reports that it works on other platforms, but I'm not positive. I also > believe that it has been reported to not work for attempts to > suspend/resume when in text mode... only when in X. (I guess I can test > this myself.) > > For almost four years all vesa commits were by jkim. > > -- > R. Kevin Oberman, Network Engineer > E-mail: rkoberman@gmail.com > From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 1 20:40:44 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 D141E88A; Sun, 1 Sep 2013 20:40:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 152DB24A7; Sun, 1 Sep 2013 20:40:43 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id l18so333041wgh.16 for ; Sun, 01 Sep 2013 13:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+pP6GjNDfUDbLgtBGg2rfZsLHmha8o//3ObcRKQoPmk=; b=tL3fWtYqwEyKhAX4y7eKGLmKqz++dOrsKzWp24rrFDc8zgrU6EFkgIUjs0gi6aYADC qN2S8ff+Mx1Rqjy+hg8tqMd/vpQtv1IzeR70GXuPRSvGDUthrnnqwNrCwhPI/SalnSfk 7Pb36xyOyK/UTtKf+AlUbOARhBNUdOA3c0t2ODsJngakRxdUmZlV8XYNF47jhvcvT53Q EKfsDZGBW+u7MdxM6xjzeuP0hqTXwAL+3jCMxMekLo8C0iopNHH9cjaAidQpscuL+RYY aVBjA372NUa8CW99gDrDWEfiK3OU8PQ6bt7PGiX7V7YCyssupZukkhBO0K8RiH0yb591 8qsA== MIME-Version: 1.0 X-Received: by 10.180.37.164 with SMTP id z4mr10911294wij.30.1378068041804; Sun, 01 Sep 2013 13:40:41 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.146.2 with HTTP; Sun, 1 Sep 2013 13:40:41 -0700 (PDT) In-Reply-To: <5222E19C.9040402@FreeBSD.org> References: <5222E19C.9040402@FreeBSD.org> Date: Sun, 1 Sep 2013 13:40:41 -0700 X-Google-Sender-Auth: BayHoyoSKTHzmC1H4Y09Zfzfotc Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Mike Harding 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: Sun, 01 Sep 2013 20:40:44 -0000 On 31 August 2013 23:41, Andriy Gapon wrote: > > > > I've tracked this down to a single line, details in > > http://www.freebsd.org/cgi/query-pr.cgi?pr=181632. Basically, the > code is > > now doing a 'sti, hlt' vs. a 'sti' in some code that is only > supposed to run > > if idle is disabled. Given that 'hlt' is the idle instruction, this > doesn't > > seem right. > > > > > > Wow, nice! > > > > Avg - can we get this fixed? Or just revert this! > > Thank you for trying to be helpful. But let's not jump to conclusions. > BTW, I am following up on the problem in the PR. > Sure, I'd like to know why it's behaving badly. But since we're so close to 9.2-REL, do you think you can get it sorted out and bug-free on all the existing platforms that people are using 9.2 on (including server, desktop and laptop) without reverting it? Reverting and fixing it later seems like the safest option to me. Is there a bigger problem that you tried to fix in that patch that wasn't as obvious? Thanks, -adrian From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 1 21:36:21 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CB63F410; Sun, 1 Sep 2013 21:36:21 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A53CD26CA; Sun, 1 Sep 2013 21:36:20 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA11313; Mon, 02 Sep 2013 00:36:12 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VGFJc-000Ip7-EG; Mon, 02 Sep 2013 00:36:12 +0300 Message-ID: <5223B313.9060708@FreeBSD.org> Date: Mon, 02 Sep 2013 00:35:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance References: <5222E19C.9040402@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Mike Harding 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: Sun, 01 Sep 2013 21:36:21 -0000 on 01/09/2013 23:40 Adrian Chadd said the following: > On 31 August 2013 23:41, Andriy Gapon > > wrote: > > > > > I've tracked this down to a single line, details in > > http://www.freebsd.org/cgi/query-pr.cgi?pr=181632. Basically, the code is > > now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed > to run > > if idle is disabled. Given that 'hlt' is the idle instruction, this > doesn't > > seem right. > > > > > > Wow, nice! > > > > Avg - can we get this fixed? Or just revert this! > > Thank you for trying to be helpful. But let's not jump to conclusions. > BTW, I am following up on the problem in the PR. > > > Sure, I'd like to know why it's behaving badly. But since we're so close to > 9.2-REL, do you think you can get it sorted out and bug-free on all the existing > platforms that people are using 9.2 on (including server, desktop and laptop) > without reverting it? Do you have any evidence that there is anybody else besides Mike who has this problem? Also, I usually try to "sort out" things after there is a clear understanding of what the problem is and how it should be fixed. > Reverting and fixing it later seems like the safest option to me. Is there a > bigger problem that you tried to fix in that patch that wasn't as obvious? I do not see any problem with the code*.* I do not see any explanation of the root cause of the problem that Mike has. I do not see why anything has to be reverted. Especially because "since we're so close to 9.2-REL". Just in case, I'll remind that the commit in question is in stable/9 since Dec 23 2012. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 1 21:58:32 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 CAC288C0; Sun, 1 Sep 2013 21:58:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F25E027AC; Sun, 1 Sep 2013 21:58:31 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w60so3495991wes.29 for ; Sun, 01 Sep 2013 14:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dhzOgP9Evd6NgojDkPJFJmWBRsN7wJL70CV2/JYUltk=; b=AcIyR8EXmFrSKN9qtruQZXPjMVM4oTZbpvKOSXOq00j5FkyRk+LjIXhWXkytxFnSCF Cc+k9QCVYN8KqUu17RVPadQxj+SnMFYciXh/cwBrf6YVDjp3r/IVKq2hIosZnCikOVI5 ShA2jcMLDKuyv+KPo9KZ1V5awS14VGHSeQUdymLqq7xFBVTfwGBoN+0myanbJZQBkZso aW2s/5twXuFmApwzFlH8ERRSmaN4KA2puiEwLpTLvi/nE/jvh/Z7iPxzZNOHGud8r7mq FmP8PowSn7BAw0jzox0UWQF4pUSromNzmhEWwOE4H8EIK48a+xXF5iAEbd35EJdFJYN4 UF4A== MIME-Version: 1.0 X-Received: by 10.180.8.42 with SMTP id o10mr11236796wia.0.1378072709730; Sun, 01 Sep 2013 14:58:29 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.146.2 with HTTP; Sun, 1 Sep 2013 14:58:29 -0700 (PDT) In-Reply-To: <5223B313.9060708@FreeBSD.org> References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> Date: Sun, 1 Sep 2013 14:58:29 -0700 X-Google-Sender-Auth: H7DTAwVcmUqmrfEMXuEtRmfdKZ8 Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Mike Harding 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: Sun, 01 Sep 2013 21:58:32 -0000 On 1 September 2013 14:35, Andriy Gapon wrote: > Do you have any evidence that there is anybody else besides Mike who has > this > problem? > Nope! but we can't assume that users are reporting all the system slowdowns. And honestly, I've heard enough strange stories on mailing lists and IRC of things like "during disk IO, blah would be really slow, when I change timekeeping or halt from ACPI to something else, things get better." So I can't discount that this is affecting people and they either don't know, or just chalk it up as "shitty hardware." Also, I usually try to "sort out" things after there is a clear > understanding of > what the problem is and how it should be fixed. > > Well, the big change is that it's now going into a sleep state on a HT core, right? Are you able to go into an ACPI sleep state on a HT logical CPU, rather than the physical core? Or am I mis-understanding what's going on? > > Reverting and fixing it later seems like the safest option to me. Is > there a > > bigger problem that you tried to fix in that patch that wasn't as > obvious? > > I do not see any problem with the code*.* I do not see any explanation of > the > root cause of the problem that Mike has. I do not see why anything has to > be > reverted. Especially because "since we're so close to 9.2-REL". > Just in case, I'll remind that the commit in question is in stable/9 since > Dec > 23 2012. > > Right, but I also know a lot of people who just have stayed with 8.x or 9.0-RELEASE and haven't bothered upgrading. Again, I can't assume that everyone has been keeping up to date with stable/9 and providing feedback. Thanks, -adrian From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 1 22:04:47 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8A062C20; Sun, 1 Sep 2013 22:04:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4984E2807; Sun, 1 Sep 2013 22:04:45 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA11670; Mon, 02 Sep 2013 01:04:44 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VGFlE-000Irc-3P; Mon, 02 Sep 2013 01:04:44 +0300 Message-ID: <5223B9C3.2070508@FreeBSD.org> Date: Mon, 02 Sep 2013 01:03:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Mike Harding 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: Sun, 01 Sep 2013 22:04:47 -0000 on 02/09/2013 00:58 Adrian Chadd said the following: > On 1 September 2013 14:35, Andriy Gapon > wrote: > > > Do you have any evidence that there is anybody else besides Mike who has this > problem? > > > > Nope! but we can't assume that users are reporting all the system slowdowns. Why? > And honestly, I've heard enough strange stories on mailing lists and IRC of > things like "during disk IO, blah would be really slow, when I change > timekeeping or halt from ACPI to something else, things get better." So I can't > discount that this is affecting people and they either don't know, or just chalk > it up as "shitty hardware." Strange stories are just that. > Also, I usually try to "sort out" things after there is a clear understanding of > what the problem is and how it should be fixed. > > > Well, the big change is that it's now going into a sleep state on a HT core, right? > > Are you able to go into an ACPI sleep state on a HT logical CPU, rather than the > physical core? Or am I mis-understanding what's going on? Most likely. I do not see how the change is HT-specific or HT-related at all. > > > Reverting and fixing it later seems like the safest option to me. Is there a > > bigger problem that you tried to fix in that patch that wasn't as obvious? > > I do not see any problem with the code*.* I do not see any explanation of the > root cause of the problem that Mike has. I do not see why anything has to be > reverted. Especially because "since we're so close to 9.2-REL". > Just in case, I'll remind that the commit in question is in stable/9 since Dec > 23 2012. > > > Right, but I also know a lot of people who just have stayed with 8.x or > 9.0-RELEASE and haven't bothered upgrading. Again, I can't assume that everyone > has been keeping up to date with stable/9 and providing feedback. I am positive that it's not everyone who uses (up-to-date) stable/9. Still, I believe that a user-base of stable/9 is >> 1. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 1 22:21:58 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0647D104; Sun, 1 Sep 2013 22:21:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A2AE28DD; Sun, 1 Sep 2013 22:21:57 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id cb5so15265wib.9 for ; Sun, 01 Sep 2013 15:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FILi6APwSH5WlkfZUnUVfArsNjrZgEFnxsohfYyQBTA=; b=cG22GVf7DKi+PITKaOhuHURT06G7+NdA6w5pVlHvxLrcx2JkpH4uIWkMJcjX9cFyQJ a6W8wo91esmQdK0/pcZhFntoScpMSN+/MHiV6wdE+ed6rU13shDXPiRVixm3pYltwD0s 5EwvyXFEZlExd017FVCCiBIKvrhtKLsYNhZJ9oY3XwLKcjfNGnfi3aZA8+3oVRAB0x6e prKdBSILEq1EiC6f9RDxOROv0VOiQLd5jwEKEy6QAwC234lFdmUoMyTiVtGojlDfxLKe OY068CCaDPyj/foral0TyIVy2gzh7artyeAZ+yqzRAJGyCOxcECN9PxKiBC1jgGxnQO2 3XGw== MIME-Version: 1.0 X-Received: by 10.180.72.198 with SMTP id f6mr11085195wiv.46.1378074115345; Sun, 01 Sep 2013 15:21:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.146.2 with HTTP; Sun, 1 Sep 2013 15:21:55 -0700 (PDT) In-Reply-To: <5223B9C3.2070508@FreeBSD.org> References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> Date: Sun, 1 Sep 2013 15:21:55 -0700 X-Google-Sender-Auth: O2pV1mL9kRhK0-9h-NvtKy0XVcw Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Mike Harding 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: Sun, 01 Sep 2013 22:21:58 -0000 .. well, when is that pointer NULL? It looks like it's supposed to be NULL for one pair of the two HT CPUs? Are you taking the whole core into an ACPI idle state if one of two logical CPUs representing a core is going idle? -adrian From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 1 23:13:16 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 596CF8F0; Sun, 1 Sep 2013 23:13:16 +0000 (UTC) (envelope-from mvharding@gmail.com) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 673D52BC1; Sun, 1 Sep 2013 23:13:15 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id c11so1236342wgh.1 for ; Sun, 01 Sep 2013 16:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tlSW+JdT/E5H9P5CaLXK50Q6dqSTE19VjOYwNyanDFk=; b=PHzbjgBUeRIs6MXrgKtUMeJcepFwzTA66U+mrHP6S07UeNtvoVXdcKJ6yZ6XjhYsUX IYXeu4ynNYB9fccUj3dw0Fr2UOpgj12I5ZnFU/a5JWgvtpqEQIQF5nrP3N5i9zbSIsql HGd1MltKwCtLpeNlzRlJ5ctx5Sabhd8DwMSxGSyjcmIP/aIYkryUins3IFDGuifWsrM0 iXfXuE89hGo4ocvtcyfMrTi+egVMwLCEf0jnn7sPH8GfX6AuaO1mLOvkmwf2ZHlqssDW fwaDZUxGmNO5rIbKuJg76l979eqD0qy4kLjPCT4JWXe959kiiTZJG0D521K8JojDmBN3 mF6Q== MIME-Version: 1.0 X-Received: by 10.194.178.166 with SMTP id cz6mr35207wjc.53.1378077193737; Sun, 01 Sep 2013 16:13:13 -0700 (PDT) Received: by 10.217.67.69 with HTTP; Sun, 1 Sep 2013 16:13:13 -0700 (PDT) In-Reply-To: References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> Date: Sun, 1 Sep 2013 16:13:13 -0700 Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Mike Harding To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Andriy Gapon 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: Sun, 01 Sep 2013 23:13:16 -0000 This would be a 'strange story' if I had not tracked this down. The disk works, only much slower than normal. I only noticed it because I was doing a buildworld. There is no crash, no dmesg, no console logs. I'll ask again, why change that line? Did you feel that the original author of the code had made a mistake? The code in question is from Oct. 2005. Also why move the check for the HT in front of the check for the disabled idle? The only change that affects my system is that idle is enabled in a code path that should only be run when idle is disabled. I don't know the larger context but I also don't know why the code was changed. It looks like the intent of the code has been changed ("don't suspend if this flag is set") and I don't know what benefit this provides. The code path seems to only be run during startup, shutdown and wake from sleep. Contact me via email and I'll set up remote access. This is a personal machine so this is a bit awkward. From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 2 01:40:39 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 25E696DD; Mon, 2 Sep 2013 01:40:39 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E81552616; Mon, 2 Sep 2013 01:40:38 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 8A5138A7D; Mon, 2 Sep 2013 01:40:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 8A5138A7D Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 1 Sep 2013 21:40:29 -0400 From: Glen Barber To: Adrian Chadd Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) Message-ID: <20130902014029.GA2243@glenbarber.us> References: <20130830145102.GG32399@FreeBSD.org> <201308301153.23184.jhb@freebsd.org> <20130830215355.GH32399@FreeBSD.org> <522118EB.5090801@sics.se> <20130831063908.GJ32399@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Laura Marie Feeney , "freebsd-acpi@freebsd.org" , Kevin Oberman , Gleb Smirnoff , "Sergey A. Osokin" 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: Mon, 02 Sep 2013 01:40:39 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 01, 2013 at 12:51:47PM -0700, Adrian Chadd wrote: > (cc jkim) >=20 > Hi! Would you mind taking a look at the -acpi list posts with this subjec= t? > 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. >=20 Just to clarify on some information I provided a few days ago, I did not realize at first (when I replied) that this thread was targeted towards Thinkpad laptops. For what it is worth, my laptop is an ASUS X53E. For a long time, suspend/resume did not work (well, resume did not work, suspend worked fine). avg@ fixed this with r246251. However, after a few weeks, the next Xorg update broke it. In between those updates, I did not change anything for my kernel config (in fact, the latest thing I recall adding/removing was the VESA to test this out). TLDR: this is broader than "just Thinkpads". I am happy to put VESA back into my kernel config and test patches, if that is helpful. Glen --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBCAAGBQJSI+yNAAoJEFJPDDeguUaj5iwH/jng//5w+xlqaGq2y2Tp+TxI 2Syr2szR/ZbdgZMINbJOYZNrkea4FUwUxvvl+/wrkmS6xPBjm7oUTigiKD2Bbcgv Ib0/8QuZf36ZL0Ki/UDxjlnW1xCqEcBS/Jhcz5mxw7AfkYsRTfbhqGCvykFGxbII 7j10DilLmDu97Az1rhDUwPg+oIQCVPEAhL9O2dGJt6cL/Qgn+5e12IysoWx/vK1D KdSc6Ur8/ryhJ45ZcFaYa3fEPh65/4YpPy5jqs8ytQ/4l41saZTQodw4Bj4GBBpP vu54wwzlvhSkblRh2SSZBAgLyESqkgJfF7UjH8XjDjXdgwYJUrGXqDpBBFstDNY= =IfsH -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 2 04:47:48 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F3804843; Mon, 2 Sep 2013 04:47:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CDE9D2D18; Mon, 2 Sep 2013 04:47:46 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id HAA15790; Mon, 02 Sep 2013 07:47:44 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VGM3E-000MHz-Lt; Mon, 02 Sep 2013 07:47:44 +0300 Message-ID: <52241838.8020906@FreeBSD.org> Date: Mon, 02 Sep 2013 07:46:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Mike Harding 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: Mon, 02 Sep 2013 04:47:48 -0000 on 02/09/2013 01:21 Adrian Chadd said the following: > .. well, when is that pointer NULL? It's never NULL. But that is besides the point as we are talking about a different check. * if (is_idle_disabled(sc)) {* - ACPI_ENABLE_IRQS(); + acpi_cpu_c1(); > It looks like it's supposed to be NULL for > one pair of the two HT CPUs? > > Are you taking the whole core into an ACPI idle state if one of two logical CPUs > representing a core is going idle? -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 2 04:50:56 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 43A9DA61; Mon, 2 Sep 2013 04:50:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 23C7C2D75; Mon, 2 Sep 2013 04:50:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id HAA15817; Mon, 02 Sep 2013 07:50:53 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VGM6G-000MIB-RG; Mon, 02 Sep 2013 07:50:52 +0300 Message-ID: <522418F4.9030007@FreeBSD.org> Date: Mon, 02 Sep 2013 07:49:56 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mike Harding Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Mailing List , "freebsd-acpi@freebsd.org" 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: Mon, 02 Sep 2013 04:50:56 -0000 on 02/09/2013 02:13 Mike Harding said the following: > I'll ask again, why change that line? I got your question the first few times you asked it. I do not see why you keep asking it when nobody has a clear explanation of what exactly is going on on your system and I've already told that I want to investigate / analyze that first. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 2 05:46:59 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 99790597; Mon, 2 Sep 2013 05:46:59 +0000 (UTC) (envelope-from mvharding@gmail.com) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A9ED12F51; Mon, 2 Sep 2013 05:46:58 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id f12so824257wgh.14 for ; Sun, 01 Sep 2013 22:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=65LnWEHbGIzsSaO5YTAsy0pp5oNV9wBg0g/evi9n3wc=; b=rJLua8N9yk9AB08e4P6e+qto/qUEoetOdzNAFKrAiwNk6LBYXokIuz8oA7KJYO//I+ 9PqotVReJPWd43NwF7YMdRZ4Gbzg429wLGaXxRQbtrF1JomDYdulGMJRHeK/DlnY0FLH jn7zIC9H4V0uoLfgrksSRHWvkRLr2keqCS6bQIuiQl/4WmsTE3Glqemt8Knh0GSvID2g ED+jSTDteG5hAzFhlcVfRCTkMlct0SAM+IUUnXAAw45GaaWj8kPwGK1+8l7paT6MR9Lw t4/O6uc2cVA45vXoxW3aYXFG8J4OgUgWzfzDZ6QDBhKaNvIC/j5kdIxoDBD5XdR1ImZM anqA== MIME-Version: 1.0 X-Received: by 10.194.19.5 with SMTP id a5mr286025wje.48.1378100816887; Sun, 01 Sep 2013 22:46:56 -0700 (PDT) Received: by 10.217.67.69 with HTTP; Sun, 1 Sep 2013 22:46:56 -0700 (PDT) In-Reply-To: <522418F4.9030007@FreeBSD.org> References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> <522418F4.9030007@FreeBSD.org> Date: Sun, 1 Sep 2013 22:46:56 -0700 Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Mike Harding To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List , "freebsd-acpi@freebsd.org" 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: Mon, 02 Sep 2013 05:46:59 -0000 Why not put this out to stable and take a survey with more than 2 members? I am sure that there are those who will be delighted, as I was with 9.1, to discover that suspend/resume worked without rebooting the machine. I can make the system available to you, contact me at this email. I am in the PDT time zone. From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 2 11:06:40 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EE0C6FB7 for ; Mon, 2 Sep 2013 11:06:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C1DED2395 for ; Mon, 2 Sep 2013 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r82B6e4a015935 for ; Mon, 2 Sep 2013 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r82B6eH0015933 for freebsd-acpi@FreeBSD.org; Mon, 2 Sep 2013 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Sep 2013 11:06:40 GMT Message-Id: <201309021106.r82B6eH0015933@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org 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: Mon, 02 Sep 2013 11:06:41 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/181665 acpi [acpi] System will not go into S3 state. o kern/180897 acpi [acpi] ACPI error with MB p8h67 v.1405 o kern/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/173408 acpi [acpi] [regression] ACPI Regression: battery does not o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/165381 acpi [cpufreq] powerd(8) eats CPUs for breakfast o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/73823 acpi [request] acpi / power-on by timer support 28 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 2 13:35:28 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8A458BC; Mon, 2 Sep 2013 13:35:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BD06A214F; Mon, 2 Sep 2013 13:35:27 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id q59so3730910wes.41 for ; Mon, 02 Sep 2013 06:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4j5KltgmtMMH1+OMUW06jIXiB5Do60MrsTO1xTe5n4c=; b=kC0xeAMpBrllzZeb9E17fLJQUb9RdPmjZ2H2LvO+HvTR2IzZrlDlMbl8OrBEeOsrzT DYO1nafPR49wvrdsbaLCXC3Z06Y31BircvsL67ylbwh9wrCR6ME4fHW33qPPDtor7Aye YkffKyYngDsL5vusfkMq6cJKFV6eAT57rtlOvGHuDEn3h100086CUnmaxWXAAuX8HKum D6tXkZakcd+kjBE7pVdvQUtQ85Nij148+aq/XQLbjT3n+D/scYVvyJkWYNJDqftckW5/ zREH1ffzZtM5SgKiFnEBVx0YFuZFDeKSGsnZcTBf4oJlydZ6TiFr4nvHqSd+3Cx9JnBH 7kRg== MIME-Version: 1.0 X-Received: by 10.180.211.206 with SMTP id ne14mr13911670wic.30.1378128926073; Mon, 02 Sep 2013 06:35:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.146.2 with HTTP; Mon, 2 Sep 2013 06:35:25 -0700 (PDT) In-Reply-To: References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> <522418F4.9030007@FreeBSD.org> Date: Mon, 2 Sep 2013 06:35:25 -0700 X-Google-Sender-Auth: E74zhiE6t9WchBvULI4jcGcG4IY Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Adrian Chadd To: Mike Harding Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Andriy Gapon 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: Mon, 02 Sep 2013 13:35:28 -0000 So you tinkered with this - which particular line(s) did you revert back to get the old behaviour? -adrian On 1 September 2013 22:46, Mike Harding wrote: > Why not put this out to stable and take a survey with more than 2 > members? I am sure that there > are those who will be delighted, as I was with 9.1, to discover that > suspend/resume worked without > rebooting the machine. > > I can make the system available to you, contact me at this email. I am in > the PDT time zone. > > From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 2 14:25:43 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 9A7742C8; Mon, 2 Sep 2013 14:25:43 +0000 (UTC) (envelope-from mvharding@gmail.com) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A5F8226E0; Mon, 2 Sep 2013 14:25:42 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id t60so488743wes.28 for ; Mon, 02 Sep 2013 07:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8fSgdL0ShkaLdAchBIBO0uXUU0b+J2PcE3MHnT9UafI=; b=HaRZCnSyK8mpItwlLLgWiHI9pbFaAfvDH+6qx/zpoDcaLxSwPvQT1j2IEDGF8pfyZ0 e/zrXOCtiVfLOf3ymEUijmtSQHnO9yAdar5s53J5KUcpksIYjM/BKcaXztBhU+f4BZJu iu/dGH/LbbSvZ6VmDgu8LnnRbHT1/XeYi3yOzFuUQCt5uzoPSEGeor0Y2IhIs6ju61U1 +zZBBmg+vJXXpKdguJQtgWPzrUmxoX0puyg1yQhZLLZJCVDnHQN+z+K+72OjRbdm0zsD sMdXaxjNGwAjOypsvl+eJ/vX0oRQZ3kHyJQ9VInO+v4DjsTRWrVL9WQpJDBnbRqYP5zu GpnQ== MIME-Version: 1.0 X-Received: by 10.180.72.104 with SMTP id c8mr13923576wiv.63.1378131940960; Mon, 02 Sep 2013 07:25:40 -0700 (PDT) Received: by 10.217.67.69 with HTTP; Mon, 2 Sep 2013 07:25:40 -0700 (PDT) In-Reply-To: References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> <522418F4.9030007@FreeBSD.org> Date: Mon, 2 Sep 2013 07:25:40 -0700 Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Mike Harding To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Andriy Gapon 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: Mon, 02 Sep 2013 14:25:43 -0000 It's detailed in the ticket, see http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for 'reverted'. On Mon, Sep 2, 2013 at 6:35 AM, Adrian Chadd wrote: > So you tinkered with this - which particular line(s) did you revert back > to get the old behaviour? > > -adrian > > From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 2 14:29:25 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 45BA75A9; Mon, 2 Sep 2013 14:29:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 778CA2770; Mon, 2 Sep 2013 14:29:24 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id c11so1858567wgh.3 for ; Mon, 02 Sep 2013 07:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=e5Vt2ezBEEUs0Q8KXFDiSoz6VL10rSATImopfQSs8mw=; b=D/iKt+B06E8b4nNilbZUXmOajQs10P4fUTZ2k1pnHkQJSey1mmESGyPHmrj3RCxK3j d6GOCPYbcrKV9kl+CwC4lnEYDBxeUqlMMjpwpYDBTp/GqdjVnK5W+X229waXRWoqJheb KETXeWrF/+SdUtEevrAwzs3HbEJI71b+a3WjeCJGXK5Yqdz4kxDCv8fExttPOlQSnosA uCSUdatxWEHtTSj7rLh7U8u88V7AOGgWaRFUld1/qDhKOfyMrnyZg5GDnM9i9ql75rbv qIVgWFV7UfzrNTZYE/0ty8z7bljABRslSJ9zblq7noYykzGvczxDzGBHjSjn0wFmobw6 sBIw== MIME-Version: 1.0 X-Received: by 10.180.72.198 with SMTP id f6mr14023973wiv.46.1378132162711; Mon, 02 Sep 2013 07:29:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.146.2 with HTTP; Mon, 2 Sep 2013 07:29:22 -0700 (PDT) In-Reply-To: References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> <522418F4.9030007@FreeBSD.org> Date: Mon, 2 Sep 2013 07:29:22 -0700 X-Google-Sender-Auth: Q65bufPzkILe1R2IwOzmfjFEX10 Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Adrian Chadd To: Mike Harding Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Andriy Gapon 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: Mon, 02 Sep 2013 14:29:25 -0000 On 2 September 2013 07:25, Mike Harding wrote: > It's detailed in the ticket, see > http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for > 'reverted'. > > Ok. You and avg@ are digging into it deeper, so I'll leave it be for now. I'll retest this on my test laptops when I'm back home. -adrian From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 3 19:08:29 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 E5DB553C; Tue, 3 Sep 2013 19:08:29 +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 AF9312FB9; Tue, 3 Sep 2013 19:08:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7DE78B965; Tue, 3 Sep 2013 15:08:27 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) Date: Tue, 3 Sep 2013 12:28:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <521D03AE.3050709@sics.se> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201309031228.30717.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 03 Sep 2013 15:08:27 -0400 (EDT) Cc: Laura Marie Feeney , Kevin Oberman , Gleb Smirnoff , "Sergey A. Osokin" 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 19:08:30 -0000 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. 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. I'd argue that we should be it is a BIOS bug regardless. 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. I wonder if it's supposed to be device_get_unit() instead of device_get_flags() in the vgapm identify routine? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 3 20:14:20 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 D4C7761E; Tue, 3 Sep 2013 20:14:19 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <52264291.7000509@FreeBSD.org> Date: Tue, 03 Sep 2013 16:12:01 -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> In-Reply-To: <201309031228.30717.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 20:14:20 -0000 -----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----- 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 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----- From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 4 16:54:55 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 9063F8BD; Wed, 4 Sep 2013 16:54:54 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <52276554.6020807@FreeBSD.org> Date: Wed, 04 Sep 2013 12:52:36 -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> <201309031647.47650.jhb@freebsd.org> <522669AF.5000209@FreeBSD.org> <201309040929.35903.jhb@freebsd.org> In-Reply-To: <201309040929.35903.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 , Kevin Oberman , Gleb Smirnoff , "Sergey A. Osokin" , =?ISO-8859-1?Q?Jean-S=E9bastien_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: Wed, 04 Sep 2013 16:54:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-09-04 09:29:35 -0400, John Baldwin wrote: > On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: >> On 2013-09-03 16:47:47 -0400, John Baldwin wrote: >>> Even with that hacked so I force vgapm0 and dpms0 to attach, I >>> still can't resume in console mode, ... >> >> What happens? Does it panic, hang, or just no backlight? > > Just no backlight. It resumes fine and if I do it in multiuser I > can ssh in, etc. It's just the backlight that doesn't resume. I > was hopeful dpms.ko would fix that, but it didn't. :( Ah, that's a well-known problem and we cannot fix it without help of machine-specific code, e.g., drm1/drm2. Actually, both acpi_video and dpms try to restore video settings but nothing worked for Intel GPUs + LVDS + LCD panel AFAIK. > I think i915drm has code to specifically turn on the backlight as > I get some weird error message in the kernel console about a > timeout trying to turn the panel off during suspend when I'm in X. So, I guess it has an ordering issue. If my memory serves, drm1 was okay with vesa, however. I *think* it accidentally worked because of automatic VT-switching, which is still broken for KMS. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJ2VUAAoJECXpabHZMqHOJtgIAIagXbUGDBGR6cdu1EncP8bU eN+03coO4KBsCuFesNkOBF8GgCsoGf+n+IrUjGnazuyK9UTi5flLMieg3TpIkGrL YxOTTo6hfMswII8c5B67ZqPjvY/EmhgQdCQ34WsUGptDvUnqq23u3ounOiQY75iu FXJqQf5s1X6M5a5bzgvfWZd8yhJhUoYsrQftFOpiZBx1Xyb6hrfCRUJquQklx1Y8 zFDVYm6zr34Aan/lHOWTjAI2ZWBFeiu6BswWdFy2BCbKUUh5b9tToBikfsBRWmSn isgnm4y8NNDlz/wY42eoXvGFonJLH6+lR7sasxQayIZU7bkfrLlgs9SBex1vh4g= =dj+e -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 4 19:12:52 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A55E6C28; Wed, 4 Sep 2013 19:12:52 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 185272D16; Wed, 4 Sep 2013 19:12:51 +0000 (UTC) Received: from P142.sics.se (h139n3-u-d1.ias.bredband.telia.com [90.228.197.139]) by sink.sics.se (8.14.5/8.14.5) with ESMTP id r84JCfr9044833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Sep 2013 21:12:41 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.5/8.14.5) with ESMTP id r84JEWGP005907; Wed, 4 Sep 2013 21:14:32 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.5/8.14.5/Submit) id r84JEWIL005906; Wed, 4 Sep 2013 21:14:32 +0200 (CEST) (envelope-from bengta@P142.sics.se) From: Bengt Ahlgren To: Jung-uk Kim Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) In-Reply-To: <52276554.6020807@FreeBSD.org> (Jung-uk Kim's message of "Wed, 04 Sep 2013 12:52:36 -0400") References: <521D03AE.3050709@sics.se> <201309031647.47650.jhb@freebsd.org> <522669AF.5000209@FreeBSD.org> <201309040929.35903.jhb@freebsd.org> <52276554.6020807@FreeBSD.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) Date: Wed, 04 Sep 2013 21:14:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: Kevin Oberman , freebsd-acpi , Laura Marie Feeney , Gleb Smirnoff , "Sergey A. Osokin" , =?iso-8859-1?Q?Jean-S=E9bastien_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: Wed, 04 Sep 2013 19:12:52 -0000 Jung-uk Kim writes: > On 2013-09-04 09:29:35 -0400, John Baldwin wrote: >> On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: >>> On 2013-09-03 16:47:47 -0400, John Baldwin wrote: >>>> Even with that hacked so I force vgapm0 and dpms0 to attach, I >>>> still can't resume in console mode, ... >>> >>> What happens? Does it panic, hang, or just no backlight? >> >> Just no backlight. It resumes fine and if I do it in multiuser I >> can ssh in, etc. It's just the backlight that doesn't resume. I >> was hopeful dpms.ko would fix that, but it didn't. :( > > Ah, that's a well-known problem and we cannot fix it without help of > machine-specific code, e.g., drm1/drm2. Actually, both acpi_video and > dpms try to restore video settings but nothing worked for Intel GPUs + > LVDS + LCD panel AFAIK. > >> I think i915drm has code to specifically turn on the backlight as >> I get some weird error message in the kernel console about a >> timeout trying to turn the panel off during suspend when I'm in X. > So, I guess it has an ordering issue. If my memory serves, drm1 was > okay with vesa, however. I *think* it accidentally worked because of > automatic VT-switching, which is still broken for KMS. Yes, perhaps, but there is also the sysctl hw.acpi.reset_video which I have enabled on my older hardware (TP X40 running 8.3-REL and an old Xorg server) for it to work properly. (I however have some faint memory that reset_video might a no-op these days, or?) In this old mail regarding reset_video, there is a thought that it could be good with "more" reinitialisation: http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html I however have one datapoint that I think contradicts John's thought. This is on a X201 with stable/9 and no options VESA. I first just booted up and stayed in text console, suspended and resumed. No backlight, of course, and also no content on the LCD, it is completely black. Then, I started Xorg with KMS. Still no backlight, but you can see that the LCD is driven with the desired content, which is one step forward. Finally, I suspended and resumed, but no difference, the backlight is still off. Xorg/KMS didn't manage to turn the backlight on, so the text console suspend/resume cycle managed to persistently turn the backlight off. One more thing, the kernel logs this at resume directly after the devices are powered on (transition to D0), but I have no idea whether it is relevant: Sep 2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable] *ERROR* timed out waiting for panel to power off Bengt From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 4 20:04:44 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 1B519D84; Wed, 4 Sep 2013 20:04:44 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <522791D2.9050606@FreeBSD.org> Date: Wed, 04 Sep 2013 16:02:26 -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: Bengt Ahlgren Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) References: <521D03AE.3050709@sics.se> <201309031647.47650.jhb@freebsd.org> <522669AF.5000209@FreeBSD.org> <201309040929.35903.jhb@freebsd.org> <52276554.6020807@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kevin Oberman , freebsd-acpi , Laura Marie Feeney , Gleb Smirnoff , "Sergey A. Osokin" , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= 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: Wed, 04 Sep 2013 20:04:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote: > Jung-uk Kim writes: > >> On 2013-09-04 09:29:35 -0400, John Baldwin wrote: >>> On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: >>>> On 2013-09-03 16:47:47 -0400, John Baldwin wrote: >>>>> Even with that hacked so I force vgapm0 and dpms0 to >>>>> attach, I still can't resume in console mode, ... >>>> >>>> What happens? Does it panic, hang, or just no backlight? >>> >>> Just no backlight. It resumes fine and if I do it in multiuser >>> I can ssh in, etc. It's just the backlight that doesn't >>> resume. I was hopeful dpms.ko would fix that, but it didn't. >>> :( >> >> Ah, that's a well-known problem and we cannot fix it without help >> of machine-specific code, e.g., drm1/drm2. Actually, both >> acpi_video and dpms try to restore video settings but nothing >> worked for Intel GPUs + LVDS + LCD panel AFAIK. >> >>> I think i915drm has code to specifically turn on the backlight >>> as I get some weird error message in the kernel console about >>> a timeout trying to turn the panel off during suspend when I'm >>> in X. >> So, I guess it has an ordering issue. If my memory serves, drm1 >> was okay with vesa, however. I *think* it accidentally worked >> because of automatic VT-switching, which is still broken for >> KMS. > > Yes, perhaps, but there is also the sysctl hw.acpi.reset_video > which I have enabled on my older hardware (TP X40 running 8.3-REL > and an old Xorg server) for it to work properly. (I however have > some faint memory that reset_video might a no-op these days, or?) No, I didn't remove it. However, I strongly discourage it. In fact, the same functionality exists in vesa.c and it is safer. > In this old mail regarding reset_video, there is a thought that it > could be good with "more" reinitialisation: > > http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html vesa.c > does pretty much the same thing. FYI, vbetool does "more" but it does not really do more "reinitialisation". % grep ^MAINTAINER sysutils/vbetool/Makefile MAINTAINER= jkim@FreeBSD.org :-) > I however have one datapoint that I think contradicts John's > thought. This is on a X201 with stable/9 and no options VESA. I > first just booted up and stayed in text console, suspended and > resumed. No backlight, of course, and also no content on the LCD, > it is completely black. Panel may be completely off. > Then, I started Xorg with KMS. Still no backlight, but you can see > that the LCD is driven with the desired content, which is one step > forward. Finally, I suspended and resumed, but no difference, the > backlight is still off. I believe i915kms explicitly turns on LVDS/LCD panel. I guess it doesn't change brightness, though. > Xorg/KMS didn't manage to turn the backlight on, so the text > console suspend/resume cycle managed to persistently turn the > backlight off. Can you change the brightness via hotkeys or acpi_video? > One more thing, the kernel logs this at resume directly after the > devices are powered on (transition to D0), but I have no idea > whether it is relevant: > > Sep 2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable] > *ERROR* timed out waiting for panel to power off Yes, it looks relevant. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJ5HRAAoJECXpabHZMqHOZWQIAMHMrSWRw55HslMhQBpdbiI6 lT/iKNGUsHu4um9o8ULJMuuq2aKsSPxygz62a+XokefTbMEBIxQPFfcXAqvvGq2Y 6CvLjimTzfPO8axvvLRLEbVXDKcnHboabW5YxwJ6NreXwiWID+Noifc3EiEs5knj /Y0la3PP9ZWJu71DinGeyNLMoIeNdRC/E+o45P9uDTy3uZh7jBbIIwVdzAUEho+7 dN9xx88FkgYvnaNVJIf2sGmcMbMo0PJHB/9RNnz5AxNtmgVzrlEJaMMwKr1rnRu5 J5mUyuLt27/hGjSamqWaTMA/jS8gYJeF1Gyq7NWb2AvIsWHe68DY2a0MVZe1Oz0= =9xfZ -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 4 20:24:04 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 71215541; Wed, 4 Sep 2013 20:24:04 +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 13ABA22EB; Wed, 4 Sep 2013 20:24:04 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ECAF0B922; Wed, 4 Sep 2013 16:23:59 -0400 (EDT) From: John Baldwin To: Bengt Ahlgren Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) Date: Wed, 4 Sep 2013 16:23:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <521D03AE.3050709@sics.se> <52276554.6020807@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201309041623.53700.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Sep 2013 16:24:00 -0400 (EDT) Cc: Kevin Oberman , freebsd-acpi , Laura Marie Feeney , Gleb Smirnoff , =?iso-8859-15?q?Jean-S=E9bastien?= =?iso-8859-15?q?_P=E9dron?= , "Sergey A. Osokin" 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: Wed, 04 Sep 2013 20:24:04 -0000 On Wednesday, September 04, 2013 3:14:32 pm Bengt Ahlgren wrote: > Jung-uk Kim writes: > > > On 2013-09-04 09:29:35 -0400, John Baldwin wrote: > >> On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: > >>> On 2013-09-03 16:47:47 -0400, John Baldwin wrote: > >>>> Even with that hacked so I force vgapm0 and dpms0 to attach, I > >>>> still can't resume in console mode, ... > >>> > >>> What happens? Does it panic, hang, or just no backlight? > >> > >> Just no backlight. It resumes fine and if I do it in multiuser I > >> can ssh in, etc. It's just the backlight that doesn't resume. I > >> was hopeful dpms.ko would fix that, but it didn't. :( > > > > Ah, that's a well-known problem and we cannot fix it without help of > > machine-specific code, e.g., drm1/drm2. Actually, both acpi_video and > > dpms try to restore video settings but nothing worked for Intel GPUs + > > LVDS + LCD panel AFAIK. > > > >> I think i915drm has code to specifically turn on the backlight as > >> I get some weird error message in the kernel console about a > >> timeout trying to turn the panel off during suspend when I'm in X. > > So, I guess it has an ordering issue. If my memory serves, drm1 was > > okay with vesa, however. I *think* it accidentally worked because of > > automatic VT-switching, which is still broken for KMS. > > Yes, perhaps, but there is also the sysctl hw.acpi.reset_video which I > have enabled on my older hardware (TP X40 running 8.3-REL and an old > Xorg server) for it to work properly. (I however have some faint memory > that reset_video might a no-op these days, or?) In this old mail > regarding reset_video, there is a thought that it could be good with > "more" reinitialisation: > > http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html > > I however have one datapoint that I think contradicts John's thought. > This is on a X201 with stable/9 and no options VESA. I first just > booted up and stayed in text console, suspended and resumed. No > backlight, of course, and also no content on the LCD, it is completely > black. Then, I started Xorg with KMS. Still no backlight, but you can > see that the LCD is driven with the desired content, which is one step > forward. Finally, I suspended and resumed, but no difference, the > backlight is still off. Xorg/KMS didn't manage to turn the backlight > on, so the text console suspend/resume cycle managed to persistently > turn the backlight off. Try starting X before you suspend the first time. For me resume works fine if I do that. > One more thing, the kernel logs this at resume directly after the > devices are powered on (transition to D0), but I have no idea whether it > is relevant: > > Sep 2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable] *ERROR* timed out waiting for panel to power off I see this even when resume works fine. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 4 21:13:29 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 8129C7BD; Wed, 4 Sep 2013 21:13:29 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D29E2667; Wed, 4 Sep 2013 21:13:28 +0000 (UTC) Received: from P142.sics.se (h139n3-u-d1.ias.bredband.telia.com [90.228.197.139]) by sink.sics.se (8.14.5/8.14.5) with ESMTP id r84LDPrS045205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Sep 2013 23:13:25 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.5/8.14.5) with ESMTP id r84LFGcV006193; Wed, 4 Sep 2013 23:15:16 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.5/8.14.5/Submit) id r84LFG17006192; Wed, 4 Sep 2013 23:15:16 +0200 (CEST) (envelope-from bengta@P142.sics.se) From: Bengt Ahlgren To: John Baldwin Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) In-Reply-To: <201309041623.53700.jhb@freebsd.org> (John Baldwin's message of "Wed, 4 Sep 2013 16:23:53 -0400") References: <521D03AE.3050709@sics.se> <52276554.6020807@FreeBSD.org> <201309041623.53700.jhb@freebsd.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) Date: Wed, 04 Sep 2013 23:15:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: Kevin Oberman , freebsd-acpi , Laura Marie Feeney , Gleb Smirnoff , =?iso-8859-1?Q?_Jean-S=E9bastien?= =?iso-8859-1?Q?_P=E9dron?= , "Sergey A. Osokin" 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: Wed, 04 Sep 2013 21:13:29 -0000 John Baldwin writes: > On Wednesday, September 04, 2013 3:14:32 pm Bengt Ahlgren wrote: >> Jung-uk Kim writes: >> >> > On 2013-09-04 09:29:35 -0400, John Baldwin wrote: >> >> On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: >> >>> On 2013-09-03 16:47:47 -0400, John Baldwin wrote: >> >>>> Even with that hacked so I force vgapm0 and dpms0 to attach, I >> >>>> still can't resume in console mode, ... >> >>> >> >>> What happens? Does it panic, hang, or just no backlight? >> >> >> >> Just no backlight. It resumes fine and if I do it in multiuser I >> >> can ssh in, etc. It's just the backlight that doesn't resume. I >> >> was hopeful dpms.ko would fix that, but it didn't. :( >> > >> > Ah, that's a well-known problem and we cannot fix it without help of >> > machine-specific code, e.g., drm1/drm2. Actually, both acpi_video and >> > dpms try to restore video settings but nothing worked for Intel GPUs + >> > LVDS + LCD panel AFAIK. >> > >> >> I think i915drm has code to specifically turn on the backlight as >> >> I get some weird error message in the kernel console about a >> >> timeout trying to turn the panel off during suspend when I'm in X. >> > So, I guess it has an ordering issue. If my memory serves, drm1 was >> > okay with vesa, however. I *think* it accidentally worked because of >> > automatic VT-switching, which is still broken for KMS. >> >> Yes, perhaps, but there is also the sysctl hw.acpi.reset_video which I >> have enabled on my older hardware (TP X40 running 8.3-REL and an old >> Xorg server) for it to work properly. (I however have some faint memory >> that reset_video might a no-op these days, or?) In this old mail >> regarding reset_video, there is a thought that it could be good with >> "more" reinitialisation: >> >> http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html >> >> I however have one datapoint that I think contradicts John's thought. >> This is on a X201 with stable/9 and no options VESA. I first just >> booted up and stayed in text console, suspended and resumed. No >> backlight, of course, and also no content on the LCD, it is completely >> black. Then, I started Xorg with KMS. Still no backlight, but you can >> see that the LCD is driven with the desired content, which is one step >> forward. Finally, I suspended and resumed, but no difference, the >> backlight is still off. Xorg/KMS didn't manage to turn the backlight >> on, so the text console suspend/resume cycle managed to persistently >> turn the backlight off. > > Try starting X before you suspend the first time. For me resume works > fine if I do that. Yes, it does work then for me too - knew that already. Bengt From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 4 22:37:20 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 9E556E27; Wed, 4 Sep 2013 22:37:20 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DAA3D2B89; Wed, 4 Sep 2013 22:37:19 +0000 (UTC) Received: from P142.sics.se (h139n3-u-d1.ias.bredband.telia.com [90.228.197.139]) by sink.sics.se (8.14.5/8.14.5) with ESMTP id r84MbGuQ045353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Sep 2013 00:37:16 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.5/8.14.5) with ESMTP id r84Md7Mo006454; Thu, 5 Sep 2013 00:39:07 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.5/8.14.5/Submit) id r84Md72H006453; Thu, 5 Sep 2013 00:39:07 +0200 (CEST) (envelope-from bengta@P142.sics.se) From: Bengt Ahlgren To: Jung-uk Kim Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) In-Reply-To: <522791D2.9050606@FreeBSD.org> (Jung-uk Kim's message of "Wed, 04 Sep 2013 16:02:26 -0400") References: <521D03AE.3050709@sics.se> <201309031647.47650.jhb@freebsd.org> <522669AF.5000209@FreeBSD.org> <201309040929.35903.jhb@freebsd.org> <52276554.6020807@FreeBSD.org> <522791D2.9050606@FreeBSD.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) Date: Thu, 05 Sep 2013 00:39:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: Kevin Oberman , freebsd-acpi , Laura Marie Feeney , Gleb Smirnoff , "Sergey A. Osokin" , =?iso-8859-1?Q?Jean-S=E9bastien_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: Wed, 04 Sep 2013 22:37:20 -0000 Jung-uk Kim writes: > On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote: >> Jung-uk Kim writes: >> >>> On 2013-09-04 09:29:35 -0400, John Baldwin wrote: >>>> On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: >>>>> On 2013-09-03 16:47:47 -0400, John Baldwin wrote: >>>>>> Even with that hacked so I force vgapm0 and dpms0 to >>>>>> attach, I still can't resume in console mode, ... >>>>> >>>>> What happens? Does it panic, hang, or just no backlight? >>>> >>>> Just no backlight. It resumes fine and if I do it in multiuser >>>> I can ssh in, etc. It's just the backlight that doesn't >>>> resume. I was hopeful dpms.ko would fix that, but it didn't. >>>> :( >>> >>> Ah, that's a well-known problem and we cannot fix it without help >>> of machine-specific code, e.g., drm1/drm2. Actually, both >>> acpi_video and dpms try to restore video settings but nothing >>> worked for Intel GPUs + LVDS + LCD panel AFAIK. >>> >>>> I think i915drm has code to specifically turn on the backlight >>>> as I get some weird error message in the kernel console about >>>> a timeout trying to turn the panel off during suspend when I'm >>>> in X. >>> So, I guess it has an ordering issue. If my memory serves, drm1 >>> was okay with vesa, however. I *think* it accidentally worked >>> because of automatic VT-switching, which is still broken for >>> KMS. >> >> Yes, perhaps, but there is also the sysctl hw.acpi.reset_video >> which I have enabled on my older hardware (TP X40 running 8.3-REL >> and an old Xorg server) for it to work properly. (I however have >> some faint memory that reset_video might a no-op these days, or?) > > No, I didn't remove it. However, I strongly discourage it. In fact, > the same functionality exists in vesa.c and it is safer. > >> In this old mail regarding reset_video, there is a thought that it >> could be good with "more" reinitialisation: >> >> http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html > > vesa.c >> > does pretty much the same thing. FYI, vbetool does "more" but > it does not really do more "reinitialisation". > > % grep ^MAINTAINER sysutils/vbetool/Makefile > MAINTAINER= jkim@FreeBSD.org > > :-) Great! Is vesa.c = options VESA = vesa.ko? >> I however have one datapoint that I think contradicts John's >> thought. This is on a X201 with stable/9 and no options VESA. I >> first just booted up and stayed in text console, suspended and >> resumed. No backlight, of course, and also no content on the LCD, >> it is completely black. > > Panel may be completely off. > >> Then, I started Xorg with KMS. Still no backlight, but you can see >> that the LCD is driven with the desired content, which is one step >> forward. Finally, I suspended and resumed, but no difference, the >> backlight is still off. > > I believe i915kms explicitly turns on LVDS/LCD panel. I guess it > doesn't change brightness, though. > >> Xorg/KMS didn't manage to turn the backlight on, so the text >> console suspend/resume cycle managed to persistently turn the >> backlight off. > > Can you change the brightness via hotkeys or acpi_video? The value of hw.acpi.video.lcd0.brightness changes when the screen brightness keys (Fn+Home/End) are pressed, but nothing happens with the screen. Same goes for changing the value with sysctl. After a fresh boot it works with one issue. The screen brightness level seems to lag behind one keypress. Without acpi_video, screen brightness changes without the lag. hw.acpi.video.lcd0.active is always stuck at 0 - can't change with sysctl (regardless if the screen is on after a fresh boot, or black after a text console suspend/resume): [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 hw.acpi.video.lcd0.active: 0 -> 0 Again, for my old X40 with non-KMS Xorg intel driver has (curiously, the screen blinks when issuing this sysctl command): [bengta@P142 ~]$ sysctl hw.acpi.video hw.acpi.video.lcd0.active: 1 hw.acpi.video.crt0.active: 0 Jumping to another thing. The Xorg intel/KMS driver does not present a backlight property using RandR (older non-KMS intel driver did): [bengta@bit ~]$ xbacklight No outputs have backlight property Bengt >> One more thing, the kernel logs this at resume directly after the >> devices are powered on (transition to D0), but I have no idea >> whether it is relevant: >> >> Sep 2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable] >> *ERROR* timed out waiting for panel to power off > > Yes, it looks relevant. > > Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 4 22:50:06 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 E1AE7466; Wed, 4 Sep 2013 22:50:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <5227B893.1000509@FreeBSD.org> Date: Wed, 04 Sep 2013 18:47:47 -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: Bengt Ahlgren Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) References: <521D03AE.3050709@sics.se> <201309031647.47650.jhb@freebsd.org> <522669AF.5000209@FreeBSD.org> <201309040929.35903.jhb@freebsd.org> <52276554.6020807@FreeBSD.org> <522791D2.9050606@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kevin Oberman , freebsd-acpi , Laura Marie Feeney , Gleb Smirnoff , "Sergey A. Osokin" , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= 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: Wed, 04 Sep 2013 22:50:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote: > Jung-uk Kim writes: > >> On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote: >>> Jung-uk Kim writes: >>> >>>> On 2013-09-04 09:29:35 -0400, John Baldwin wrote: >>>>> On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim >>>>> wrote: >>>>>> On 2013-09-03 16:47:47 -0400, John Baldwin wrote: >>>>>>> Even with that hacked so I force vgapm0 and dpms0 to >>>>>>> attach, I still can't resume in console mode, ... >>>>>> >>>>>> What happens? Does it panic, hang, or just no >>>>>> backlight? >>>>> >>>>> Just no backlight. It resumes fine and if I do it in >>>>> multiuser I can ssh in, etc. It's just the backlight that >>>>> doesn't resume. I was hopeful dpms.ko would fix that, but >>>>> it didn't. :( >>>> >>>> Ah, that's a well-known problem and we cannot fix it without >>>> help of machine-specific code, e.g., drm1/drm2. Actually, >>>> both acpi_video and dpms try to restore video settings but >>>> nothing worked for Intel GPUs + LVDS + LCD panel AFAIK. >>>> >>>>> I think i915drm has code to specifically turn on the >>>>> backlight as I get some weird error message in the kernel >>>>> console about a timeout trying to turn the panel off during >>>>> suspend when I'm in X. >>>> So, I guess it has an ordering issue. If my memory serves, >>>> drm1 was okay with vesa, however. I *think* it accidentally >>>> worked because of automatic VT-switching, which is still >>>> broken for KMS. >>> >>> Yes, perhaps, but there is also the sysctl hw.acpi.reset_video >>> which I have enabled on my older hardware (TP X40 running >>> 8.3-REL and an old Xorg server) for it to work properly. (I >>> however have some faint memory that reset_video might a no-op >>> these days, or?) >> >> No, I didn't remove it. However, I strongly discourage it. In >> fact, the same functionality exists in vesa.c and it is safer. >> >>> In this old mail regarding reset_video, there is a thought that >>> it could be good with "more" reinitialisation: >>> >>> http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html >> >> >>> vesa.c >>> >> does pretty much the same thing. FYI, vbetool does "more" but it >> does not really do more "reinitialisation". >> >> % grep ^MAINTAINER sysutils/vbetool/Makefile MAINTAINER= >> jkim@FreeBSD.org >> >> :-) > > Great! Is vesa.c = options VESA = vesa.ko? Yes. >>> I however have one datapoint that I think contradicts John's >>> thought. This is on a X201 with stable/9 and no options VESA. >>> I first just booted up and stayed in text console, suspended >>> and resumed. No backlight, of course, and also no content on >>> the LCD, it is completely black. >> >> Panel may be completely off. >> >>> Then, I started Xorg with KMS. Still no backlight, but you can >>> see that the LCD is driven with the desired content, which is >>> one step forward. Finally, I suspended and resumed, but no >>> difference, the backlight is still off. >> >> I believe i915kms explicitly turns on LVDS/LCD panel. I guess >> it doesn't change brightness, though. >> >>> Xorg/KMS didn't manage to turn the backlight on, so the text >>> console suspend/resume cycle managed to persistently turn the >>> backlight off. >> >> Can you change the brightness via hotkeys or acpi_video? > > The value of hw.acpi.video.lcd0.brightness changes when the screen > brightness keys (Fn+Home/End) are pressed, but nothing happens with > the screen. Same goes for changing the value with sysctl. After a > fresh boot it works with one issue. The screen brightness level > seems to lag behind one keypress. Without acpi_video, screen > brightness changes without the lag. > > hw.acpi.video.lcd0.active is always stuck at 0 - can't change with > sysctl (regardless if the screen is on after a fresh boot, or > black after a text console suspend/resume): > > [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 > hw.acpi.video.lcd0.active: 0 -> 0 > > Again, for my old X40 with non-KMS Xorg intel driver has > (curiously, the screen blinks when issuing this sysctl command): > > [bengta@P142 ~]$ sysctl hw.acpi.video hw.acpi.video.lcd0.active: 1 > hw.acpi.video.crt0.active: 0 Then, KMS probably breaks acpi_video(4), too. :-( Jung-uk Kim > Jumping to another thing. The Xorg intel/KMS driver does not > present a backlight property using RandR (older non-KMS intel > driver did): > > [bengta@bit ~]$ xbacklight No outputs have backlight property > > Bengt > >>> One more thing, the kernel logs this at resume directly after >>> the devices are powered on (transition to D0), but I have no >>> idea whether it is relevant: >>> >>> Sep 2 19:57:21 bit kernel: error: >>> [drm:pid1904:intel_lvds_enable] *ERROR* timed out waiting for >>> panel to power off >> >> Yes, it looks relevant. >> >> Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJ7iTAAoJECXpabHZMqHOX0kH/Ag+vuvrx3YKyeYHKiGwlOKR eOp8s4m9EJgdPFy2Tw5u9xQsLiQ1JBgT10kZ+PDXaqFGEPGlVROrfc/lsoUVx6u3 ArOGaG1+NO1dTHurfrysRl/k35fcnY3p8+KrYmzbia6BNWC/3DmtnHItaWn+nOs2 PFJfCBWjjljVpZa+TNRBR2H5QMGOFnOGA9kDgZQe3QJY0JGZOMTuXizWatEYWo5q 7hLZsyvEsIQNSbmofE7KO5JNekllQ/F5A9RLilXRPnJBaJm1to2BT89Nf8JgiIxm 18jk17XXkRWYmAkM+8aYrxUoR9SIK/jn3hxL4iNZRma/yWbSfcvj/dqJnMoEC0A= =Rfa3 -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 5 00:08:27 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 DE8B0B21; Thu, 5 Sep 2013 00:08:26 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <5227CAF0.5040300@FreeBSD.org> Date: Wed, 04 Sep 2013 20:06:08 -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: Bengt Ahlgren Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) References: <521D03AE.3050709@sics.se> <201309031647.47650.jhb@freebsd.org> <522669AF.5000209@FreeBSD.org> <201309040929.35903.jhb@freebsd.org> <52276554.6020807@FreeBSD.org> <522791D2.9050606@FreeBSD.org> <5227B893.1000509@FreeBSD.org> In-Reply-To: <5227B893.1000509@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kevin Oberman , freebsd-acpi , Laura Marie Feeney , Gleb Smirnoff , "Sergey A. Osokin" , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= 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: Thu, 05 Sep 2013 00:08:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-09-04 18:47:47 -0400, Jung-uk Kim wrote: > On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote: >> The value of hw.acpi.video.lcd0.brightness changes when the >> screen brightness keys (Fn+Home/End) are pressed, but nothing >> happens with the screen. Same goes for changing the value with >> sysctl. After a fresh boot it works with one issue. The screen >> brightness level seems to lag behind one keypress. Without >> acpi_video, screen brightness changes without the lag. > >> hw.acpi.video.lcd0.active is always stuck at 0 - can't change >> with sysctl (regardless if the screen is on after a fresh boot, >> or black after a text console suspend/resume): > >> [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 >> hw.acpi.video.lcd0.active: 0 -> 0 > >> Again, for my old X40 with non-KMS Xorg intel driver has >> (curiously, the screen blinks when issuing this sysctl command): > >> [bengta@P142 ~]$ sysctl hw.acpi.video hw.acpi.video.lcd0.active: >> 1 hw.acpi.video.crt0.active: 0 > > Then, KMS probably breaks acpi_video(4), too. :-( kib let me know that there is a way to make it work but it was not well-integrated to i915kms.ko. If you are interested in fixing it, dev/drm2/i915/intel_opregion.c is the source and you can download the specification from here: https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJ8rwAAoJECXpabHZMqHOz3cIAIH5qAXbfWZrWgwJWYAyL9UI z0f/LC5ufqlpgnyvFAHZO75oDebKiDq8skGWDFDhEj8vjp8JIydZSM89EK5wj0zB eCAVwquzcasduGXQZSGyN2tPUqwCm3Fuw3Bsj2Fhwgy3Y0TA9Vsz2KGTH4qCuqWU 7W97FXpLmIOpMBh/LcWCE96hY8u0HxZmzFhjMn5MlJ7z07zEc58YRpieZ3MqACCx ml3dp56RVUQhXXZzrc5Vj+Oxgmti13Xrat7YrzVmpqSRzDtOLNaoqvk4sMz1Crh4 aXq1de1+7Hc+g2oroN3mqDcb5RXknqZ7Aq7wbiOCeQwOzK7vrs3khFWq9luWG9E= =nWlO -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 5 06:30:54 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 81E8A388; Thu, 5 Sep 2013 06:30:54 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: from lmtp.galacsys.net (webmail.galacsys.net [IPv6:2001:1b78:0:1:d918:51d7:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 494642E44; Thu, 5 Sep 2013 06:30:54 +0000 (UTC) Received: from martymac.org (webmail.galacsys.net [217.24.81.215]) by lmtp.galacsys.net (Postfix) with ESMTP id 29A451FA5D4F; Thu, 5 Sep 2013 08:30:52 +0200 (CEST) From: "Ganael LAPLANCHE" To: John Baldwin ,freebsd-acpi@freebsd.org Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) X-Openwebmail-Date: Thu, 5 Sep 2013 09:30:52 +0200 Message-Id: <20130905062730.M86390@martymac.org> In-Reply-To: <201308301153.23184.jhb@freebsd.org> References: <521D03AE.3050709@sics.se> <20130830145102.GG32399@FreeBSD.org> <201308301153.23184.jhb@freebsd.org> X-Mailer: Open WebMail 2.01 20030425 X-OriginatingIP: 157.99.64.43 (ganael.laplanche@martymac.org) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Date: Thu, 5 Sep 2013 06:30:54 +0000 (UTC) Cc: Laura Marie Feeney , Gleb Smirnoff , "Sergey A. Osokin" 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: Thu, 05 Sep 2013 06:30:54 -0000 On Fri, 30 Aug 2013 11:53:22 -0400, John Baldwin wrote > I just removed VESA from my kernel on an X220 and it now suspends and > resumes great in X. I don't notice any slowdown, but I'm using a very > simple tiling window manager (i3wm). Great, I can confirm that suspend/resume also works on my X220 with this trick ! I had once opened a PR for that problem and I had managed to track the change that, at that time, broke suspend/resume : http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174504 I don't know how it relates to VESA (the change does not seem to be related to VESA), but it might help ? Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 5 06:40:03 2013 Return-Path: Delivered-To: freebsd-acpi@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 596AD735 for ; Thu, 5 Sep 2013 06:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 454D02EA0 for ; Thu, 5 Sep 2013 06:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r856e3Om088633 for ; Thu, 5 Sep 2013 06:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r856e3JH088632; Thu, 5 Sep 2013 06:40:03 GMT (envelope-from gnats) Date: Thu, 5 Sep 2013 06:40:03 GMT Message-Id: <201309050640.r856e3JH088632@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org Cc: From: "Ganael LAPLANCHE" Subject: Re: kern/174504: [ACPI] Suspend/resume broken on Lenovo x220 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Ganael LAPLANCHE List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 06:40:03 -0000 The following reply was made to PR kern/174504; it has been noted by GNATS. From: "Ganael LAPLANCHE" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/174504: [ACPI] Suspend/resume broken on Lenovo x220 Date: Thu, 5 Sep 2013 06:35:39 +0000 (UTC) Hi, Following this message : http://lists.freebsd.org/pipermail/freebsd-acpi/2013-August/008335.html I can confirm that removing the VESA option from the kernel enables suspend/resume again. I don't know how the change introduced by rev. 231797 is related to VESA, but it might give a hint. As removing VESA is only a workaround, I'll leave this PR opened for the moment. Feel free to close it if you think it can be. Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 5 08:23:05 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EDD87FC2; Thu, 5 Sep 2013 08:23:05 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7FA672A2A; Thu, 5 Sep 2013 08:23:05 +0000 (UTC) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.5/8.14.5) with ESMTP id r858N3JU046833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Sep 2013 10:23:03 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.5/8.14.5) with ESMTP id r858OwbJ003493; Thu, 5 Sep 2013 10:24:58 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.5/8.14.5/Submit) id r858OwXw003492; Thu, 5 Sep 2013 10:24:58 +0200 (CEST) (envelope-from bengta@P142.sics.se) From: Bengt Ahlgren To: "Ganael LAPLANCHE" Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) In-Reply-To: <20130905062730.M86390@martymac.org> (Ganael LAPLANCHE's message of "Thu, 5 Sep 2013 06:30:54 +0000 (UTC)") References: <521D03AE.3050709@sics.se> <20130830145102.GG32399@FreeBSD.org> <201308301153.23184.jhb@freebsd.org> <20130905062730.M86390@martymac.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) Date: Thu, 05 Sep 2013 10:24:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: Laura Marie Feeney , freebsd-acpi@freebsd.org, Gleb Smirnoff , "Sergey A. Osokin" 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: Thu, 05 Sep 2013 08:23:06 -0000 "Ganael LAPLANCHE" writes: > On Fri, 30 Aug 2013 11:53:22 -0400, John Baldwin wrote > >> I just removed VESA from my kernel on an X220 and it now suspends and >> resumes great in X. I don't notice any slowdown, but I'm using a very >> simple tiling window manager (i3wm). > > Great, I can confirm that suspend/resume also works on my X220 with this > trick ! > > I had once opened a PR for that problem and I had managed to track the > change that, at that time, broke suspend/resume : > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174504 > > I don't know how it relates to VESA (the change does not seem to be > related to VESA), but it might help ? I believe this (the PR) is a completely different issue, since you write "resume make the computer hang". The nooptions VESA fixed wedging of Intel/KMS graphics _after_ resume. There have been many other changes since r231797 (15 feb 2012). But nice that it works for you too! Bengt From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 5 18:02:17 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 0FF857CB; Thu, 5 Sep 2013 18:02:16 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <5228C69D.9070801@FreeBSD.org> Date: Thu, 05 Sep 2013 13:59:57 -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: Bengt Ahlgren Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) References: <521D03AE.3050709@sics.se> <20130830145102.GG32399@FreeBSD.org> <201308301153.23184.jhb@freebsd.org> <20130905062730.M86390@martymac.org> In-Reply-To: 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, Gleb Smirnoff , "Sergey A. Osokin" , Ganael LAPLANCHE 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: Thu, 05 Sep 2013 18:02:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-09-05 04:24:58 -0400, Bengt Ahlgren wrote: > "Ganael LAPLANCHE" writes: > >> On Fri, 30 Aug 2013 11:53:22 -0400, John Baldwin wrote >> >>> I just removed VESA from my kernel on an X220 and it now >>> suspends and resumes great in X. I don't notice any slowdown, >>> but I'm using a very simple tiling window manager (i3wm). >> >> Great, I can confirm that suspend/resume also works on my X220 >> with this trick ! >> >> I had once opened a PR for that problem and I had managed to >> track the change that, at that time, broke suspend/resume : >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174504 >> >> I don't know how it relates to VESA (the change does not seem to >> be related to VESA), but it might help ? > > I believe this (the PR) is a completely different issue, since you > write "resume make the computer hang". The nooptions VESA fixed > wedging of Intel/KMS graphics _after_ resume. There have been many > other changes since r231797 (15 feb 2012). Correct. r231797 had an issue but it was quickly fixed, I think, and it was completely unrelated to VESA. > But nice that it works for you too! Unfortunately, many people think that no video == hang because they cannot see anything on their screen/panel. Moreover, I realized that more users are now complaining about suspend/resume problems with DRM/KMS, which is not directly related to ACPI. - From lots of responses I gathered from users and developers yesterday, I can definitely say that i915kms.ko does not cooperatively work with syscons(4) and acpi_video(4). Basically, it was not a priority at the time of porting according to the author. I am quite sure radeonkms.ko has similar problems. FYI... Jung-uk Kim * PS: https://wiki.freebsd.org/SuspendResume needs more love, I guess. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSKMadAAoJECXpabHZMqHOvpMH/0RVq4KZCTDZqsxOibrIY9/9 INNEZXsVWP+Y8+BQacXP3x45eUOGVKa2IGiDo/O7Oediqh/DIhWa8pqonzJ474qY UadV+SQTjQE1EDUcjWmKnAY4OT0dHiN6eAIUv5o+dnFOxb6HupQ2hTGziReQoupS QE9YgwUVU5yOlGZXFbhq2RHvqT2Bi52dHC1qP2waVOlghNY7PIbYMTwQ4X6S4fGC Fjgjvx4tUU4EhjWuaK8mH0t/gCsUjpRico7YmYVVb2N5hu9SrojGPsIgGLaD1Aqi 4Nkmd59Asu+NBR0A22c7UAcoRpP2aJ65q/MU8CdRp/FOTE+W2LLlsXy2JIiKCBk= =Pf+z -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 5 20:03:17 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 3323FA6D; Thu, 5 Sep 2013 20:03:17 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A7A92CEE; Thu, 5 Sep 2013 20:03:16 +0000 (UTC) Received: from P142.sics.se (h139n3-u-d1.ias.bredband.telia.com [90.228.197.139]) by sink.sics.se (8.14.5/8.14.5) with ESMTP id r85K353q048517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Sep 2013 22:03:05 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.5/8.14.5) with ESMTP id r85K4urw005904; Thu, 5 Sep 2013 22:04:56 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.5/8.14.5/Submit) id r85K4u7i005903; Thu, 5 Sep 2013 22:04:56 +0200 (CEST) (envelope-from bengta@P142.sics.se) From: Bengt Ahlgren To: Jung-uk Kim Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) In-Reply-To: <5227CAF0.5040300@FreeBSD.org> (Jung-uk Kim's message of "Wed, 04 Sep 2013 20:06:08 -0400") References: <521D03AE.3050709@sics.se> <201309031647.47650.jhb@freebsd.org> <522669AF.5000209@FreeBSD.org> <201309040929.35903.jhb@freebsd.org> <52276554.6020807@FreeBSD.org> <522791D2.9050606@FreeBSD.org> <5227B893.1000509@FreeBSD.org> <5227CAF0.5040300@FreeBSD.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) Date: Thu, 05 Sep 2013 22:04:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: Kevin Oberman , freebsd-acpi , Laura Marie Feeney , Gleb Smirnoff , "Sergey A. Osokin" , =?iso-8859-1?Q?Jean-S=E9bastien_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: Thu, 05 Sep 2013 20:03:17 -0000 Jung-uk Kim writes: > On 2013-09-04 18:47:47 -0400, Jung-uk Kim wrote: >> On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote: >>> The value of hw.acpi.video.lcd0.brightness changes when the >>> screen brightness keys (Fn+Home/End) are pressed, but nothing >>> happens with the screen. Same goes for changing the value with >>> sysctl. After a fresh boot it works with one issue. The screen >>> brightness level seems to lag behind one keypress. Without >>> acpi_video, screen brightness changes without the lag. >> >>> hw.acpi.video.lcd0.active is always stuck at 0 - can't change >>> with sysctl (regardless if the screen is on after a fresh boot, >>> or black after a text console suspend/resume): >> >>> [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 >>> hw.acpi.video.lcd0.active: 0 -> 0 >> >>> Again, for my old X40 with non-KMS Xorg intel driver has >>> (curiously, the screen blinks when issuing this sysctl command): >> >>> [bengta@P142 ~]$ sysctl hw.acpi.video hw.acpi.video.lcd0.active: >>> 1 hw.acpi.video.crt0.active: 0 >> >> Then, KMS probably breaks acpi_video(4), too. :-( > > kib let me know that there is a way to make it work but it was not > well-integrated to i915kms.ko. If you are interested in fixing it, > dev/drm2/i915/intel_opregion.c is the source and you can download the > specification from here: > > https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf Hmm, scanning that spec, I wonder whether the opregion functionality is better placed together with acpi_video, and then i915kms makes calls to that instead? Hmm, again, perhaps the intel platform needs opregion support to work properly also without the kms driver. Could be an explanation for the backlight issues. (Just speculation so far... I have no idea if/how this relates to or interacts with options VESA) Bengt From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 5 20:34:43 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 8D2728A0; Thu, 5 Sep 2013 20:34:42 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <5228EA57.5000005@FreeBSD.org> Date: Thu, 05 Sep 2013 16:32:23 -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: Bengt Ahlgren Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) References: <521D03AE.3050709@sics.se> <201309031647.47650.jhb@freebsd.org> <522669AF.5000209@FreeBSD.org> <201309040929.35903.jhb@freebsd.org> <52276554.6020807@FreeBSD.org> <522791D2.9050606@FreeBSD.org> <5227B893.1000509@FreeBSD.org> <5227CAF0.5040300@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kevin Oberman , freebsd-acpi , Laura Marie Feeney , Gleb Smirnoff , "Sergey A. Osokin" , =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= 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: Thu, 05 Sep 2013 20:34:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-09-05 16:04:56 -0400, Bengt Ahlgren wrote: > Jung-uk Kim writes: > >> On 2013-09-04 18:47:47 -0400, Jung-uk Kim wrote: >>> On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote: >>>> The value of hw.acpi.video.lcd0.brightness changes when the >>>> screen brightness keys (Fn+Home/End) are pressed, but >>>> nothing happens with the screen. Same goes for changing the >>>> value with sysctl. After a fresh boot it works with one >>>> issue. The screen brightness level seems to lag behind one >>>> keypress. Without acpi_video, screen brightness changes >>>> without the lag. >>> >>>> hw.acpi.video.lcd0.active is always stuck at 0 - can't >>>> change with sysctl (regardless if the screen is on after a >>>> fresh boot, or black after a text console suspend/resume): >>> >>>> [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 >>>> hw.acpi.video.lcd0.active: 0 -> 0 >>> >>>> Again, for my old X40 with non-KMS Xorg intel driver has >>>> (curiously, the screen blinks when issuing this sysctl >>>> command): >>> >>>> [bengta@P142 ~]$ sysctl hw.acpi.video >>>> hw.acpi.video.lcd0.active: 1 hw.acpi.video.crt0.active: 0 >>> >>> Then, KMS probably breaks acpi_video(4), too. :-( >> >> kib let me know that there is a way to make it work but it was >> not well-integrated to i915kms.ko. If you are interested in >> fixing it, dev/drm2/i915/intel_opregion.c is the source and you >> can download the specification from here: >> >> https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf > >> > Hmm, scanning that spec, I wonder whether the opregion > functionality is better placed together with acpi_video, and then > i915kms makes calls to that instead? Traditionally, platform-specific code goes to dev/acpi_support. So, dev/acpi_support/acpi_intel.c may be created to cater its needs, if it is absolutely necessary. > Hmm, again, perhaps the intel platform needs opregion support to > work properly also without the kms driver. Could be anexplanation > for the backlight issues. Yes and yes, I think. However, many developers are tired of dealing with syscons ugliness and now the Foundation is sponsoring ray@ to replace syscons with newcons+KMS if my understanding is correct. I am not sure how it will be layered at the end, though. > (Just speculation so far... I have no idea if/how this relates to > or interacts with options VESA) Apparently, they interact badly. :-( Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSKOpXAAoJECXpabHZMqHOSnIIANS/Kt043RI7fFLNYVeWvpH0 zQ8C3wTi66aIW9B5bvYcXcJXcE1yazfegbtAHT6i0Hf4/BrvoMkN3umHIRYMbMv9 ei7WoFDLRIuyGzqgMy7CP3t9byYZolRBuyIt+zELsNU/5zCkgSP3di40TK+oLJ+3 NXhALsLZA37B1S3TYaiLy+U4BylfC3iNhFDlDRrikuYvAym/s5o/Ro0Ea8dyUw4i CtWDEomCIwjzOuythAl1wlXYeMtZZp+6Fj2Pemhh9COzFXgHiTfhfVySRVt0tBAs 6FKmQnc30ra2clU1o5JJuzwlOsgGH+aztvrdjc4VGr/wGpdmKW6FrNlpcku1VkQ= =i0JD -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 6 00:24:49 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 5EB191B8; Fri, 6 Sep 2013 00:24:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5A05C29FA; Fri, 6 Sep 2013 00:24:48 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id f12so2285332wgh.26 for ; Thu, 05 Sep 2013 17:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VUz4d8ArHjwQOVoxN0NmNauovwVhOCsb+qv2AoSPskA=; b=KBsIwyCE2ZBNV4IL+A3V316oWQUN5/akTIHfZ64J2HOf0q7MZsBlrNBccoYM0AtqZp ZQ2cAy+op1IF6qewQLlqYCGyE8sMwPkUjr6dCw/yC5R7+0efJx1os9itPDUbfNQwodNH ox4m25wCnfYPLLdjJbEMFI9wC0QRafdg7ng5Jkv+xnyCAMOtr1eEjj5zUQg51/CugKaV Y9WNLEG7Z6MItnPNbL7xtogRwIoyEdRQFSIKCDubYFrGSXvcDZGH/hsVzWtQY32ZDUgB 2CLkJw+04z0TPMWMQfB5xOu21wGNJJySq7vYbjYUKDnnWXPzqm7PeF87NkGwZV2Bjmk3 k2Ig== MIME-Version: 1.0 X-Received: by 10.194.122.99 with SMTP id lr3mr8741480wjb.21.1378427086738; Thu, 05 Sep 2013 17:24:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.133 with HTTP; Thu, 5 Sep 2013 17:24:46 -0700 (PDT) In-Reply-To: <5228EA57.5000005@FreeBSD.org> References: <521D03AE.3050709@sics.se> <201309031647.47650.jhb@freebsd.org> <522669AF.5000209@FreeBSD.org> <201309040929.35903.jhb@freebsd.org> <52276554.6020807@FreeBSD.org> <522791D2.9050606@FreeBSD.org> <5227B893.1000509@FreeBSD.org> <5227CAF0.5040300@FreeBSD.org> <5228EA57.5000005@FreeBSD.org> Date: Thu, 5 Sep 2013 17:24:46 -0700 X-Google-Sender-Auth: ozLMTGzTiNGwaGX2Hk9wBBWIDvM Message-ID: Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) From: Adrian Chadd To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Laura Marie Feeney , freebsd-acpi , Kevin Oberman , Gleb Smirnoff , "Sergey A. Osokin" , =?ISO-8859-1?Q?Jean=2DS=E9bastien_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: Fri, 06 Sep 2013 00:24:49 -0000 Whoa whoa. I'm confused. Well, a bit. How is it up to syscons to fix the backlight configuration, which seems to be a large part of the problem here? Or what else is going on here with restoring the system state? I'm worried that we'll have the same problem with newcons, with or without KMS. Why would KMS get involved if I'm in console mode doing 80x60 text? :) -adrian From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 6 01:13: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 19B2B8B4; Fri, 6 Sep 2013 01:13:32 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <52292BAF.6060508@FreeBSD.org> Date: Thu, 05 Sep 2013 21:11:11 -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: Adrian Chadd Subject: Re: suspend/resume on Lenovo X1 (regression from reports on wiki) References: <521D03AE.3050709@sics.se> <201309031647.47650.jhb@freebsd.org> <522669AF.5000209@FreeBSD.org> <201309040929.35903.jhb@freebsd.org> <52276554.6020807@FreeBSD.org> <522791D2.9050606@FreeBSD.org> <5227B893.1000509@FreeBSD.org> <5227CAF0.5040300@FreeBSD.org> <5228EA57.5000005@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Laura Marie Feeney , freebsd-acpi , 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: Fri, 06 Sep 2013 01:13:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-09-05 20:24:46 -0400, Adrian Chadd wrote: > Whoa whoa. > > I'm confused. Well, a bit. How is it up to syscons to fix the > backlight configuration, which seems to be a large part of the > problem here? No, it has nothing to do with syscons(4). acpi_video(4) does. However, it does not work with i915kms.ko because some piece of code is not implemented for FreeBSD if I understand it correctly. > Or what else is going on here with restoring the system state? It worked with DRM1 because automatic VT-switching (aka sysctl hw.syscons.sc_no_suspend_vtswitch) indirectly saves/restores GPU states via X11 driver, which is no longer possible with KMS. > I'm worried that we'll have the same problem with newcons, with or > without KMS. Why would KMS get involved if I'm in console mode > doing 80x60 text? :) If KMS is used for newcons backend, I am sure text mode won't be implemented. Also, KMS will "naturally" handle suspend/resume as it is a proper newbus driver, unlike syscons. At least, that's the idea. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSKSuvAAoJECXpabHZMqHOA6kIAMLLYNSniDonBSs5QzLvT6aM iISSshjhyykNPCTwZBS5d5LCMAJXuQ7OF7FIYYI7bgrKFX0hzNCAARDJE52/PgQA S1D4ra0slsKm62ezdiOuJhP4C/Hwqihv8/jMK9KmbBSNAyydZ+pPVXHd/JKaCd/U J+g72slzyAm/GYOe8kRb7JGUQsiDyDUbVOOoZZlarqxSEl0kvZFE7rIWBxuD0DGN iGkVB3e0ybIlVNPvjh2CsukBnD2TUYR1ssXFn7zp1Mh9qnQIfoTnQoSDkjDVV1b6 wi2Y1L3cu1kgfG0dCx6CNuH/K3/g0SXA55D8o+NrmLPAQYHWy/TGVm3eKQe30fg= =CY1F -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 6 22:01:29 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2E281743; Fri, 6 Sep 2013 22:01:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6BCB42C9D; Fri, 6 Sep 2013 22:01:28 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id cb5so1470346wib.4 for ; Fri, 06 Sep 2013 15:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YMBMIO4rJrd6+3GOvCf4rLa9RcreZoEwc2C/aDkK3DI=; b=x7hHfAc5woRJIptkFl6OoU9bEWHuvMP53Qh8ZY3+BZV0pDhxafPQQPNyVxGlH+UeaZ T8YPA1Ycy/oAs4UZDn+zl7O7DMFkxNxrRi5s4X9r4oLbtfj9+/KpbMAW3045NR4YBWif 1/p9kI5YR5Z79L9jTNwr+BkT8LBiPROsyJwUAJesYUxQVc2ZTCOpL6nyrz+nmAG2oVY3 0qyw01ANDOO3/d3SiNV0nS5ES4Hhfl25yzNT4KbVhq7z4BOlhjidOorlrnnjPPBFCgOY Zt3OIUcWKFyt9xA9xQLYfxD19uQRMntr+JHZY44JMa9cr7ZRcMWh9VzTWW+gGXKJjq6B JTkw== MIME-Version: 1.0 X-Received: by 10.180.79.131 with SMTP id j3mr90639wix.0.1378504886872; Fri, 06 Sep 2013 15:01:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.133 with HTTP; Fri, 6 Sep 2013 15:01:26 -0700 (PDT) In-Reply-To: References: <5222E19C.9040402@FreeBSD.org> <5223B313.9060708@FreeBSD.org> <5223B9C3.2070508@FreeBSD.org> <522418F4.9030007@FreeBSD.org> Date: Fri, 6 Sep 2013 15:01:26 -0700 X-Google-Sender-Auth: oaMIqjsuWpUFfu_kIpgt-iqCzY4 Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Adrian Chadd To: Mike Harding Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List , Andriy Gapon 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: Fri, 06 Sep 2013 22:01:29 -0000 .. anything happening? -adrian On 2 September 2013 07:29, Adrian Chadd wrote: > > On 2 September 2013 07:25, Mike Harding wrote: > >> It's detailed in the ticket, see >> http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for >> 'reverted'. >> >> > Ok. You and avg@ are digging into it deeper, so I'll leave it be for now. > I'll retest this on my test laptops when I'm back home. > > > > -adrian > >