From owner-freebsd-hackers@freebsd.org Sun Feb 18 18:08:08 2018 Return-Path: Delivered-To: freebsd-hackers@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 6D6FFF1D9D1; Sun, 18 Feb 2018 18:08:08 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 0744382ED8; Sun, 18 Feb 2018 18:08:08 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x22c.google.com with SMTP id v90so6963034qte.12; Sun, 18 Feb 2018 10:08:08 -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=m+LrZUy3RpK+YZmHv8DL7+nGCBlfbj/EGQYxYpkRu0Y=; b=MC4uFCPU9o5Ih7ORz48ie/x1LY2t3QACrkuaTLpZKPB1RTBIgR+SMVBJbOk40TyLn5 iIt1BClBfB+F4uI8SKz3VCb9UyVe64PTq6LIQ+CpcMrecAoiS5bAGigXxrAPTWQzt1i2 AsR4DrMEmuZnp6jZi9ujIhfLkNKcqTpVmYlQCylaiuP4es/R7UD4997sULko7s8qmsXU UzBE2e6uXm3VjNHGBK0k5XOGH4E472cOnGHQVGA5HMsbmMbcdjxKmEiwyCTcJU8EP835 Czs5+FBurGdwJqKqsr/kECDtnxuiR2IM7u1L6UhEmDFZt+2CPmQ2h1BTSO0ecLZ0P5YB NdfA== 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=m+LrZUy3RpK+YZmHv8DL7+nGCBlfbj/EGQYxYpkRu0Y=; b=SAP+Ji0RI0C0zIo2ISIszlk2kWmkG7Yq4u0kHPt4CCw9YNQqV0cpwSK0usHPmMQhJB 6y0FdDQQ1kJifnpAlfp++WbunFOvfYN6KeUYgMJyyk5nKKIw+RoZS3epUZKsxHynN4vk IrshpR+dkyNX/K6kr89A3HvXhY6jjhwYxjrShX7nJSnoI2x2geEGFpz9kjun6dCyNEr6 ZHZJwa9YviCy57FBv6ZPw5T+M/7zhcmVPgDTMKwYkz3hPSmcfJwJ6iWXKVc0zRx5sRFn P9EteRwzGJpVNT9mme5spCsQy1KYpBo/S+lBBdt7YlescS/hrAQKGQ9xiMqElS6IysAC iUQQ== X-Gm-Message-State: APf1xPAExGn3ZU+ZB04GJyr0UizDsFu93n2qmga6+ekcANSz8FTk6oQr kRbdK7Q27uzX4KKKrvJJkm7+kXF34EfAnDoPYWI= X-Google-Smtp-Source: AH8x225nxW9c4CsaZ7LS+bMN1XEaYpHsQxqpAGlxP9cnM2fz7V6+/MWdXJJwrNp00Fh6YugJPS0w4sNsWD3CYd3yfxk= X-Received: by 10.200.38.188 with SMTP id 57mr6877681qto.220.1518977287640; Sun, 18 Feb 2018 10:08:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.58.99 with HTTP; Sun, 18 Feb 2018 10:08:07 -0800 (PST) In-Reply-To: <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> From: Mateusz Guzik Date: Sun, 18 Feb 2018 19:08:07 +0100 Message-ID: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: Mark Millard Cc: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 18:08:08 -0000 Can you please bisect this? There is another report stating that r329418 works fine. On Sun, Feb 18, 2018 at 6:35 PM, Mark Millard wrote: > > On 2018-Feb-17, at 6:10 PM, Mark Millard > wrote: > > > [Some more information added, from /usr/libexec/kgdb use.] > > > > On 2018-Feb-17, at 5:39 PM, Mark Millard > wrote: > > > >> This is for FreeBSD running under Hyper-V on a Windows 10 Pro machine. > >> The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS files. > >> 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen > >> Threadripper 1950X). No other Hyper-V use. > > Trond's report seems to be for a "4 core" Intel i7 context (as seen > by FreeBSD in virtual box). So Ryzen seems to be non-essential for > reproduction. > > Both of our reports are from some form of using FreeBSD in a virtual > machine (Hyper-V and VirtualBox). I do not know if that is a required > type of context or not. > > >> This happened during: > >> > >> # ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_ > nodebug_clang_altbinutils-amd64-host.sh check-old > DESTDIR=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils > >> Script started, output file is /root/sys_typescripts/ > typescript_make_powerpc64vtsc_nodebug_clang_altbinutils- > amd64-host-2018-02-17:15:56:20 > >>>>> Checking for old files > >> > > I got another example but during a buildworld: > > >>> Deleting stale files in build tree... > cd /usr/src; MACHINE_ARCH=powerpc64 MACHINE=powerpc CPUTYPE= > BUILD_TOOLS_META=.NOMETA CC="cc -target powerpc64-unknown-freebsd12.0 > --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CXX="c++ -target > powerpc64-unknown-freebsd12.0 --sysroot=/usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CPP="cpp -target > powerpc64-unknown-freebsd12.0 --sysroot=/usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" > AS="/usr/local/powerpc64-unknown-freebsd12.0/bin/as" > AR="/usr/local/powerpc64-unknown-freebsd12.0/bin/ar" > LD="/usr/local/powerpc64-unknown-freebsd12.0/bin/ld" LLVM_LINK="" > NM=/usr/local/powerpc64-unknown-freebsd12.0/bin/nm > OBJCOPY="/usr/local/powerpc64-unknown-freebsd12.0/bin/objcopy" > RANLIB=/usr/local/powerpc64-unknown- > freebsd12.0/bin/ranlib STRINGS=/usr/local/bin/ > powerpc64-unknown-freebsd12.0-strings SIZE="/usr/local/powerpc64-unknown-freebsd12.0/bin/size" > INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/powerpc64vtsc_ > clang_altbinutils/powerpc.powerpc64/usr/src/powerpc. > powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/ > legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/ > usr/src/powerpc.powerpc64/tmp/legacy/bin:/usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/ > usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/ > usr/src/powerpc.powerpc64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin > SYSROOT=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > make -f Makefile.inc1 BWPHASE=worldtmp DESTDIR=/usr/obj/ > powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -DBATCH_DELETE_OLD_FILES delete-old d > elete-old-libs >/dev/null > > load: 0.68 cmd: make 62180 [select] 25.15r 0.00u 0.00s 0% 1468k > make: Working in: /usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64 > packet_write_wait: Connection to 192.168.1.165 port 22: Broken pipe > > > (I noticed the long pause and got the ^T in before the panic.) > > Yet again it is xargs related fork activity that gets the problem (from > core.txt.1 ): > > 561 Thread 100836 (PID=69982: xargs) fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:840 > . . . > * 559 Thread 100811 (PID=62304: xargs) doadump (textdump=-2122191464) at > pcpu.h:230 > > spin lock 0xffffffff81b3cf00 (sched lock 24) held by 0xfffff806aa6d5000 > (tid 100836) too long > panic: spin lock held too long > cpuid = 24 > time = 1518974055 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00f11304d0 > vpanic() at vpanic+0x18d/frame 0xfffffe00f1130530 > panic() at panic+0x43/frame 0xfffffe00f1130590 > _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame > 0xfffffe00f11305a0 > thread_lock_flags_() at thread_lock_flags_+0xdb/frame 0xfffffe00f1130610 > statclock_cnt() at statclock_cnt+0xdc/frame 0xfffffe00f1130650 > handleevents() at handleevents+0x113/frame 0xfffffe00f11306a0 > timercb() at timercb+0xa9/frame 0xfffffe00f11306f0 > lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfffffe00f1130730 > timerint_u() at timerint_u+0x96/frame 0xfffffe00f1130810 > thread_lock_flags_() at thread_lock_flags_+0xc1/frame 0xfffffe00f1130880 > fork1() at fork1+0x1b9f/frame 0xfffffe00f1130930 > sys_vfork() at sys_vfork+0x4c/frame 0xfffffe00f1130980 > amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00f1130ab0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffc5a0 > > > > > === > Mark Millard > marklmi at yahoo.com > ( markmi at dsl-only.net is > going away in 2018-Feb, late) > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Mateusz Guzik