Date: Wed, 4 Mar 2020 17:09:51 +0100 From: Peter <pmc@citylink.dinoex.sub.org> To: freebsd-stable@freebsd.org Subject: panic: too many modules Message-ID: <20200304160951.GA44138@gate.oper.dinoex.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200304160951.GA44138>