From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Subject: Re: next-20130627 breaks i.MX6 sabre sd UART console Date: Mon, 01 Jul 2013 15:14:24 -0700 Message-ID: <51D1FF40.2030805@codeaurora.org> References: <51CDB26A.9060500@codeaurora.org> <51CDC2B3.1030907@codeaurora.org> <20130629020738.GG11625@codeaurora.org> <51D1DD6D.8050805@codeaurora.org> <51D1EC8C.4050101@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from smtp.codeaurora.org ([198.145.11.231]:36222 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755393Ab3GAWO0 (ORCPT ); Mon, 1 Jul 2013 18:14:26 -0400 In-Reply-To: Sender: linux-next-owner@vger.kernel.org List-ID: To: Thomas Gleixner Cc: Stehle Vincent-B46079 , "linux-next@vger.kernel.org" , John Stultz , "linux-kernel@vger.kernel.org" , Mark Rutland On 07/01/13 14:24, Thomas Gleixner wrote: > On Mon, 1 Jul 2013, Stephen Boyd wrote: >> On 07/01/13 13:14, Thomas Gleixner wrote: >>> The issue is very subtle. What happens is: >>> >>> CPU0 CPU1 >>> >>> Switch to oneshot mode >>> >>> Copy the bits from tick_broadcast_mask to >>> tick_broadcast_oneshot_mask. We need to do >>> that so the other cpus reach the timer irq >>> and the softirq which switches them to >>> oneshot. >>> >>> Kick the broadcast device into oneshot. >>> >>> Timer interrupt fires >>> >>> irq_enter sees the cpu in >>> tick_broadcast_oneshot_mask and >>> sets the device to oneshot mode >>> >>> handle_periodic: >>> Sees oneshot mode and adds >>> period to >>> dev->next_event(KTIME_MAX) >>> >> Yep. It is also racing with the timer interrupt so having more than two >> CPUs must help widen the window (which is why we see it on the higher >> numbered CPUs). > The race above is about the timer interrupt. You mean the broadcast > one which is still enabled due to the dummy -> functional transition > issue, right? That helps a lot to make this more visible, because we > double the number of events. I was thinking that tick_check_oneshot_broadcast() is racing with tick_switch_to_oneshot() and because we have more CPUs we're more likely to have a CPU fix up the handler in tick_switch_to_oneshot() after tick_check_oneshot_broadcast() forces that CPU to oneshot mode and the periodic handler runs. I wonder if I can reproduce it locally by making tick_switch_to_oneshot() spin for a jiffy or two on CPU1. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation