From owner-freebsd-arm@freebsd.org Sat Jan 13 03:58:48 2018 Return-Path: Delivered-To: freebsd-arm@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 B01ADE708CB for ; Sat, 13 Jan 2018 03:58:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-125.reflexion.net [208.70.210.125]) (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 6D0FD717FD for ; Sat, 13 Jan 2018 03:58:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4541 invoked from network); 13 Jan 2018 02:58:41 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Jan 2018 02:58:41 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Fri, 12 Jan 2018 21:58:41 -0500 (EST) Received: (qmail 10921 invoked from network); 13 Jan 2018 02:58:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Jan 2018 02:58:40 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 10FC7EC7C39; Fri, 12 Jan 2018 18:58:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Builworld stalls on rpi2 [various processes stuck in pfault and vmwait with 1996M Free Swap listed by top] From: Mark Millard In-Reply-To: <20180113024346.GB48702@www.zefox.net> Date: Fri, 12 Jan 2018 18:58:39 -0800 Cc: Freebsd-arm , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <866A14D4-2D81-4C2E-B902-0AD05514E709@dsl-only.net> References: <20180113005426.GA48702@www.zefox.net> <19904500-5819-47AC-9666-7103ED87C1CA@dsl-only.net> <20180113024346.GB48702@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 03:58:48 -0000 On 2018-Jan-12, at 6:43 PM, bob prohaska wrote: > On Fri, Jan 12, 2018 at 05:53:03PM -0800, Mark Millard wrote: >>=20 >> On 2018-Jan-12, at 4:54 PM, bob prohaska = wrote: >>=20 >>>=20 >>> The machine still answers ping. Typing escape control-b does not >>> bring up a debugger, did the keysequence change? Power cycling seems >>> to be the only way out. >>=20 >> With or without: >>=20 >> options ALT_BREAK_TO_DEBUGGER >>=20 >> For with: ~^B (with being >> and ^ being ) is an alternate with >> this. >>=20 >=20 > The line=20 > options ALT_BREAK_TO_DEBUGGER > does not appear in the GENERIC kernel, but > neither does the ue identifier for ethernet. > I thought perhaps both were included from > elsewhere. Maybe not. I'll add it. >=20 >=20 I tend to include GENERIC in another file and then specify things I want as well or instead: # more /usr/src/sys/arm/conf/GENERIC-NODBG=20 include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE options KLD_DEBUG #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING nooptions DEADLKRES # Enable the deadlock resolver nooptions USB_DEBUG nooptions USB_REQ_DEBUG nooptions USB_VERBOSE # more /usr/src/sys/arm/conf/GENERIC-DBG include "GENERIC" ident GENERIC-DBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KLD_DEBUG #options KTR #options KTR_MASK=3DKTR_TRAP|KTR_PROC ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Enable any extra checking for. . . options INVARIANTS # Enable calls of extra sanity = checking options INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS options WITNESS # Enable checks to detect = deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC options BUF_TRACKING options FULL_BUF_TRACKING options DEADLKRES # Enable the deadlock resolver options USB_DEBUG #options USB_REQ_DEBUG #options USB_VERBOSE This avoids changing the official GENERIC. Of course I have to specify the non-default file name for the build. >> I've see the smsc0 messages before but I'm >> not up to -r327664+ yet. This has been with >> a non-debug kernel running. >>=20 >> I've had building large ports get into such states, >> especially while at least one large link operation >> was active with other fairly large processes, >> as I remember. >>=20 >> Note all the pfault and vmwait lines. It looks like >> -r327316 and -r327468 did not happen to avoid this. >> It looks like the paging/swaping has gotten stuck >> in some way. How tied that might be to smsc0 >> messages, I've no clue. >>=20 >> You might get through by using -j3 or -j2 or -j1 which >> likely would use less process space at once (worst case) >> than -j4 happened to. >>=20 >> Of course there are other time consequences as you >> approach -j1 (or no explicit -j for the buildworld >> at all). >>=20 >>=20 >=20 > I'd rather not slow things down, but slow is better than > crashed.... =3D=3D=3D Mark Millard markmi at dsl-only.net