Message-ID: <1513001367.2981.11.camel@intel.com>
Subject: Re: Linux 4.15-rc2: Regression in resume from ACPI S3
From: Zhang Rui <rui.zhang@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
        Pavel Machek <pavel@ucw.cz>
Cc: Andrew Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Jarkko Nikula <jarkko.nikula@linux.intel.com>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>
Date: Mon, 11 Dec 2017 22:09:27 +0800
In-Reply-To: <CA+55aFy2-vNAXSnSBoiSfvhijKXzYVmpYr1VCOb87+tgrw0B1Q@mail.gmail.com>
References: <CA+55aFxPBszFBt91KRNBrsQdJ10b+6fh9ySNzSKSX7JOq4WRPw@mail.gmail.com>
         <alpine.DEB.2.20.1712042338280.2198@nanos>
         <2809506.pL8kVbvXcY@aspire.rjw.lan> <1578405.51lzoSX1jh@aspire.rjw.lan>
         <20171209103325.GA13867@amd>
         <CA+55aFw8tuoJ2gcXx3K2sKFf2Y9hXX4naMVQNqGOUivnjwhjkg@mail.gmail.com>
         <20171209220110.GA11496@amd>
         <CA+55aFySAdiBZhZ0PSDjH5PuvPPcMsBRXbxCkObfm1eY7gHDbQ@mail.gmail.com>
         <20171210162305.GA10159@amd>
         <CA+55aFxc9e=CuwrAzhX7BgV4Or+unTQDXW1Xk-gXOZPiAtN3Bw@mail.gmail.com>
         <20171210185638.GA10363@amd>
         <CA+55aFy2-vNAXSnSBoiSfvhijKXzYVmpYr1VCOb87+tgrw0B1Q@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1961
Lines: 58

On Sun, 2017-12-10 at 12:30 -0800, Linus Torvalds wrote:
> On Sun, Dec 10, 2017 at 10:56 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > 
> > 
> > Confirmed, revert fixes it. You see how it moves
> > fix_processor_context
> > around #ifdef CONFIG_X86_32 block? And how people forget 32-bit
> > machines exist? Aha.
> Yeah, people do.
> 
> Andy?
> 
> > 
> > Which brings me to .. various people do automated testing of
> > kernel. Testing 32-bit kernel for boot, and both 32-bit and 64-bit
> > for
> > boot and suspend would be very nice. The last item is not hard,
> > either:
> > 
> > sudo rtcwake -l -m mem -s 5
> > 
> > ...should take 10 seconds or so.
> I'm told 0day does *some* suspend/resume testing, but I think it's
> pretty limited, partly because the kinds of machines it primarily
> works on don't really support suspend/resume at all.

currently, we're running suspend test on 1 platform only, with 64 bit
kernel. suspend test will be enabled on more platforms (laptops) in
next two weeks.

I will check why it does not find the first regression introduced by
ca37e57bbe0c ("x86/entry/64: Add missing irqflags tracing to
native_load_gs_index()").

>  I'm also not sure
> just how many of those machines are 32-bit at all..

for this, I suppose it can be reproduced if we use 32-bit kernel and
rootfs, right? Then it's easier to enable this in 0Day.

thanks,
rui
> 
> But I'm adding Zhang Rui to the cc, to see if my recollection is
> right.
> 
> Because you're right, more suspend/resume automated testing would be
> good to have. And yes, people test mainly 64-bit these days.
> 
> Also, I'm not even sure what the 0day rules are for just plain
> mainline. I don't tend to see a lot of breakage reports, even though
> I'd expect to. This came in from the x86 trees (and those do their
> own
> tests too, but probably not suspend/resume either), but it hit my
> tree
> fairly soon after going into the x86 -tip trees.
> 
>             Linus