From owner-svn-src-all@freebsd.org Sat Feb 4 20:22:32 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 DD7D2CD1B85; Sat, 4 Feb 2017 20:22:32 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from smtp.imp.ch (smtp.imp.ch [IPv6:2001:4060:1:1001::13:196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F9EA185F; Sat, 4 Feb 2017 20:22:32 +0000 (UTC) (envelope-from andreast@FreeBSD.org) Received: from [192.168.225.14] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by fgznet.ch (Postfix) with ESMTPSA id 49CB4C53F9; Sat, 4 Feb 2017 21:22:27 +0100 (CET) Subject: Re: svn commit: r313037 - in head/sys: amd64/include kern mips/include net powerpc/include sparc64/include To: Jason Harmening References: <201702010332.v113WnYf041362@repo.freebsd.org> <20170203231238.0675c289@kan> <8523aaa5-6c30-9f9f-40f0-fdf82cdf1669@pix.net> <6bf86e46-9714-c7e9-8d47-845761e2de24@FreeBSD.org> 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 From: Andreas Tobler Message-ID: <8a2f7f7d-14c3-8e75-e060-fc41213ce389@FreeBSD.org> Date: Sat, 4 Feb 2017 21:22:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: Idefix Submit on 127.0.1.1 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:22:33 -0000 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