From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757955AbcGZSVK (ORCPT ); Tue, 26 Jul 2016 14:21:10 -0400 Received: from hqemgate15.nvidia.com ([216.228.121.64]:6214 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757886AbcGZSUU (ORCPT ); Tue, 26 Jul 2016 14:20:20 -0400 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Tue, 26 Jul 2016 11:17:43 -0700 Subject: Re: [patch 61/66] timers: Convert to hotplug state machine To: Thomas Gleixner References: <20160711122450.923603742@linutronix.de> <20160711122535.775201614@linutronix.de> <7d37714e-b072-ee90-f14f-364f4fd01f0d@nvidia.com> <20160725153543.GB10939@linutronix.de> <0b5a7bb5-6670-606b-e33d-63cd8b0fcedd@nvidia.com> CC: , Anna-Maria Gleixner , LKML , Peter Zijlstra , Ingo Molnar , Sebastian Andrzej Siewior , "linux-tegra@vger.kernel.org" From: Jon Hunter Message-ID: Date: Tue, 26 Jul 2016 19:20:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.26.11.53] X-ClientProxiedBy: UKMAIL101.nvidia.com (10.26.138.13) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thomas, On 26/07/16 15:15, Thomas Gleixner wrote: > Jon, > > On Tue, 26 Jul 2016, Jon Hunter wrote: >> On 25/07/16 16:35, rcochran@linutronix.de wrote: >>> Just to be sure, this problem didn't exist before the HP rework, that >>> is, suspend worked fine with and without CONFIG_PREEMPT, right? >> >> Correct. I test suspend on Tegra with both multi_v7_defconfig >> (CONFIG_PREEMPT disabled) and tegra_defconfig (CONFIG_PREEMPT enabled). >> Looking at the git history for these configs I don't see any changes in >> this regard since they were added (unless some underlying Kconfig files >> have changed). > > Is that fully reproducible, i.e on every suspend? No not every suspend. I run 10 suspend cycles on each Tegra board (5 boards total) and typically between 3 and 5 boards would see the stall in the 10 suspend cycles. So it does appear to be timing sensitive. > Can you please check whether this issue happens with just cpu offline as > well? I.e. set a cpu (or all non-boot cpus) offline, wait long enough that the > stall detector can trigger, set the cpu(s) online again and repeat. I can, but it appears like Richard's patch has fixed this. I am happy to do more testing if necessary. Cheers Jon -- nvpublic