From owner-freebsd-stable@freebsd.org Thu Jul 30 02:04:21 2015 Return-Path: Delivered-To: freebsd-stable@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 C5B319A71FD for ; Thu, 30 Jul 2015 02:04:21 +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 A17F161E for ; Thu, 30 Jul 2015 02:04:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AF571B97B; Wed, 29 Jul 2015 22:04:20 -0400 (EDT) From: John Baldwin To: Kevin Oberman Cc: Joseph Mingrone , "Brandon J. Wandersee" , Adrian Chadd , FreeBSD-STABLE Mailing List Subject: Re: suspend/resume regression Date: Wed, 29 Jul 2015 18:25:57 -0700 Message-ID: <2584513.nR3WcOyoao@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <86oak289hv.fsf@gly.ftfl.ca> 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); Wed, 29 Jul 2015 22:04:20 -0400 (EDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 02:04:21 -0000 On Saturday, July 25, 2015 03:54:40 PM Kevin Oberman wrote: > John, > > I'm concerned that two issues may be getting conflated. > > The issue I thought we were looking at was the failure of some systems > (T520, X220, T430) to resume after a number of PCI enhancements were MFCed. > This is completely unrelated to the USB issue I was experiencing when > trying to test the problem on HEAD. The more I think about it, the more I > think that the USB "issue" is just how things need to work. Well, the USB thing could be smarter, but it's a bit of a PITA. What if you take the USB stick out, mess with it on another system, then plug it back in before resume? All the cached file data in the RAM of the resumed system would need to be invalidated, etc. However, I ended up copying a HEAD kernel onto my USB stick and seeing that I at least got the console back before it panic'd. This was sufficient to let me test the reversion patch via the USB stick (and would be sufficient for seeing if we can merge it again for 10.3). > The real issue is just resuming the system after r281874 was MFCed as a > part of 284034. No USB connected file systems are involved. I m happy to > see that it has been reverted for 10.2, but clearly, these changes are > needed down the line and I hope the issue can be resolved well before 11.0. > (This assumes a 10.3 before 11.0 happens next year.) So it works fine in 11.0 on my x220, and as other folks reported in the PR, so 11.0 is fine. It is also needed for PCI-e hotplug to work after resume (using out-of-tree patches for PCI-e hotplug that jmg@ has). If I merge it to 10.3 it won't be until I've verified that whatever I merge works on my x220 as well as the T440. -- John Baldwin