From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751691AbcFXNkQ (ORCPT ); Fri, 24 Jun 2016 09:40:16 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:42627 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751398AbcFXNkO (ORCPT ); Fri, 24 Jun 2016 09:40:14 -0400 Subject: Re: Crashes in -next due to 'mm, page_alloc: remove fair zone allocation policy' To: Mel Gorman References: <20160624060533.GA9507@roeck-us.net> <20160624083914.GD1868@techsingularity.net> Cc: Andrew Morton , linux-kernel@vger.kernel.org, Vlastimil Babka From: Guenter Roeck Message-ID: <576D3833.7020608@roeck-us.net> Date: Fri, 24 Jun 2016 06:40:03 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160624083914.GD1868@techsingularity.net> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mel, On 06/24/2016 01:39 AM, Mel Gorman wrote: > On Thu, Jun 23, 2016 at 11:05:33PM -0700, Guenter Roeck wrote: >> Hi, >> >> I see a lot of crashes with various architectures in next-20160623. >> I bisected mips and sh; both bisect log point to the same patch. >> Bisect log is attached. arm, ppc, and x86 images crash as well, >> but I did not confirm if the same patch is the culprit there. >> > > The series has been dropped. Due to conflicts with other patches, there > were a few bugs introduced, one which potentially corrupted memory. Just > to be sure though, what sort of workload crashed just in case I need to > adjust the test coverage? > This is just a basic qemu boot test. No workload at all. Here is a complete list of failures. Qemu test results: total: 107 pass: 66 fail: 41 Failed tests: arm:versatilepb-scsi:versatile_defconfig:versatile-pb arm:versatileab:versatile_defconfig:versatile-ab arm:versatilepb:versatile_defconfig:versatile-pb arm:imx25-pdk:imx_v4_v5_defconfig:imx25-pdk arm:midway:multi_v7_defconfig:ecx-2000 arm:realview-pb-a8:realview_defconfig arm:akita:spitz_defconfig arm:spitz:spitz_defconfig arm:akita:pxa_defconfig arm:borzoi:pxa_defconfig arm:mainstone:pxa_defconfig arm:spitz:pxa_defconfig arm:terrier:pxa_defconfig arm:tosa:pxa_defconfig arm:z2:pxa_defconfig arm:collie:collie_defconfig arm:integratorcp:integrator_defconfig:integratorcp mips:malta_defconfig:nosmp mips64:malta_defconfig:nosmp mipsel64:fuloong2e_defconfig:fulong2e powerpc:mac99:nosmp:ppc_book3s_defconfig powerpc:g3beige:nosmp:ppc_book3s_defconfig powerpc:virtex-ml507:44x/virtex5_defconfig powerpc:mpc8548cds:85xx/mpc85xx_cds_defconfig powerpc:bamboo:44x/bamboo_defconfig powerpc:nosmp:ppc64_book3s_defconfig sh:rts7751r2dplus_defconfig x86:core2duo:q35:x86_pc_nosmp_defconfig x86:Conroe:isapc:x86_pc_nosmp_defconfig x86:Opteron_G1:pc:x86_pc_nosmp_defconfig x86:n270:isapc:x86_pc_nosmp_defconfig x86_64:SandyBridge:q35:x86_64_pc_defconfig x86_64:Haswell:q35:x86_64_pc_defconfig x86_64:core2duo:pc:x86_64_pc_defconfig x86_64:Nehalem:q35:x86_64_pc_defconfig x86_64:phenom:pc:x86_64_pc_defconfig x86_64:Opteron_G1:q35:x86_64_pc_defconfig x86_64:Opteron_G4:pc:x86_64_pc_nosmp_defconfig x86_64:IvyBridge:q35:x86_64_pc_nosmp_defconfig xtensa:dc233c:ml605:generic_kc705_defconfig xtensa:dc233c:kc705:generic_kc705_defconfig For logs, please see the next column of the qemu test results at http://kerneltests.org/builders. You might have to dive into individual builds if you check after a more recent -next kernel has been made available and your changes were dropped in that kernel. Test results are available for about a month. Build and test scripts are available at https://github.com/groeck/linux-build-test. Hope this helps, Guenter