On Fri, Jun 1, 2018 at 12:19 AM, Kevin Oberman wrote:
> On Thu, May 31, 2018 at 3:43 AM, Ka Ho Ng 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: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
