From owner-svn-src-all@freebsd.org Sat Feb 4 20:39:31 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E2EDCD1F4F; Sat, 4 Feb 2017 20:39:31 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-ot0-x243.google.com (mail-ot0-x243.google.com [IPv6:2607:f8b0:4003:c0f::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB9931E8A; Sat, 4 Feb 2017 20:39:30 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by mail-ot0-x243.google.com with SMTP id 65so6166015otq.2; Sat, 04 Feb 2017 12:39:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W7AQFNRW6Pso0h2MUXQhud6LmcjyZuHP2BvW5JOP/7g=; b=c+rcJQWGoT4PtXGUUGzRjHC42j9Fc1M5Oygy+rVNMFgLpqcG0dOz8YGGsETAMaNbSa 2apIYs/BfdkK0HuuBZjBsp52nK7aWBeHUdieHLwvx5bqJZ783Ga/FDPn8HLU66X9HIRd vle7jqlloK9YId7quPc18TalQFO7XyxpFp3tWKTScFByle2u8gQ9hTh59f7Gez1Ebnr8 dhZHV0FLgwe+sKo8MpLZiX9BX3J9N21m4gqP77I5PvSWiPRoD2brXqe0Vp5xbI3/sw5S 7Iae6BOHUNYWNsMTFZGYVP1Kfc5xSyN2qf6chiuiIqLw5x+OFds2AsRPxTE6t1zs5aXG SCug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W7AQFNRW6Pso0h2MUXQhud6LmcjyZuHP2BvW5JOP/7g=; b=k4JXt81L2s9vNHJfwRUe5nZvV4EtUB8dBQ4rqTCMggcAAQtrrln0y5rrepurwq+enB 7O0OGQKKM2WApnxfTooltX8XO60LQwp3Ri1LEiMadoApXJm6IrH+bkEWUkOiN9yhL6wO wuiZzS//jLVQIsN6tctFCO3SPigPv4iLGxzrjzEKiK4Bi0zeKQ/qv7unCDtltOVLl/d9 QUZKIGjSLeI3ePgfaBzNu6o79glulu7+ovS+aYshl+7g76D75FMNjUNVc3vSXp5cyWso 1yQLAAprLsvjyGjf+Obwjxp0YYNCeyHSCKKJLzidvrj44/Rdocy4VJwNFQB+i2yBhABL 9zrg== X-Gm-Message-State: AIkVDXKERdFrwiqsHy0M1/oj0LHH1Mya2jUOwfHeef5m/TP9tIiS5VxksaFzzieFw5dvnchBB1HaUI1GdFuFkg== X-Received: by 10.157.27.208 with SMTP id v16mr1577762otv.200.1486240770032; Sat, 04 Feb 2017 12:39:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.51.7 with HTTP; Sat, 4 Feb 2017 12:39:29 -0800 (PST) In-Reply-To: <8a2f7f7d-14c3-8e75-e060-fc41213ce389@FreeBSD.org> References: <201702010332.v113WnYf041362@repo.freebsd.org> <20170203231238.0675c289@kan> <8523aaa5-6c30-9f9f-40f0-fdf82cdf1669@pix.net> <6bf86e46-9714-c7e9-8d47-845761e2de24@FreeBSD.org> <8a2f7f7d-14c3-8e75-e060-fc41213ce389@FreeBSD.org> From: Jason Harmening Date: Sat, 4 Feb 2017 12:39:29 -0800 Message-ID: Subject: Re: svn commit: r313037 - in head/sys: amd64/include kern mips/include net powerpc/include sparc64/include To: Andreas Tobler Cc: Kurt Lidl , Alexander Kabaev , "Jason A. Harmening" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Ed Maste , Justin Hibbits Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 20:39:31 -0000 Can you post an example of such panic? Only 2 MI pieces were changed, netisr and rmlock. I haven't seen problems on my own amd64/i386/arm testing of this, so a backtrace might help to narrow down the cause. On Sat, Feb 4, 2017 at 12:22 PM, Andreas Tobler wrote: > On 04.02.17 20:54, Jason Harmening wrote: > >> I suspect this broke rmlocks for mips because the rmlock implementation >> takes the address of the per-CPU pc_rm_queue when building tracker >> lists. That address may be later accessed from another CPU and will >> then translate to the wrong physical region if the address was taken >> relative to the globally-constant pcpup VA used on mips. >> >> Regardless, for mips get_pcpup() should be implemented as >> pcpu_find(curcpu) since returning an address that may mean something >> different depending on the CPU seems like a big POLA violation if >> nothing else. >> >> I'm more concerned about the report of powerpc breakage. For powerpc we >> simply take each pcpu pointer from the pc_allcpu list (which is the same >> value stored in the cpuid_to_pcpu array) and pass it through the ap_pcpu >> global to each AP's startup code, which then stores it in sprg0. It >> should be globally unique and won't have the variable-translation issues >> seen on mips. Andreas, are you certain this change was responsible the >> breakage you saw, and was it the same sort of hang observed on mips? >> > > I'm really sure. 313036 booted fine, allowed me to execute heavy > compilation jobs, np. 313037 on the other side gave me various patterns of > panics. During startup, but I also succeeded to get into multiuser and then > the panic happend during port building. > > I have no deeper inside where pcpu data is used. Justin mentioned netisr? > > Andreas > >