From owner-freebsd-stable@freebsd.org Sat Jul 22 08:37:40 2017 Return-Path: Delivered-To: freebsd-stable@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 64148CFF277 for ; Sat, 22 Jul 2017 08:37:40 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E8D6A7189E; Sat, 22 Jul 2017 08:37:39 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id v6M8bYA8027416 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 Jul 2017 10:37:35 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: kostikbel@gmail.com Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id v6M8bU0H007977; Sat, 22 Jul 2017 15:37:30 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: stable/11 r321349 crashing immediately To: Konstantin Belousov References: <201707220542.v6M5ggtP052112@gw.catspoiler.org> <5972E7C5.6070102@grosbein.net> <20170722070529.GP1935@kib.kiev.ua> <5973018B.2050505@grosbein.net> <20170722080012.GR1935@kib.kiev.ua> Cc: Don Lewis , pz-freebsd-stable@ziemba.us, freebsd-stable@FreeBSD.org From: Eugene Grosbein X-Enigmail-Draft-Status: N1110 Message-ID: <59730ECA.7030309@grosbein.net> Date: Sat, 22 Jul 2017 15:37:30 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20170722080012.GR1935@kib.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=3.6 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 3.3 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: *** X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 08:37:40 -0000 On 22.07.2017 15:00, Konstantin Belousov wrote: > On Sat, Jul 22, 2017 at 02:40:59PM +0700, Eugene Grosbein wrote: >> Also, I've always wondered what load pattern one should have >> to exhibit real kernel stack problems due to KVA fragmentation >> and KSTACK_PAGES>2 on i386? > In fact each stack consumes 3 contigous pages because there is also > the guard, which catches the double faults. > > You need to use the machine, e.g. to run something that creates and destroys > kernel threads, while doing something that consumes kernel_arena KVA. > Plain malloc/zmalloc is enough. Does an i386 box running PPPoE connection to an ISP (mpd5) plus several IPSEC tunnels plus PPtP tunnel plus WiFi access point plus "transmission" torrent client with 2TB UFS volume over GEOM_CACHE over GEOM_JOURNAL over USB qualify? There are ospfd, racoon, sendmail, ssh and several periodic cron jobs too. > In other words, any non-static load would cause fragmentation preventing > allocations of the kernel stacks for new threads. > >> How can I get ddb backtrace you asked for? I'm not very familiar with ddb. >> I have serial console to such i386 system. > > bt command for the given thread provides the backtrace. I have no idea > how did you obtained the numbers that you show. Not sure what kernel thread I too to trace... If you just need a name of the function: $ objdump -d vm_object.o | grep -B 8 'sub .*0x...,%esp' |less 00003b30 : 3b30: 55 push %ebp 3b31: 89 e5 mov %esp,%ebp 3b33: 53 push %ebx 3b34: 57 push %edi 3b35: 56 push %esi 3b36: 83 e4 f8 and $0xfffffff8,%esp 3b39: 81 ec 30 05 00 00 sub $0x530,%esp It uses stack for pretty large struct kinfo_vmobject (includes char kvo_path[PATH_MAX]) and several others.