Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751328AbdCYL1K (ORCPT ); Sat, 25 Mar 2017 07:27:10 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:58491 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750766AbdCYL1I (ORCPT ); Sat, 25 Mar 2017 07:27:08 -0400 Date: Sat, 25 Mar 2017 12:27:06 +0100 From: Alexandre Belloni To: Guenter Roeck Cc: Kevin Hilman , "kernelci.org bot" , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org, shuahkh@osg.samsung.com, patches@kernelci.org, ben.hutchings@codethink.co.uk, stable@vger.kernel.org, nicolas.ferre@atmel.com, Ludovic Desroches , Richard Genoud Subject: Re: [PATCH 4.4 00/30] 4.4.57-stable review Message-ID: <20170325112705.s2uusw7fz5gz7r3m@piout.net> References: <20170324151220.759111698@linuxfoundation.org> <58d5acb7.5ed7190a.6dd61.3845@mx.google.com> <02dd0335-8f4e-a01d-824d-98d08c3d0413@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02dd0335-8f4e-a01d-824d-98d08c3d0413@roeck-us.net> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3161 Lines: 79 On 24/03/2017 at 21:15:28 -0700, Guenter Roeck wrote: > On 03/24/2017 05:10 PM, Kevin Hilman wrote: > > + at91 maintainers > > + Richard, Ludovic > > kernelci.org bot writes: > > > > > stable-rc boot: 496 boots: 1 failed, 492 passed with 2 offline, 1 conflict (v4.4.56-31-gbcd1e808ead3) > > > > > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.4.56-31-gbcd1e808ead3/ > > > Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.4.56-31-gbcd1e808ead3/ > > > > > > Tree: stable-rc > > > Branch: local/linux-4.4.y > > > Git Describe: v4.4.56-31-gbcd1e808ead3 > > > Git Commit: bcd1e808ead359a9af8476025d8b8a5349796dcd > > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > > Tested: 97 unique boards, 23 SoC families, 31 builds out of 202 > > > > > > Boot Regressions Detected: > > > > > > arm: > > > > > > multi_v7_defconfig+CONFIG_LKDTM=y: > > > at91-sama5d2_xplained: > > > lab-free-electrons: new failure (last pass: v4.4.51-27-g2ffd736763bc) > > > > This one is definitely a new regression. Hopefully the AT91 maintainers > > (now Cc'd) can have a closer look. > > > > 6b1d7b6f54c7 would be a candidate for a culprit. > Possibly and it may exercise a part of the logic that is not quite robust in atmel_set_ops(). Basically, atmel_rx_from_pdc() must not be chosen on sama5d2 (it has no PDC). For reference, bootlog here: https://storage.kernelci.org/stable-rc/v4.4.56-31-gbcd1e808ead3/arm-multi_v7_defconfig+CONFIG_LKDTM=y/lab-free-electrons/boot-at91-sama5d2_xplained.html > > > Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) > > > > > > arm: > > > > > > multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: > > > at91-sama5d3_xplained: > > > lab-baylibre-seattle: PASS > > > lab-free-electrons: FAIL > > > > @Alexandre: Because it's passing in my lab and failing in yours, I'm > > guessing this is still the UART overflow issue we've discussed before? > > > > What's strange is that this defconfig in your lab seems to only be > > booting for stable/linux-4.4.y[1] but not mailine or newer stable trees, > > so I couldn't check if the problem still exists in mainline. > > It definitively exists but it is not solvable quickly. Either we run without DMA and we'll see the issue because CONFIG_PROVE_LOCKING makes the interrupt handling to slow and characters are dropped. Or, we add DMA and then CONFIG_PROVE_LOCKING will find a deadlock (that's a real deadlock, not a false positive) and the platform will not boot. This only affects sama5d3 because it is the only SoC using the hdma controller with the uart IP. Earlier SoCs have a PDC and later SoCs are using the xdma controller. This happens because atc_chain_complete() keeps the lock before calling the callback. And atmel_complete_tx_dma() will call dmaengine function that will try to acquire the lock. No issue using the xdmac because there is no lock. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com