From owner-freebsd-current@freebsd.org Sat Mar 24 21:56:38 2018 Return-Path: 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 1D788F4E5F6 for ; Sat, 24 Mar 2018 21:56:38 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A8D2181D5F for ; Sat, 24 Mar 2018 21:56:37 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: by mailman.ysv.freebsd.org (Postfix) id 67476F4E5F5; Sat, 24 Mar 2018 21:56:37 +0000 (UTC) Delivered-To: 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 430F4F4E5F4 for ; Sat, 24 Mar 2018 21:56:37 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nsstlmta09p.bpe.bigpond.com (nsstlmta09p.bpe.bigpond.com [203.38.21.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Openwave Messaging Inc." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F1C6881D5B for ; Sat, 24 Mar 2018 21:56:34 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep07p-svc.bpe.nexus.telstra.com.au with ESMTP id <20180324205121.DELH24132.nsstlfep07p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com>; Sun, 25 Mar 2018 07:51:21 +1100 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedtgedrvdefgddugeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuuffpveftpgfvgffnuffvtfetnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefffggjfhggtgfguffvhffksegrjehmredtreejnecuhfhrohhmpeetnhgurhgvficutfgvihhllhihuceorghrvghilhhlhiessghighhpohhnugdrnhgvthdrrghuqeenucffohhmrghinhepfhhrvggvsghsugdrohhrghdprggtqdhrrdhnuhenucfkphepuddvgedrudeltddrgedtrddukedvnecurfgrrhgrmhephhgvlhhopegluddtrddtrddtrdeingdpihhnvghtpeduvdegrdduledtrdegtddrudekvddpmhgr X-RG-VS-CLASS: clean X-Authentication-Info: Submitted using ID areilly@bigpond.net.au Received: from [10.0.0.6] (124.190.40.182) by smtp.telstra.com (9.0.019.22-1) (authenticated as areilly@bigpond.net.au) id 5A61443617890073; Sun, 25 Mar 2018 07:51:21 +1100 Date: Sun, 25 Mar 2018 07:49:17 +1100 User-Agent: K-9 Mail for Android In-Reply-To: References: <20180324035653.GA3411@Zen.ac-r.nu> MIME-Version: 1.0 Subject: Re: 12-Current panics on boot (didn't a week ago.) To: Warner Losh CC: FreeBSD Current From: Andrew Reilly Message-ID: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 21:56:38 -0000 Hi Warner, The breakage was in 331470, and at least one version earlier, that I upda= ted past when it panicked=2E I'm guessing that kdb's inability to dump would be down to it not having f= ound any disk devices yet, right? So yes, bisecting to narrow down the iss= ue is probably the best bet=2E I'll try your r331464: if that works that l= eaves only four or five revisions=2E Of course the breakage could be hardw= are specific=2E Cheers, --=20 Andrew On 25 March 2018 1:14:40 am AEDT, Warner Losh wrote: >Also, what rev failed? I booted r331464 last night w/o issue=2E > >Warner > >On Fri, Mar 23, 2018 at 9:56 PM, Andrew Reilly >wrote: > >> Hi all, >> >> For reasons that still escape me, I haven't been able to get a kernel >dump >> to debug, sorry=2E >> >> Just thought that I'd generate a fairly low-quality report, to see if >> anyone has some ideas=2E >> >> The last kernel that I have that booted OK (and I'm now running) is: >> FreeBSD Zen=2Eac-r=2Enu 12=2E0-CURRENT FreeBSD 12=2E0-CURRENT #1 r33106= 4M: >Sat >> Mar 17 07:54:51 AEDT 2018 =20 >root@Zen:/usr/obj/usr/src/amd64=2Eamd64/sys/GENERIC >> amd64 >> >> The machine is a: >> CPU: AMD Ryzen 7 1700 Eight-Core Processor (2994=2E46-MHz >K8-class >> CPU) >> Origin=3D"AuthenticAMD" Id=3D0x800f11 Family=3D0x17 Model=3D0x1=20 >Stepping=3D1 >> Features=3D0x178bfbff> APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> >> >> Kernels built from head as of a couple of hours ago get through >launching >> the other CPUs and then stops somewhere in random, apparently: >> >> SMP: AP CPU #2 Launched! >> Timecounter "TSC-low" frequency 1497223020 Hz quality 1000 >> random: entpanic: mtx_lock() of spin mutex (null) @ >> /usr/src/sys/kern/subr_bus=2Ec:617 >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe00004507a0 >> vpanic() at vpanic+0x18d/frame 0xfffffe0000450800 >> doadump () at doadump/frame 0xfffffe0000450880 >> __mtx_lock_flags() at __mtx_lock_flags+0x163/frame 0xfffffe00004508d0 >> devctl_queue_data_f() at devctl_queue_data_f+0x6a/frame >0xfffffe0000450900 >> g_dev_taste() at g_dev_taste+0x370/frame 0xfffffe0000450a10 >> g_new_provider_event() at g_new_provider_event+0xfa/frame >> 0xfffffe0000450a30 >> g_run_events() at g_run_events+0x151/frame 0xfffffe0000450a70 >> fork_exit() at fork_exit+0x84/frame 0xfffffe0000450ab0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000450ab0 >> --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- >> KDB: enter: panic >> [ thread pid 14 tid 100052 ] >> Stopped at kdb_enter+0x3b: movq $0,kdb_why >> db> dump >> Cannot dump: no dump device specified=2E >> db> >> >> Now dumping worked fine the last time the kernel panicked: I have >> dumpdev=3DAUTO in rc=2Econf and I have swap on nvd0p3 (first) and >> /dev/zvol/root/swap >> (second, larger than the first=2E) >> >> Root on the nvd0p2 is ZFS, and ther's a four-drive raidZ with user >> directories and what-not on them, and another ZFS on an external USB >drive >> that I use >> for backups, unmounted=2E >> >> In the new kernels, we clearly aren't even getting as far as finding >the >> hubs and controllers, let alone the drives=2E >> >> I've attached dmesg=2Eboot from the last boot from last week's good >kernel=2E >> (While briefly in yoyo mode I turned the SMT back on, so now there >are 16 >> cores >> instead of the eight mentioned in the crash dump=2E Didn't help, but I >> haven't turned it back off yet=2E) >> >> Cheers, >> >> Andrew >> >> >> _______________________________________________ >> freebsd-current@freebsd=2Eorg mailing list >> https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >"freebsd-current-unsubscribe@freebsd=2Eorg" >> >>