Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752320AbdLJVfV (ORCPT ); Sun, 10 Dec 2017 16:35:21 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:53706 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751628AbdLJVfT (ORCPT ); Sun, 10 Dec 2017 16:35:19 -0500 Date: Sun, 10 Dec 2017 22:35:18 +0100 From: Pavel Machek To: Linus Torvalds Cc: Zhang Rui , Andrew Lutomirski , Thomas Gleixner , Jarkko Nikula , "Rafael J. Wysocki" , Linux Kernel Mailing List , the arch/x86 maintainers Subject: Re: Linux 4.15-rc2: Regression in resume from ACPI S3 Message-ID: <20171210213516.GA5096@amd> References: <20171209103325.GA13867@amd> <20171209220110.GA11496@amd> <20171210162305.GA10159@amd> <20171210185638.GA10363@amd> <20171210204350.GA25013@amd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2192 Lines: 67 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun 2017-12-10 13:28:50, Linus Torvalds wrote: > On Sun, Dec 10, 2017 at 12:43 PM, Pavel Machek wrote: > > > > For the record... this should fix it. Tested on x60. More tests pending. >=20 > This can't be right. >=20 > At the very least, now the comment is wrong. And the comment does seem > relevant for 32-bit too: Well, take a look at orignal patch. I'm reverting 32-bit code to v4.15-rc1 version, while keeping 64-bit code at v4.15-rc3 version. Yes, my brain hurts from looking at the code :-(. In the meantime, I did short test on 64-bit machine. No ill effect observed. Hmm. Aha. Yes, the comment is wrong... as it was in wrong in -rc1. > > - fix_processor_context(); > > - > > /* > > * Restore segment registers. This happens after restoring the= GDT > > * and LDT, which happen in fix_processor_context(). >=20 > Notice? You've moved down the 32-bit fix_processor_context() call to > after the loadsegment() calls, which smells wrong. Yeah, I did. There's where it was in v4.15-rc1, and that's what ws working for me.=20 > That said, this *all* smells wrong. Why is there a special > fix_processor_context() function at all with different 32-bit and > 64-bit behavior? This code is all written to be maximally confusing. >=20 > I think this could do with some re-org to make it more logical. That > "some random things done in fix_processor_context(), other random > things done directly in __restore_processor_state()" makes no sense at > all to me. There's no logic to what is done where. I have to agree. Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --wac7ysb48OaltWcw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlotqJMACgkQMOfwapXb+vJpNgCfZ3iYjP27gmtV93sTrKeCYMqJ 1jkAn1u8AKff6kXPi5aMg3K7YW30wxuR =TGLo -----END PGP SIGNATURE----- --wac7ysb48OaltWcw--