From owner-freebsd-mobile@freebsd.org Thu Feb 18 14:55:35 2016 Return-Path: Delivered-To: freebsd-mobile@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE67AAADCED; Thu, 18 Feb 2016 14:55:35 +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 DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88F9B95F; Thu, 18 Feb 2016 14:55:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 93073B94E; Thu, 18 Feb 2016 09:55:34 -0500 (EST) From: John Baldwin To: Alexey Dokuchaev Cc: Kevin Oberman , Adrian Chadd , "current@freebsd.org" , Stefan Ehmann , "freebsd-mobile@freebsd.org" Subject: Re: Thinkpad T410: resume broken Date: Thu, 18 Feb 2016 06:50:34 -0800 Message-ID: <2846385.IUIOUlEDYf@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160218141338.GA15706@regency.nsu.ru> References: <53762216.8020205@gmx.net> <537753F3.6000202@FreeBSD.org> <20160218141338.GA15706@regency.nsu.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Feb 2016 09:55:34 -0500 (EST) X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 14:55:35 -0000 On Thursday, February 18, 2016 08:13:38 PM Alexey Dokuchaev wrote: > On Sat, May 17, 2014 at 08:20:03AM -0400, John Baldwin wrote: > > VESA needs to be removed for i915kms, but I've no idea if it needs to be > > removed for Nvidia. The video reset code was reworked in 10 so that > > having VESA is supposed to be like using 'hw.acpi.reset_video=1' on 9, > > but in theory it works more often. > > This (VESA needs to be removed for i915kms) is news to me: I don't see it > mentioned in UPDATING, and "options VESA" presents in -CURRENT's (post-KMS > era) GENERIC kernel config. So what's the real deal here? :-) This is an old mail you are responding to. You no longer need to remove VESA for kms. > If "having VESA is supposed to be like using 'hw.acpi.reset_video=1' on > 9", it should not hurt (I recall having to hw.acpi.reset_video=1 in early > stable/[67] days, but no longer for quite a long time with stable/8). > > Admittedly, the whole situation with i915kms, vesa.ko, et al. looks quite > confusing, while suspend/resume works *worse* than with stable/8 and pre- > KMS. Table of known laptops on wiki page [1] is hardly helpful unless it > has your laptop of interest; IMHO it would benefit a lot more from listing > common symptoms and mitigation/fixes for them (including VESA, sysctl vars, > kernel options, etc). The value of "worse" depends on your laptop. I have an older i386 HP netbook for which resume works fine using sc(4) and the older DRM drivers because the video BIOS turns the LCD back on during resume without requiring the OS to do so. However, the recent GPU chipsets from Intel do not do that and the only bit of code in the tree that knows how to turn the LCD panel back on is the KMS driver. However, note that KMS is not related to NVidia GPUs. If your laptop is using one of those then the nvidia driver is what has to turn the LCD panel back on. > > ACPI_PM setting to the kernel module along with removing VESA would seem > > like your best bet, but I see in follow-ups that that wasn't completely > > reliable. However, you can try using ACPI_PM with syscons, no need to > > use vt. > > What are indications for use of ACPI_PM option? As for removing VESA, > I've found that my laptop resumes more willingly with i915kms.ko *and* > vesa.ko than without vesa.ko (could only? be loaded from loader.conf): > with both modules loaded it takes only three presses of power button to > get back from suspend, while without vesa.ko it's a lottery, and often > power-cycling is required to get things back to working -- any ideas on > why would that be? vesa.ko shouldn't be working with KMS. KMS turns off the legacy VGA emulation in the hardware when it starts which prevents VESA from working (VESA requires the legacy VGA interface). I never have to hit the power button more than once to resume on a laptop where resume works though. (True on my X220 and on a T440 both with Intel or Radeon graphics (all using KMS). > Needless to say, suspend/resume worked nearly flawlessly under stable/8 > and stable/7 FWIW. If it worked here, then this means you could try using sc(4) + the old drm (not drm2). This means your laptop is old enough to still turn the LCD panel back on in its BIOS during resume like my HP netbook. However, I don't know for how much longer Xorg will support the older drm (if it even does now). FWIW, the HP netbook resumes fine with KMS as well for me. One caveat though is that if you are using vt(4) and haven't yet loaded KMS it won't resume (due to vt(4) not having the equivalent of VESA). With sc(4) the netbook was always able to resume. -- John Baldwin