From owner-svn-src-head@freebsd.org Sat Feb 4 06:27:32 2017 Return-Path: Delivered-To: svn-src-head@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 69228CD075F; Sat, 4 Feb 2017 06:27:32 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (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 2B964934; Sat, 4 Feb 2017 06:27:32 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by mail-ot0-x241.google.com with SMTP id 65so4643214otq.2; Fri, 03 Feb 2017 22:27:32 -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=V6Y8LXo1sFhYnQ++2JlnTTuJbbpmt7WD9BhqEOVvjhA=; b=kvv4kckN9Vdpzi1EIsuM4UO8oLaL/Rn0YzTi6H5aJqrdO3UqOUmh/076BzBolY3xSL 2YuqxDKMUnuWEO3avyAI6K6SRRhdBDStzLo1ZeRhw1d3K7SETTK6gy4QqQDGUTmoaIQC 0i6eOBJ5RoYAm3+399KNwSPsg7tlcFXAv0QpS5PVZODM9o2gvTOY0mVA787MTjKaDqU+ Br+fJ7MCFNk5DNCx5OCJqNVD5nAaV+Z4EASoEx9wWgmlLPenyhsoU1YXFy0Udgr1Uz0B shUfY07juUx+FWtWk1mbwyKbDwWRUhZDISRFSGWQVrGUmi52V+dqz5DI9V6vgXvfejiz sweQ== 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=V6Y8LXo1sFhYnQ++2JlnTTuJbbpmt7WD9BhqEOVvjhA=; b=P6d/ZGYBUbfqIvgZKYd5Is4p/h3Ae5/+RrwI0etWAekY9wx0JaKPQ2JlCMCfdAn2mK s5M5j8vw42bmbPFeISYnTe4X88vlEFEO9r59V8MhdOlYKcFWov+sOcsDOPvi351jbiNB oTIHlRYBnN1deRK9ldJenekyaTuRqAXbeZXRIUFsQ+zzfea0kqCBycawoA/gG+TlfUMA MYM6JtLP/2j/r9KTKitEJ3QUrti7brdwGySpQ3cDWda+I8cXLHV+ggQgFVUX4fGH5VxR /KmLIHwiRS9N2GhurSwPCeeB/hHaNNVzJTk2DzYtfUfQyA1mLtE4IsJCpsnzV2ptHbsn zsRg== X-Gm-Message-State: AMke39kuum+IIsExMLv1SgK82LRUXzgDSNtsAGATuB9hA1B0zjcswsBSsV+zK9cxWG95ruxp7ebjU/TktK29jQ== X-Received: by 10.157.41.173 with SMTP id n42mr312752otb.158.1486189651370; Fri, 03 Feb 2017 22:27:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.51.7 with HTTP; Fri, 3 Feb 2017 22:27:30 -0800 (PST) In-Reply-To: <8523aaa5-6c30-9f9f-40f0-fdf82cdf1669@pix.net> References: <201702010332.v113WnYf041362@repo.freebsd.org> <20170203231238.0675c289@kan> <8523aaa5-6c30-9f9f-40f0-fdf82cdf1669@pix.net> From: Jason Harmening Date: Fri, 3 Feb 2017 22:27:30 -0800 Message-ID: Subject: Re: svn commit: r313037 - in head/sys: amd64/include kern mips/include net powerpc/include sparc64/include To: Kurt Lidl Cc: Alexander Kabaev , "Jason A. Harmening" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Ed Maste Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 06:27:32 -0000 It's hard to argue with that:) I've backed it out until we can figure out what's going on. Sorry for the breakage. On Fri, Feb 3, 2017 at 9:54 PM, Kurt Lidl wrote: > Having just spent a couple of hours bisecting what broke the kernel on > my mips64 machine, I can definitively state it was this commit. > > With this commit in place, the kernel hangs early in the > autoconfiguration: > > gcc version 4.2.1 20070831 patched [FreeBSD] > Preloaded elf kernel "kernel" at 0xffffffff80aa96a0. > real memory = 523239424 (510976K bytes) > Physical memory chunk(s): > 0x00bf3000 - 0x080d5fff, 122564608 bytes (29923 pages) > 0x08101000 - 0x0ff00fff, 132120576 bytes (32256 pages) > 0x410000000 - 0x41f196fff, 253325312 bytes (61847 pages) > avail memory = 504360960 (480MB) > Create COP2 context zone > AP #1 started! > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > ---- hangs here ---- > > -Kurt > > On 2/4/17 12:29 AM, Jason Harmening wrote: > >> Hi, >> >> I'm a bit confused as to how this change breaks MIPS. The new function, >> get_pcpu() is intended to be used only to access the per-cpu data >> pointer locally. It returns pcpup, which is the per-cpu pointer wired >> into the local TLB to translate to the local CPU's physical data region, >> correct? >> >> This is the same value used by the per-CPU accessors such as PCPU_ADD >> and PCPU_GET. The MI portions of this change only use get_pcpu() to >> access the local CPU's data, e.g. under a critical section in the >> rmlock. It is not intended to be used for iterating all CPUs. >> >> If I've missed something and MIPS is truly broken by this, then I'll >> gladly revert, but (maybe because it's late) I'm not seeing where this >> goes wrong on MIPS. >> >> Thanks, >> Jason >> >> On Fri, Feb 3, 2017 at 8:12 PM, Alexander Kabaev > > wrote: >> >> On Wed, 1 Feb 2017 03:32:49 +0000 (UTC) >> "Jason A. Harmening" wrote: >> >> > Author: jah >> > Date: Wed Feb 1 03:32:49 2017 >> > New Revision: 313037 >> > URL: https://svnweb.freebsd.org/changeset/base/313037 >> >> > >> > Log: >> > Implement get_pcpu() for the remaining architectures and use it to >> > replace pcpu_find(curcpu) in MI code. >> > >> > Modified: >> > head/sys/amd64/include/pcpu.h >> > head/sys/kern/kern_rmlock.c >> > head/sys/mips/include/pcpu.h >> > head/sys/net/netisr.c >> > head/sys/powerpc/include/cpufunc.h >> > head/sys/powerpc/include/pcpu.h >> > head/sys/sparc64/include/pcpu.h >> > >> >> Hi, >> >> this change was not reviewed nor testing was thought for all >> architectures it touches. The change happens to break MIPS quite >> thoroughly, since MIPS is using different pointers when accessing PCPU >> area locally and when doing iterations using cpu_to_cpuid array. I >> therefore officially am requesting this change to be reverted until >> reasonable solution is found to unbreak architectures that use wired >> TLBs to access local per-CPU data. >> >> -- >> Alexander Kabaev >> >> >> >