From patchwork Tue Mar 4 21:26:23 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kirill Tkhai X-Patchwork-Id: 326509 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 921AF2C007E for ; Wed, 5 Mar 2014 08:29:30 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756713AbaCDV3Q (ORCPT ); Tue, 4 Mar 2014 16:29:16 -0500 Received: from forward8l.mail.yandex.net ([84.201.143.141]:36934 "EHLO forward8l.mail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755973AbaCDV3P (ORCPT ); Tue, 4 Mar 2014 16:29:15 -0500 Received: from smtp7.mail.yandex.net (smtp7.mail.yandex.net [77.88.61.55]) by forward8l.mail.yandex.net (Yandex) with ESMTP id CE17A1A40FB3; Wed, 5 Mar 2014 01:29:11 +0400 (MSK) Received: from smtp7.mail.yandex.net (localhost [127.0.0.1]) by smtp7.mail.yandex.net (Yandex) with ESMTP id 37AFC1580094; Wed, 5 Mar 2014 01:29:11 +0400 (MSK) Received: from 128-72-95-235.broadband.corbina.ru (128-72-95-235.broadband.corbina.ru [128.72.95.235]) by smtp7.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Z86S5FsyKC-TAU8qwiL; Wed, 5 Mar 2014 01:29:10 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: fff8f84d-ee89-4a35-8c1e-83d4e7ae6516 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1393968550; bh=obJShNk9nIrXr8mmifYFUnY8qQVqenFP/o4DrCXDiUs=; h=Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=m2hxxmtgc1qOXNuE1en/NTGWcuMGUVNgh2a1pFGD0v6ZekS7gqFAYAlgCaelK9wd8 pd3I7ItkttFks7JLyX7Fa0bGd5HLy0NFXpTteRkYctk+WTywd9hcOc2K5N0/ZHVK38 1e1A3xrvp/7e9s2cckIKLc6wiaASZJvuCMEK0NnI= Authentication-Results: smtp7.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <531644FF.30800@yandex.ru> Date: Wed, 05 Mar 2014 01:26:23 +0400 From: Kirill Tkhai Reply-To: tkhai@yandex.ru User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0 MIME-Version: 1.0 To: David Miller CC: allen.pais@oracle.com, linux-rt-users@vger.kernel.org, sparclinux@vger.kernel.org, bigeasy@linutronix.de Subject: Re: [PATCH 3/4] sparc64: convert spinlock_t to raw_spinlock_t in mmu_context_t References: <259041392800232@web13m.yandex.ru> <530475A8.3060602@oracle.com> <359241392801938@web24j.yandex.ru> <20140304.150338.542737888922892447.davem@davemloft.net> In-Reply-To: <20140304.150338.542737888922892447.davem@davemloft.net> Sender: sparclinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: sparclinux@vger.kernel.org On 05.03.2014 00:03, David Miller wrote: > From: Kirill Tkhai > Date: Wed, 19 Feb 2014 13:25:38 +0400 > >> It seems for me it's better to decide the problem not changing protector of tsb like in patch above. >> You may get good stack without sun4v_data_access_exception error, which was in the first or second >> message. > > My suspicion is that what happens when we get the data access error is > that we sample the tlb batch count as non-zero, preempt, then come > back from preemption seeing the tlb batch in a completely different state. > > And that's what leads to the crash, in the one trace I saw the TSB address > passed to tsb_flush() (register %o0) was some garbage like 0x103. > I suggested to set tb_active to zero just for experiment. This way Last Allen's stack (from 26 feb. 11:52) still contains flush_tlb_pending(). Strange, why this is so, maybe bad initialized per-cpu tlb_batch, and something bad is with BSS... --- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/sparc/mm/tlb.c b/arch/sparc/mm/tlb.c index b12cb5e..e1d1fd6 100644 --- a/arch/sparc/mm/tlb.c +++ b/arch/sparc/mm/tlb.c @@ -54,7 +54,7 @@ void arch_enter_lazy_mmu_mode(void) { struct tlb_batch *tb = &__get_cpu_var(tlb_batch); - tb->active = 1; + tb->active = 0; } void arch_leave_lazy_mmu_mode(void)