From owner-freebsd-current@freebsd.org  Tue Aug  7 16:51:07 2018
Return-Path: <owner-freebsd-current@freebsd.org>
Delivered-To: freebsd-current@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id E59931063FE0
 for <freebsd-current@mailman.ysv.freebsd.org>;
 Tue,  7 Aug 2018 16:51:06 +0000 (UTC)
 (envelope-from kevans@freebsd.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "smtp.freebsd.org",
 Issuer "Let's Encrypt Authority X3" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 96CF377378;
 Tue,  7 Aug 2018 16:51:06 +0000 (UTC)
 (envelope-from kevans@freebsd.org)
Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com
 [209.85.167.43])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G3" (verified OK))
 (Authenticated sender: kevans)
 by smtp.freebsd.org (Postfix) with ESMTPSA id 3460F14E00;
 Tue,  7 Aug 2018 16:51:06 +0000 (UTC)
 (envelope-from kevans@freebsd.org)
Received: by mail-lf1-f43.google.com with SMTP id a4-v6so12131724lff.5;
 Tue, 07 Aug 2018 09:51:06 -0700 (PDT)
X-Gm-Message-State: AOUpUlGV43ytmBGWPM9eGilAW5PaG2YeQF0chma+TG0tSHeVEu+c+qs1
 9R44Mko9pcFR7Ac/brgnLWP9VSNbvLpexdJ1qSY=
X-Google-Smtp-Source: AAOMgpdzlaAp5YbiILhLFrAp6cMvAjpCoqZf10kyyhjGvRU34Eh+iQFEMt6SGkglr6D8W7G/8Ft6gWA4KSeN+t0y6Ak=
X-Received: by 2002:a19:9481:: with SMTP id
 o1-v6mr15395424lfk.38.1533660664822; 
 Tue, 07 Aug 2018 09:51:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:5742:0:0:0:0:0 with HTTP;
 Tue, 7 Aug 2018 09:50:44 -0700 (PDT)
In-Reply-To: <CAF6rxgmGLbLnMacc_Bb7_RKEAb6vazBjXwcECzsuVqJWKMrBvQ@mail.gmail.com>
References: <CAF6rxg=4OnHEJa1OnJerMeEKD66nZg3j-H-XZ-9YAA1TE_NoDQ@mail.gmail.com>
 <CACNAnaFv9Gj+M2Gb8FbwY5q56dnTR6OgjZ5qth9gjr8LreHeow@mail.gmail.com>
 <20180804083720.GJ6049@kib.kiev.ua>
 <CACNAnaF1anCXzjivX0jqur+omy_+6Xv4D+DttzLQY9g6qaxYbw@mail.gmail.com>
 <20180805104341.GX6049@kib.kiev.ua>
 <CACNAnaHAoVE57aw7UUPO=psOXz0nnUaCSXtJSFhpBo+Bhp_qnw@mail.gmail.com>
 <CAF6rxgmGLbLnMacc_Bb7_RKEAb6vazBjXwcECzsuVqJWKMrBvQ@mail.gmail.com>
From: Kyle Evans <kevans@freebsd.org>
Date: Tue, 7 Aug 2018 11:50:44 -0500
X-Gmail-Original-Message-ID: <CACNAnaHdgbe+VDZC-gV-oU7=DgNZhEfg1Uanrs0Lh4MgkLXsOQ@mail.gmail.com>
Message-ID: <CACNAnaHdgbe+VDZC-gV-oU7=DgNZhEfg1Uanrs0Lh4MgkLXsOQ@mail.gmail.com>
Subject: Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
To: Eitan Adler <eadler@freebsd.org>
Cc: Kostik Belousov <kostikbel@gmail.com>, 
 freebsd-current Current <freebsd-current@freebsd.org>
Content-Type: text/plain; charset="UTF-8"
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2018 16:51:07 -0000

On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler <eadler@freebsd.org> wrote:
> On Mon, 6 Aug 2018 at 11:27, Kyle Evans <kevans@freebsd.org> wrote:
>>
>> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov <kostikbel@gmail.com> wrote:
>> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote:
>> >>
>> >> He now gets a little further, but ends up with the same panic due to
>> >> efirtc_probe trying to get time to verify the rtc's actually
>> >> implemented. What kind of approach must we take to ensure curcpu is
>> >> synced?
>> >
>> > It does not panic for me, when I load efirt.ko from the loader prompt.
>> > Anyway, try this
>>
>> Right, I also don't get a panic on any of my machines from this.
>> Hopefully he'll have a chance to try this soon.
>
> This change has no impact: it still panics in the same way as without the patch.
>

That seems indicative of a bigger problem, since we use proc0
throughout all these bits so we should still be dealing with the same
pmap that got passed to pmap_pinit0 when we grab
curthread->td_proc->p_vmspace->vm_pmap.