From owner-freebsd-current@freebsd.org Thu Mar 30 14:32:09 2017 Return-Path: Delivered-To: freebsd-current@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 15B3ED26E20 for ; Thu, 30 Mar 2017 14:32:09 +0000 (UTC) (envelope-from brde@optusnet.com.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 F166CFFD for ; Thu, 30 Mar 2017 14:32:08 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id F0AC4D26E1F; Thu, 30 Mar 2017 14:32:08 +0000 (UTC) Delivered-To: current@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 F04B9D26E1E for ; Thu, 30 Mar 2017 14:32:08 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 818C5FF9; Thu, 30 Mar 2017 14:32:08 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 6758B424E39; Fri, 31 Mar 2017 01:32:05 +1100 (AEDT) Date: Fri, 31 Mar 2017 01:32:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrey Chernov cc: Bruce Evans , "Ngie Cooper (yaneurabeya)" , bde@freebsd.org, current@freebsd.org Subject: Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others In-Reply-To: <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> Message-ID: <20170331012114.G3075@besplex.bde.org> References: <7d5bbbf0-6908-185c-2ee0-29e0a4f60591@freebsd.org> <5587c798-d36c-9074-1060-30e206db5571@freebsd.org> <69af07a7-ec8f-9b7f-8b93-9ba148f30fec@freebsd.org> <8C24D1BA-1607-4C19-BA38-39256E82C7AF@gmail.com> <51045bee-a626-efb3-4b1e-0c3d36abb1ab@freebsd.org> <20170329132927.U882@besplex.bde.org> <20170330150449.R1061@besplex.bde.org> <3534bbeb-9f73-4e37-8f89-c05dd9f89f8c@freebsd.org> <20170330183716.W1655@besplex.bde.org> <4085b441-74ee-796f-adc0-713dfc198b03@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VbSHBBh9 c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=BwQVPUagxSYhzVETn80A:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Thu, 30 Mar 2017 16:02:14 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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: Thu, 30 Mar 2017 14:32:09 -0000 On Thu, 30 Mar 2017, Andrey Chernov wrote: >> We don't understand the bug yet. It might not even be in sc. Do you only >> see problems for shutdown? The shutdown environment is special for >> locking. > > Yes, only for reboot/shutdown. The system does not do anythings wrong > even under high load. On reboot or hang those lines are never printed: > > kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done > kernel: Waiting (max 60 seconds) for system process `bufdaemon' to > stop...done > kernel: Waiting (max 60 seconds) for system process `syncer' to stop... > kernel: Syncing disks, vnodes remaining...5 3 0 1 0 0 done > kernel: All buffers synced. > (it is from 10-stable sample, old -current samples are lost) > > Moreover, GELI swap deactivation lines are never printed too (I already > mention that I change swap to normal, but nothing is changed). > >> A hang in sc means that deadlock occurred and sc's new deadlock detection >> didn't work. > > Hangs are rare. Most common are premature reboots. > >> Check that ddb works before shutdown, or just put a lot of printfs in > > I can't check it ddb because I can't enter ddb in sc mode, as I already > write, nothing happens. Only vt mode allows Ctrl-Alt-ESC, but the bug > does not exist in vt mode, so it is pointless. That is signficant. My changes were initially all about making ddb work almost perfectly with sc. ddb is entered by kdb first calling cngrab(), which does much the same things as cnputc(), but more to set up for using the keyboard. If the sc part of cngrab() detects a problem, it should return and then the sc part of cnputc() should detect the same problem and do emergency output which might be just to buffer it. Nothing at all happening looks like a simpler problem, with Ctrl-Alt-ESC not being recognized. There are too many ways to enable/disable this entry, but I didn't change this. >>>> You might have entered ddb in a context which used to race or deadlock. >>> >>> No. I try about 20 times on machine which does nothing and can't enter >>> KDB in sc only mode, but got one dead hang instead, when start to repeat >>> it too fast. >> >> Even earlier than shutdown, and when booting? > > I mean in normal operation mode after booting, earlier than shutdown. > Shutdown with premature reboot is too fast to press anything at the > right time. I don't try to enter ddb when booting yet, but tell you > results later. Look early in kern_reboot(), where it does print_uptime() then cngrab(). Console output before this cngrab() should work normally, and I suspect that something in cngrab() reboots. But syncing the file systems is done before this. I think they are unmounted later, so are fscked but don't need more than fsck -p if they have been synced. Bruce