From owner-freebsd-stable@freebsd.org Wed Dec 9 11:03:37 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2232B477C81 for ; Wed, 9 Dec 2020 11:03:37 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CrZ0n0Wsdz4lN5; Wed, 9 Dec 2020 11:03:37 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id E49D4283D8; Wed, 9 Dec 2020 11:03:36 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 3B7624DD69; Wed, 9 Dec 2020 12:03:35 +0100 (CET) From: "Kristof Provost" To: Peter Cc: "Kyle Evans" , "FreeBSD-STABLE Mailing List" Subject: Re: Panic: 12.2 fails to use VIMAGE jails Date: Wed, 09 Dec 2020 12:03:34 +0100 X-Mailer: MailMate (1.13.2r5673) Message-ID: <5AC3DABA-E556-469C-926B-13484E75E64B@FreeBSD.org> In-Reply-To: References: <20201207125451.GA11406@gate.oper.dinoex.org> <39DBEA53-960F-4D70-86D7-847E6DFA437D@FreeBSD.org> <20201207233449.GA11025@gate.oper.dinoex.org> <1AAE98C9-ADF9-4869-B863-601542CEBB67@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 11:03:37 -0000 Peter, I’m not interested in discussing software development methodology here. Please drop me from this thread. Let me know if/when you have a test case I can work from. Regards, Kristof On 9 Dec 2020, at 11:54, Peter wrote: > On Tue, Dec 08, 2020 at 07:51:07PM -0600, Kyle Evans wrote: > > ! You seem to have misinterpreted this; he doesn't want to narrow it > ! down to one bug, he wants simple steps that he can follow to > reproduce > > Maybe I did misinterpret, but then I don't really understand it. > I would suppose, when testing a proposed fix, the fact that it > does break under the exact same conditions as before, is all the > information needed at that point. Put in simple words: that it does > not work. > > ! any failure, preferably steps that can actually be followed by just > ! about anyone and don't require immense amounts of setup time or > ! additional hardware. > > Engineering does not normally work that way. > > I'll try to explain: when a bug is first encountered, it is necessary > to isolate it insofar that somebody who is knowledgeable of the code, > can actually reproduce it, in order to have a look at it and analyze > what causes the mis-happening. > > If then a remedy is devised, and that does not work as expected, then > the flaw is in the analysis, and we just start over from there. > > In fact, I would have expected somebody who is trying to fix such > kind of bug, to already have testing tools available and tell me > exactly which kind of data I might retrieve from the dumps. > > The open question now is: am I the only one seeing these failures? > Might they be attributed to a faulty configuration or maybe hardware > issues or whatever? > We cannot know this, we can only watch out what happens at other > sites. And that is why I sent out all these backtraces - because they > appear weird and might be difficult to associate with this issue. > > I don't think there is much more we can do at this point, unless we > were willing to actually look into the details. > > > Am I discouraging? Indeed, I think, engineering is discouraging by > it's very nature, and that's the fun of it: to overcome odds and > finally maybe make things better. And when we start to forget about > that, bad things begin to happen (anybody remember Apollo 13?). > > But talking about disencouragement: I usually try to track down > defects I encounter, and, if possible, do a viable root-cause > analysis. I tended to be very willing to share the outcomes and. if > a solution arises, by all means make that get back into the code base; > but I found that even ready made patches for easy matters would > linger forever in the sendbug system without anybody caring, or, in > more complex cases where I would need some feedback from the original > writer, if only to clarify the purpose of some defaults or verify > than an approach is viable, that communication is very difficult to > establish. And that is what I would call disencouraging, and I for > my part have accepted to just leave the developers in their ivory > tower and tend to my own business. > > > cheerio, > PMc