Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752646AbdLKQ2v (ORCPT ); Mon, 11 Dec 2017 11:28:51 -0500 Received: from mail.kernel.org ([198.145.29.99]:60284 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752452AbdLKQ2u (ORCPT ); Mon, 11 Dec 2017 11:28:50 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B88BD21910 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org X-Google-Smtp-Source: ACJfBovp/+FfohBub1KEYbmDBfzm10DM+eWxYTZ9DTAbFzyFLoxSTyB3gzRjCpwBS2rtXKDy8x8WLLuPM1P+geDYmHE= MIME-Version: 1.0 In-Reply-To: <1513001367.2981.11.camel@intel.com> References: <2809506.pL8kVbvXcY@aspire.rjw.lan> <1578405.51lzoSX1jh@aspire.rjw.lan> <20171209103325.GA13867@amd> <20171209220110.GA11496@amd> <20171210162305.GA10159@amd> <20171210185638.GA10363@amd> <1513001367.2981.11.camel@intel.com> From: Andy Lutomirski Date: Mon, 11 Dec 2017 08:28:28 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Linux 4.15-rc2: Regression in resume from ACPI S3 To: Zhang Rui Cc: Linus Torvalds , Pavel Machek , Andrew Lutomirski , Thomas Gleixner , Jarkko Nikula , "Rafael J. Wysocki" , Linux Kernel Mailing List , "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2328 Lines: 68 On Mon, Dec 11, 2017 at 6:09 AM, Zhang Rui wrote: > On Sun, 2017-12-10 at 12:30 -0800, Linus Torvalds wrote: >> On Sun, Dec 10, 2017 at 10:56 AM, Pavel Machek 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. > Yes. The 64-bit problem should also be reproducible with rtcwake even in a vm. Also, on this topic, could make run_tests in tools/testing/selftests/x86 be added to the rotation as well? The testing dir should match the kernel being tested IMO. > 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