freebsd stable - May 2018 - Suspected KBI breakage between FreeBSD 11.1-p9 and FreeBSD 11.2-BETA3

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 Ho

On Thu, May 31, 2018 at 3:43 AM, Ka Ho Ng <khng300 at 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.)

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 at gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

On Fri, Jun 1, 2018 at 12:19 AM, Kevin Oberman <rkoberman at gmail.com>
wrote:
> On Thu, May 31, 2018 at 3:43 AM, Ka Ho Ng <khng300 at 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 at gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>