Date: Fri, 1 Jun 2018 11:21:12 +0800 From: Ka Ho Ng <khng300@gmail.com> To: Kevin Oberman <rkoberman@gmail.com> Cc: stable@freebsd.org Subject: Re: Suspected KBI breakage between FreeBSD 11.1-p9 and FreeBSD 11.2-BETA3 Message-ID: <CANnchUaWxi3vyVHnY-rp8bTvHXpQKJTcf-8DTHbhGVobOsZ5iw@mail.gmail.com> In-Reply-To: <CAN6yY1vOtS4z=4huejkZYA3PJ78aDxCexa9mT924Ed_FExYBhA@mail.gmail.com> References: <CANnchUYqVXn69qtd6Af7APSG_b49fSq_batL%2BmgxbfaYzYtXcw@mail.gmail.com> <CAN6yY1vOtS4z=4huejkZYA3PJ78aDxCexa9mT924Ed_FExYBhA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 1, 2018 at 12:19 AM, Kevin Oberman <rkoberman@gmail.com> wrote: > On Thu, May 31, 2018 at 3:43 AM, Ka Ho Ng <khng300@gmail.com> wrote: >> >> Hi folks, >> >> After an upgrade from 11.1-p9 to 11.2-BETA3, vboxdrv and nvidia no longer >> works. `kldload vboxdrv` will throw kernel panic immediately. >> >> Here are the corresponding bugzilla tickets: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228535 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228536 >> >> Since these two kmod work after rebuilding the package, I suspect the >> issue >> is due to KBI breakage. >> >> Could anyone take a look into the issue? >> >> Thanks, >> Ka Hothe BETA > > > This is a long-standing issue with ports that build kernel modules, > especially virtualbox-ose-kmod. nvidia has also been touched by this, though > not as often. Kernel modules are part of the kernel and often make use of > variables in the in kernel memory that are not part of the formal KBI. > (sysutils/lsof is not a kernel module, but has many of the same issues and > the documentation clearly states that the kernel sources at port build time > MUST match the running kernel.) I don't think there's really a clear guideline on categorizing what is supposed to be part of public KBI. Let's take https://groups.google.com/forum/#!topic/muc.lists.freebsd.stable/am9fSti2wQU as an example to the issue: vm_map_min/max/pmap is documented KPI and they were made to be inline routines, but they were broken due to possible layout changes in vm_map_t . In such case how are you going to define public KBI? Is the inline routine and the layout of memory structure be considered public KBI ? What if not? If there are modules that make use of non-public KBI but there exists an alternatives which is considered public KBI of course these modules should be blamed that violate the coding guidelines and common practices in FreeBSD kernel code. But in case if there either exists no corresponding public KBIs that can be used as substitution, then the public KBI set may need to be extended and the commit which tampers the layout should be reverted/fixed, same applies to the case of the routines mentioned above. > > It has long been suggested that any port that installs a kernel module be > added to PORTS_MODULES in /etc/src.conf so that they will be rebuilt > whenever a kernel is built This does not play well with packages during the > release cycle for a new FreeBSD version, as the packages for he modules will > lag behind BETA builds. The only way I see around this is to have full > kernel sources available and manually build the modules for BETA releases. > packages are rebuilt for the actual release, so this problem only impacts > systems running STABLE or CURRENT. > > Perhaps a policy of generating new packages for the small number of ports > where this is an issue for each BETA and RC would fix it of logistical > issues are tractable. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANnchUaWxi3vyVHnY-rp8bTvHXpQKJTcf-8DTHbhGVobOsZ5iw>