From owner-freebsd-stable@freebsd.org Wed Mar 4 17:13:50 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 8B36B273C80 for ; Wed, 4 Mar 2020 17:13:50 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48XgT810Z3z4573 for ; Wed, 4 Mar 2020 17:13:48 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.org [185.220.148.12]) by uucp.dinoex.org (8.16.0.41/8.16.0.41) with ESMTPS id 024HD7Rj045385 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 4 Mar 2020 18:13:08 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: X-Authentication-Warning: uucp.dinoex.sub.de: Host uucp.dinoex.org [185.220.148.12] claimed to be uucp.dinoex.sub.de Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.16.0.41/8.16.0.41/Submit) with UUCP id 024HD7H1045384 for freebsd-stable@freebsd.org; Wed, 4 Mar 2020 18:13:07 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id 024GBrBi050059 for ; Wed, 4 Mar 2020 17:11:53 +0100 (CET) (envelope-from peter@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id 024G9pwv049837 for ; Wed, 4 Mar 2020 17:09:52 +0100 (CET) (envelope-from peter@gate.oper.dinoex.org) Received: (from peter@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id 024G9psw049836 for freebsd-stable@freebsd.org; Wed, 4 Mar 2020 17:09:51 +0100 (CET) (envelope-from peter) Date: Wed, 4 Mar 2020 17:09:51 +0100 From: Peter Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@freebsd.org Subject: panic: too many modules Message-ID: <20200304160951.GA44138@gate.oper.dinoex.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 185.220.148.12; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.org [185.220.148.12]); Wed, 04 Mar 2020 18:13:11 +0100 (CET) X-Rspamd-Queue-Id: 48XgT810Z3z4573 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pmc@citylink.dinoex.sub.org has no SPF policy when checking 2001:1440:5001:1::2) smtp.mailfrom=pmc@citylink.dinoex.sub.org X-Spamd-Result: default: False [0.03 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.11)[-0.114,0]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.947,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; HAS_XAW(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[sub.org]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8469, ipnet:2001:1440::/32, country:DE]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(0.19)[ip: (0.50), ipnet: 2001:1440::/32(0.25), asn: 8469(0.20), country: DE(-0.02)] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 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, 04 Mar 2020 17:13:50 -0000 Front up: I do not like loadable modules. They are nice to try something out, but when you start to depend on some dozen loaded modules, debugging becomes a living hell: say you hunt some spurious misbehaviour and compare logfiles with those from four weeks ago, you will not know exactly which modules were loaded at that time. Compiling everything into the kernel has the advantage that the 'uname' does change on every change and so does precisely describe the running kernel. So I came across the cc_vegas and cc_cdg modules, and they aren't provided to compile into the kernel straightaway. But that should not be a big deal: just add some arbitrary new device to the KERNCONF, and then add the required files to sys/conf/files appropriately. Should work. But it doesn't. Right after the startup message, before even probing devices, it says panic: module_register_init: module named ertt not found and a stacktrace from kern/init_main.c:mi_startup(). But definitely the h_ertt is present in the kernel (I checked). To have a closer look, I added VERBOSE_SYSINIT to the kernel, and - the panic is gone, everything working as expected. Without even activating the output from VERBOSE_SYSINIT. Then, I moved netinet/khelp/h_ertt.c to the very end of sys/conf/files - and this also avoids the panic and things do work. While this change does nothing but change the sequence in which the files are compiled (and probably linked). I think this is not good. Everybody likes modules, (although -see above- they come with a serious tradeoff on reproducability). But if we now deliver components only as loadable modules because a compound kernel is no longer able to sort them out on boot, that's a more serious issue. I wouldn't complain if the module would simply not work (reproducible) when compiled into the kernel - but this here appears to be a race, most likely a timing race. And such being possible to happen at the point where the kernel sorts out it's own components - ups, that does worry me indeed... There seems also to be a desire for a *fast* system bringup. I don't share that. I do boot once a quarter, and if that takes a hour I don't mind. Maybe there is need for an option, to give fast boot to those who want a gaming console alike to be available immediately, and slow boot for those who want a reliable system in 24/7 operation? Maybe I'll take a closer look at the issue after switching to R.12 (probably not this year). Or, maybe somebody would like to point me to some paper describing how the module fabric is supposed to interface and by which steps the runtime linkage is achieved? Platform: FreeBSD 11.3-RELEASE-p6, Intel(R) Core(TM) i5-3570T CPU (IvyBridge) cheerio, PMc