From owner-freebsd-current@freebsd.org Sat Sep 8 19:43:29 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 01875FFC32E for ; Sat, 8 Sep 2018 19:43:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 692CF76010; Sat, 8 Sep 2018 19:43:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w88JhGo0044543 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 8 Sep 2018 22:43:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w88JhGo0044543 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w88JhG5d044542; Sat, 8 Sep 2018 22:43:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 8 Sep 2018 22:43:16 +0300 From: Konstantin Belousov To: Michael Butler Cc: John Baldwin , Ian FREISLICH , freebsd-current Subject: Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted' Message-ID: <20180908194316.GI3161@kib.kiev.ua> References: <524214ac-e3ca-53cd-aee3-dac9212e9800@capeaugusta.com> <0aa35f96-9f62-bfca-c04a-f6ddcb1ce738@FreeBSD.org> <8ed7961e-e12a-9267-2bd0-a9bcbe383c7f@protected-networks.net> <20180831052805.GP2340@kib.kiev.ua> <04526140-c561-ae1c-cc0a-52bc8b4edb3c@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04526140-c561-ae1c-cc0a-52bc8b4edb3c@protected-networks.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 08 Sep 2018 19:43:29 -0000 On Sat, Sep 08, 2018 at 02:07:41PM -0400, Michael Butler wrote: > On 8/31/18 1:28 AM, Konstantin Belousov wrote: > > On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote: > > [ .. snip .. ] > > >> I see another problem after using Ian's workaround of moving the #ifdef > >> SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) > >> machine with only 512MB of RAM: > >> > >> Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed > >> Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed > >> Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed > >> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed > >> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed > >> Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed > > > > What is the kernel revision for "now". What was the previous revision > > where the kstack allocation failures did not happen. > > > > Also, what is the workload ? > > Sorry for the delay. Any version at or after SVN r338360 would either a) > not boot at all or b) crash shortly after boot with a swarm of messages > as above. It was stable before that. > > Unfortunately, this machine is remote and, being as old as it is, has no > remote console facility. 'nextboot' has been my savior ;-) > > It is a 700MHz Pentium-III with 512MB of RAM and has 3 used interfaces, > local ethernet (FXP), GIF for an IPv6 tunnel to HE and TAP for an > OpenVPN endpoint. It has IPFW compiled into the kernel and acts as a > router/firewall with few actual applications running. > > As another data point, I manually reversed both SVN r338360 and r338415 > (a related change) and it is now stable running at SVN r338520, It is very unprobable. I do not see how could r338360 affect KVA allocation. Double-check that you booted right kernels.